Data structures and signals and stuff.

Discussion in 'VHDL' started by Murph, Dec 2, 2006.

  1. Murph

    Murph Guest

    Hello!
    I'm trying to implement a game in VHDL, for simulation on a Spartan-3
    board (through Xilinx WebPack if it matters).

    I need to have a 200-bit array to store the current "state" of the game
    board (marking each location as either taken or not), and I need to
    store a four-element array of locations on that board that represent
    the "current piece" (which isn't accounted for in the 200 bits).

    Would this work?
    subtype boardSize is integer range 0 to 199;
    type boardArray is array (natural range <>) of bit;
    type boardLocation is array (natural range <>) of boardSize;
    signal boardState : boardArray(boardSize);
    signal pieceLocations : boardLocation(0 to 3);

    Or do you have any better idea / advice? :)
    Thanks,
    --Murph

    PS - Would I be able to address something like
    boardArray(boardLocation("1"))? that'd be awesome.
    Murph, Dec 2, 2006
    #1
    1. Advertising

  2. Murph wrote:

    > Hello!
    > I'm trying to implement a game in VHDL, for simulation on a
    > Spartan-3 board (through Xilinx WebPack if it matters).
    >
    > I need to have a 200-bit array to store the current "state" of the
    > game board (marking each location as either taken or not), and I
    > need to store a four-element array of locations on that board that
    > represent the "current piece" (which isn't accounted for in the 200
    > bits).
    >
    > Would this work?


    What have you tried, what are the error messages and which error
    message is it that you do not understand?

    First think, then try to simulate it, then think again and then if
    you're stuck, then post your question here with the code and error
    messages or behavior and expected behavior.

    > subtype boardSize is integer range 0 to 199;
    > type boardArray is array (natural range <>) of bit;
    > type boardLocation is array (natural range <>) of boardSize;
    > signal boardState : boardArray(boardSize);
    > signal pieceLocations : boardLocation(0 to 3);
    >
    > Or do you have any better idea / advice? :)
    > Thanks,
    > --Murph
    >
    > PS - Would I be able to address something like
    > boardArray(boardLocation("1"))?


    No, but boardArray(boardLocation(1)) would work.
    It's just a matter of evaluating the expressions and consider the
    types. boardLocation is an array of integers (or rather a sybtype of
    integers), so boardLocation(1) (the index must be a natural, which
    "1" is not) gives an integer (subtype). The index of boardArray is
    another integer subtype (natural), so your expression is OK.

    For the rest, given the information available, your approach seems OK.
    Personally, I would use variables in stead of signals. Signals are
    only needed for communication between processes. Using synchronous
    design, I don't see reasons to have boardState or pieceLocations
    visible in more than one process.

    > that'd be awesome.


    Your choice of words. ;-)

    --
    Paul.
    www.aimcom.nl
    email address: switch x and s
    Paul Uiterlinden, Dec 3, 2006
    #2
    1. Advertising

  3. Murph

    Murph Guest

    Paul Uiterlinden wrote:
    > Murph wrote:
    >
    > > Hello!
    > > I'm trying to implement a game in VHDL, for simulation on a
    > > Spartan-3 board (through Xilinx WebPack if it matters).
    > >
    > > I need to have a 200-bit array to store the current "state" of the
    > > game board (marking each location as either taken or not), and I
    > > need to store a four-element array of locations on that board that
    > > represent the "current piece" (which isn't accounted for in the 200
    > > bits).
    > >
    > > Would this work?

    >
    > What have you tried, what are the error messages and which error
    > message is it that you do not understand?
    >
    > First think, then try to simulate it, then think again and then if
    > you're stuck, then post your question here with the code and error
    > messages or behavior and expected behavior.


    Thanks - I'll try this. I have to write a decent chunk of my project
    before I can really tell if it actually works beyond passing the syntax
    checker, so I wanted to make sure I wasn't making a stupid mistake /
    would have to write it all somehow differently.

    > > subtype boardSize is integer range 0 to 199;
    > > type boardArray is array (natural range <>) of bit;
    > > type boardLocation is array (natural range <>) of boardSize;
    > > signal boardState : boardArray(boardSize);
    > > signal pieceLocations : boardLocation(0 to 3);
    > >
    > > Or do you have any better idea / advice? :)
    > > Thanks,
    > > --Murph
    > >
    > > PS - Would I be able to address something like
    > > boardArray(boardLocation("1"))?

    >
    > No, but boardArray(boardLocation(1)) would work.
    > It's just a matter of evaluating the expressions and consider the
    > types. boardLocation is an array of integers (or rather a sybtype of
    > integers), so boardLocation(1) (the index must be a natural, which
    > "1" is not) gives an integer (subtype). The index of boardArray is
    > another integer subtype (natural), so your expression is OK.


    That make sense :) Thanks

    > For the rest, given the information available, your approach seems OK.
    > Personally, I would use variables in stead of signals. Signals are
    > only needed for communication between processes. Using synchronous
    > design, I don't see reasons to have boardState or pieceLocations
    > visible in more than one process.


    I can do that? We were told that signals would synthesize into
    flip-flops / latches, but variables wouldn't retain their values, so
    they were only good for temporary information. woah :)

    Thanks for the help / I'll write back if things don't work out, but it
    sounds like I'm starting to understand things better, so hopefully I
    won't have too many questions.

    --Murph
    Murph, Dec 3, 2006
    #3
  4. Murph wrote:

    > I can do that? We were told that signals would synthesize into
    > flip-flops / latches, but variables wouldn't retain their values, so
    > they were only good for temporary information.


    That is the conventional wisdom, but it is wrong.
    If you need evidence, see the synthesis examples here:
    http://home.comcast.net/~mike_treseler/
    These designs use variables exclusively yet infer flops just fine.

    -- Mike Treseler
    Mike Treseler, Dec 3, 2006
    #4
  5. Murph

    Andy Guest

    Signal assignments in clocked processes almost always become registers,
    unless they are assigned from a variable (or expression of variables),
    after the final "end if;" in which case they will not be registers.
    (This is a useful trick, BTW.)

    Variables assignments in clocked process by themselves do not determine
    register or combinatorial logic. The relative order of assignment to
    each reference determines whether each reference is a registered or
    combinatorial value. If the variable is assigned, within the same clock
    cycle execution of the process, prior to the reference, then the
    reference is to a combinatorial value of the variable. If on the other
    hand, the most recent assignment to a variable prior to reference was
    from a previous clock cycle, then the reference is to a registered
    value of the variable.

    You might even have a case where the previous assignment may or may not
    have happened in the same clock cycle. In this case the synthesis tool
    includes a mux, to select between the combinatorial or registered
    value, controlled by the same logic that determined whether the
    previous assignment happened in the same clock or not.

    Just write it out, and read it like software. If the simulator would
    have to remember the variables value from a previous clock, then that
    reference is to a registered value.

    The synthesis tool's job is to give you a circuit that behaves just
    like the simulation, or warn you that it could not do so.

    Andy


    Murph wrote:
    > Paul Uiterlinden wrote:
    > > Murph wrote:
    > >
    > > > Hello!
    > > > I'm trying to implement a game in VHDL, for simulation on a
    > > > Spartan-3 board (through Xilinx WebPack if it matters).
    > > >
    > > > I need to have a 200-bit array to store the current "state" of the
    > > > game board (marking each location as either taken or not), and I
    > > > need to store a four-element array of locations on that board that
    > > > represent the "current piece" (which isn't accounted for in the 200
    > > > bits).
    > > >
    > > > Would this work?

    > >
    > > What have you tried, what are the error messages and which error
    > > message is it that you do not understand?
    > >
    > > First think, then try to simulate it, then think again and then if
    > > you're stuck, then post your question here with the code and error
    > > messages or behavior and expected behavior.

    >
    > Thanks - I'll try this. I have to write a decent chunk of my project
    > before I can really tell if it actually works beyond passing the syntax
    > checker, so I wanted to make sure I wasn't making a stupid mistake /
    > would have to write it all somehow differently.
    >
    > > > subtype boardSize is integer range 0 to 199;
    > > > type boardArray is array (natural range <>) of bit;
    > > > type boardLocation is array (natural range <>) of boardSize;
    > > > signal boardState : boardArray(boardSize);
    > > > signal pieceLocations : boardLocation(0 to 3);
    > > >
    > > > Or do you have any better idea / advice? :)
    > > > Thanks,
    > > > --Murph
    > > >
    > > > PS - Would I be able to address something like
    > > > boardArray(boardLocation("1"))?

    > >
    > > No, but boardArray(boardLocation(1)) would work.
    > > It's just a matter of evaluating the expressions and consider the
    > > types. boardLocation is an array of integers (or rather a sybtype of
    > > integers), so boardLocation(1) (the index must be a natural, which
    > > "1" is not) gives an integer (subtype). The index of boardArray is
    > > another integer subtype (natural), so your expression is OK.

    >
    > That make sense :) Thanks
    >
    > > For the rest, given the information available, your approach seems OK.
    > > Personally, I would use variables in stead of signals. Signals are
    > > only needed for communication between processes. Using synchronous
    > > design, I don't see reasons to have boardState or pieceLocations
    > > visible in more than one process.

    >
    > I can do that? We were told that signals would synthesize into
    > flip-flops / latches, but variables wouldn't retain their values, so
    > they were only good for temporary information. woah :)
    >
    > Thanks for the help / I'll write back if things don't work out, but it
    > sounds like I'm starting to understand things better, so hopefully I
    > won't have too many questions.
    >
    > --Murph
    Andy, Dec 5, 2006
    #5
  6. Murph wrote:

    > Thanks - I'll try this. I have to write a decent chunk of my project
    > before I can really tell if it actually works beyond passing the
    > syntax checker, so I wanted to make sure I wasn't making a stupid
    > mistake / would have to write it all somehow differently.


    Also here I would say: first try it out.

    Whenever I try to invent some new construct or algorithm, I first test
    the pieces in what I call a sand box. It is a simple environment to
    play with things and test them. Only after I see things are working
    as expected, I incorporate the new constructs and algorithms in a
    bigger environment.

    Of course, this must not be taken into extreme. Quite often, setting a
    breakpoint on the new piece of code and go through it step by step
    also gives me enough confidence about the behavior of the code.

    --
    Paul.
    www.aimcom.nl
    email address: switch x and s
    Paul Uiterlinden, Dec 5, 2006
    #6
  7. Andy wrote:

    > Just write it out, and read it like software. If the simulator would
    > have to remember the variables value from a previous clock, then that
    > reference is to a registered value.


    And then, focus on getting the waveforms right.

    > The synthesis tool's job is to give you a circuit that behaves just
    > like the simulation, or warn you that it could not do so.


    Exactly.
    With the right design rules,
    a working "simulation" model is all that I need.
    I can think in data structures, waves, and clock ticks,
    and delegate the packing of LUTs, wires and flops.

    -- Mike Treseler
    Mike Treseler, Dec 5, 2006
    #7
  8. Murph

    Andy Guest

    Very good point about setting breakpoints and stepping through the
    code. I find that I prefer using the source level debugger, break
    points, assertions, etc. to debug a design, rather than looking at
    waveforms, though I use waveforms sometimes also.

    Andy


    Paul Uiterlinden wrote:
    > Murph wrote:
    >
    > > Thanks - I'll try this. I have to write a decent chunk of my project
    > > before I can really tell if it actually works beyond passing the
    > > syntax checker, so I wanted to make sure I wasn't making a stupid
    > > mistake / would have to write it all somehow differently.

    >
    > Also here I would say: first try it out.
    >
    > Whenever I try to invent some new construct or algorithm, I first test
    > the pieces in what I call a sand box. It is a simple environment to
    > play with things and test them. Only after I see things are working
    > as expected, I incorporate the new constructs and algorithms in a
    > bigger environment.
    >
    > Of course, this must not be taken into extreme. Quite often, setting a
    > breakpoint on the new piece of code and go through it step by step
    > also gives me enough confidence about the behavior of the code.
    >
    > --
    > Paul.
    > www.aimcom.nl
    > email address: switch x and s
    Andy, Dec 6, 2006
    #8
  9. Murph

    KJ Guest

    "Andy" <> wrote in message
    news:...
    > Very good point about setting breakpoints and stepping through the
    > code. I find that I prefer using the source level debugger, break
    > points, assertions, etc. to debug a design, rather than looking at
    > waveforms, though I use waveforms sometimes also.
    >


    I'm just the opposite when it comes to code breakpoints and waveforms. I'll
    use assertions, the waveform window and dataflow window, along with looking
    at (not stepping through) the source code to debug. Very rarely do I resort
    to breakpoints in the code for a couple reasons:

    - At the time that an assertion fails the thing that needs debugging has
    already gone 'wrong' so no amount of stepping through the code will help
    figure out why the assertion failed. What is needed for debug at that point
    is the history of all signals (and variables for those who like 'em) that
    led up to the point where the assert failed. log -r /* gets me the signal
    history, nothing gets me the variable history unless I know ahead of time
    which process (or processes) I need the variables logged for.

    - Since I don't use variables much, I don't get a headache looking at the
    physical placement of all the assignments to all the variables within the
    process when I'm looking at a process that I think is the suspect cause of a
    problem. Instead the behaviour is nearly always discernable from the
    signals in the wave window. The few times when the 'nearly always' didn't
    get it is when I'll put in code breakpoints.

    For those things where I don't have an assertion coded but is one of those
    'I'll know it's right when I see it' types of thing pretty much the same
    reasoning applies since again I'll run the sim for some amount of time and
    then by viewing the behaviour in the wave window 'know' whether there is a
    problem or not. Like an assertion failure, my viewing of a possible problem
    to investigate is after the 'bad' thing has happened.

    Doing it that way I very rarely have to re-simulate just to get up to the
    point just prior to the failure to step through code. Instead, the next run
    will have a fix for the problem that caused the assert to fail.

    KJ
    KJ, Dec 7, 2006
    #9
  10. Andy wrote:
    > Very good point about setting breakpoints and stepping through the
    > code. I find that I prefer using the source level debugger, break
    > points, assertions, etc. to debug a design, rather than looking at
    > waveforms, though I use waveforms sometimes also.


    I trace code sometimes also.
    This works best when debugging a single process design.

    For a multiprocess design, tracing is less
    useful as it jumps around from process to process.
    Tracing code on a design with asynchronous processes
    is almost useless for this reason.

    -- Mike Treseler
    Mike Treseler, Dec 7, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    651
    Roedy Green
    Jan 14, 2006
  2. index
    Replies:
    15
    Views:
    1,714
    Oliver Wong
    May 11, 2006
  3. tweak
    Replies:
    14
    Views:
    2,755
    Eric Sosman
    Jun 11, 2004
  4. Alfonso Morra
    Replies:
    11
    Views:
    696
    Emmanuel Delahaye
    Sep 24, 2005
  5. Alec Taylor
    Replies:
    0
    Views:
    153
    Alec Taylor
    Mar 2, 2012
Loading...

Share This Page