Data structures and signals and stuff.

[Murph]

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 <&gt of bit;
type boardLocation is array (natural range <&gt 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.

 

[Paul Uiterlinden]

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 <&gt of bit;
type boardLocation is array (natural range <&gt 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

 

[Mike Treseler]

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

 

[Murph]

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 <&gt of bit;
type boardLocation is array (natural range <&gt 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

 

[KJ]

"Andy" <jonesandy@comcast.net> wrote in message
news:1165413674.160605.162270@f1g2000cwa.googlegroups.com...

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

 

[Mike Treseler]

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

 

[Andy]

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 <&gt of bit;
type boardLocation is array (natural range <&gt 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

 

[Paul Uiterlinden]

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

 

[Mike Treseler]

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

 

[Andy]

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