2 digit dice (random counter 1 - 6)

[Nathan Osborne]

hey

I need to make 2 dice with random outputs to a Spartan 3E development board

i have to implement these components into the design but i have no idea how to go about it

- counters
- Decoder 1 of 6
- latch to hold the last value displayed
- button

the counter will output the 'random' number but i do not know how to design the rest.

Being guided in the right direction would help me so much to get on the right track

thanks

 

[KJ]

hey I need to make 2 dice with random outputs to a Spartan 3E
development board i have to implement these components into the
design but i have no idea how to go about it - counters - Decoder
1 of 6 - latch to hold the last value displayed - button the
counter will output the 'random' number but i do not know how to
design the rest. Being guided in the right direction would help
me so much to get on the right track

I would suggest the following...
1. Take a course in digital design
2. Take a course in VHDL
3. Then tackle the above assignment. Steps 1 and 2 are the pre-requisites to #3

Kevin Jennings

 

[goouse99]

Am Montag, 19. November 2012 22:01:42 UTC+1 schrieb njozzy:

hey



I need to make 2 dice with random outputs to a Spartan 3E development board



i have to implement these components into the design but i have no idea how to go about it



- counters

- Decoder 1 of 6

- latch to hold the last value displayed

- button



the counter will output the 'random' number but i do not know how to design the rest.



Being guided in the right direction would help me so much to get on the right track



thanks

Hi,
how funny.
Our VHDL class students get a similar assignment for a dice game.
What university(?) & class is this for?
Do they have the assignment text online?
Out of curiosity I'd like to compare it.

Have a nice synthesis
Eilert

 

[njozzy]

hey Eilert

im studying at Anglia Ruskin doing a module in micro electronics

here is a copy of the assignment brief;

The hierachical design of a 2-digit dice (i.e. random counter 1-6) with dual 6-LED display. The same steps as in the first exercise should be followed.. You will need to make use of subcircuits containing counters (or state-machines), binary to 1 of 6 decoders, an optional latch to hold the last value displayed, at least one button, and a top-level VHDL circuit design whichmay well be structural. The random count is not truly random but arises from the relatively high speed of counting compared to the user’s input. Care should be taken to prevent correlation between first and second digit display. The timing analysis of the design must be performed through simulation (post fit) or built-in static timing analysis. The hardware implementation of the design will use the Xilinx Spartan-3E development board provided.Practical testing of working circuit must then be demonstrated on the development board.


im a computer science student and i got stuck with this module, although i find it interesting, its really hard to get my head around as electronics is not my strong side

Im not looking for answers i just need to be put in the right direction

thanks

 

[rickman]

hey Eilert

im studying at Anglia Ruskin doing a module in micro electronics

here is a copy of the assignment brief;

The hierachical design of a 2-digit dice (i.e. random counter 1-6) with dual 6-LED display. The same steps as in the first exercise should be followed. You will need to make use of subcircuits containing counters (or state-machines), binary to 1 of 6 decoders, an optional latch to hold the last value displayed, at least one button, and a top-level VHDL circuit design which may well be structural. The random count is not truly random but arises from the relatively high speed of counting compared to the user’s input. Care should be taken to prevent correlation between first and second digit display. The timing analysis of the design must be performed through simulation (post fit) or built-in static timing analysis. The hardware implementation of the design will use the Xilinx Spartan-3E development board provided. Practical testing of working circuit must then be demonstrated on the development board.


im a computer science student and i got stuck with this module, although i find it interesting, its really hard to get my head around as electronics is not my strong side

Im not looking for answers i just need to be put in the right direction

thanks

The "random" aspect of the dice is done by running a counter at "high"
speed as long as the button is held. The output of the counter will
drive the two dice displays. You can run a single 6 bit counter from 0
to 35 (there are 36 combinations of two dice) or you can use two
counters that range from 0 to 5. One increments on every edge of the
clock while the push button is held down, the other increments when the
first counter reaches the last count value and the push button is held
down. Then you can decode the outputs of the two counters to drive the
LED display.

If this were my class, I would offer extra credit if you designed the
counters to directly drive the LEDs and not use decoders of any kind but
also drive seven LEDs on each die in the same pattern that is used on
real dice.

Is that any help?

Rick

 

[njozzy]

The "random" aspect of the dice is done by running a counter at "high"

speed as long as the button is held. The output of the counter will

drive the two dice displays. You can run a single 6 bit counter from 0

to 35 (there are 36 combinations of two dice) or you can use two

counters that range from 0 to 5. One increments on every edge of the

clock while the push button is held down, the other increments when the

first counter reaches the last count value and the push button is held

down. Then you can decode the outputs of the two counters to drive the

LED display.



If this were my class, I would offer extra credit if you designed the

counters to directly drive the LEDs and not use decoders of any kind but

also drive seven LEDs on each die in the same pattern that is used on

real dice.



Is that any help?



Rick

Hey rick

thanks you have been a great help!

I've created the counters and started on the decoders and the top level,

The board that provided to us only has 6 LED lights in a straight line so I won't be able to do that.

One thing I have been wondering, is how can in express the button being pushed in the code. how are the inputs and the button connected?

Thanks again

 

[goouse99]

Am Dienstag, 20. November 2012 23:59:55 UTC+1 schrieb njozzy:

Hey rick



thanks you have been a great help!



I've created the counters and started on the decoders and the top level,



The board that provided to us only has 6 LED lights in a straight line so I won't be able to do that.



One thing I have been wondering, is how can in express the button being pushed in the code. how are the inputs and the button connected?



Thanks again

Hi,
Thanks for providing the information.
So the assignment is somewhat simpler than I thought first.
You also had some a

Do you have some board schematics for the hardware you are using?
The buttons are probably simply wired to some pins of the FPGA and maybe some pullup or pulldown resistor is there too to ensure a stable input state when the button is not pressed.

Depending on the way the button is connected to the fpga you can either receive a '0' or '1' when the button is pressed.

In your code the button will appear in your toplevel entity port list as an input. In your processes inside the according modules you can simply write stufff like:

if Button ='0' then
-- do this
else
-- do that
end if.

_________

You mentioned that there are just 6 LEDs on the board, so actually you are not able to display the two dice values simultaneously.

This can be solved in two ways:
Manual: Use a second button to switch between the two dice values.
Automatic: Use a timer (about 1 second) to toggle the display.

Have a nice synthesis
Eilert

 

[Thomas Stanka]

On 21 Nov., 09:48, (e-mail address removed) wrote:
[..]

if Button ='0' then
  -- do this
else
  -- do that
end if.

Note: Using the button this way is perfect for the first steps in
VHDL. It is a complete nogo later on.
You should be aware that direct usage of an input pin driven by a
switch offers no protection for the signal at change from the
asynchronous outer world to the internal used clock domain and you
also ignore bouncing of the input during switch events.
This will likely cause some strange missmatch between simulation and
real hardware.

Second step would be a module that debounces input and ensures, that
the input pin itself is used only after beeing clocked by the internal
clock domain (there has to be only one register, that is directly
driven by this pin, no logic, all other functionality uses the
registered value of input).

bye Thomas

 

[rickman]

On 21 Nov., 09:48, (e-mail address removed) wrote:
[..]

if Button ='0' then
-- do this
else
-- do that
end if.

Note: Using the button this way is perfect for the first steps in
VHDL. It is a complete nogo later on.
You should be aware that direct usage of an input pin driven by a
switch offers no protection for the signal at change from the
asynchronous outer world to the internal used clock domain and you
also ignore bouncing of the input during switch events.
This will likely cause some strange missmatch between simulation and
real hardware.

Second step would be a module that debounces input and ensures, that
the input pin itself is used only after beeing clocked by the internal
clock domain (there has to be only one register, that is directly
driven by this pin, no logic, all other functionality uses the
registered value of input).

bye Thomas

Ozzy,

This is some of the most important advice you will get on designing
digital logic. I was never taught about metastability in school, I had
to learn about it in the field. As Thomas says, this is likely not
going to mess with this particular design for two reasons, one is that
it will happen very rarely, the other is that your circuit likely will
still work just fine when it has a failure! After all, it is generating
random numbers... lol.

So you can skip learning about metastability for now, but anything that
isn't generating a random number can have mysterious, infrequent
problems if you don't learn about this at some point. BTW, it is very
easy to deal with. The quick fix is to run the input through two FFs
(with no logic between them) before using it in your design.

The fix for switch bouncing is a little more complicated and involves
using a timer to prevent the circuit from "seeing" the dozens or
hundreds of transitions on the input line from a switch. Look at the
switch output with a scope sometime, it is a real mess!

Rick

 

[Gabor]

On 21 Nov., 09:48, (e-mail address removed) wrote:
[..]

if Button ='0' then
-- do this
else
-- do that
end if.

Note: Using the button this way is perfect for the first steps in
VHDL. It is a complete nogo later on.
You should be aware that direct usage of an input pin driven by a
switch offers no protection for the signal at change from the
asynchronous outer world to the internal used clock domain and you
also ignore bouncing of the input during switch events.
This will likely cause some strange missmatch between simulation and
real hardware.

Second step would be a module that debounces input and ensures, that
the input pin itself is used only after beeing clocked by the internal
clock domain (there has to be only one register, that is directly
driven by this pin, no logic, all other functionality uses the
registered value of input).

bye Thomas

Just don't use the same counter to debounce the switch that rolls
the dice. That's a really easy way to get non-random behavior

-- Gabor

 

[goouse99]

Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

On 21 Nov., 09:48, (e-mail address removed) wrote:

[..]

if Button ='0' then

  -- do this

  -- do that

end if.

Note: Using the button this way is perfect for the first steps in

VHDL. It is a complete nogo later on.

You should be aware that direct usage of an input pin driven by a

switch offers no protection for the signal at change from the

asynchronous outer world to the internal used clock domain and you

also ignore bouncing of the input during switch events.

This will likely cause some strange missmatch between simulation and

real hardware.



Second step would be a module that debounces input and ensures, that

the input pin itself is used only after beeing clocked by the internal

clock domain (there has to be only one register, that is directly

driven by this pin, no logic, all other functionality uses the

registered value of input).



bye Thomas

Hi Thomas,
thanks for adding the hint to use debouncers on switch/button inputs.

For this special design they might be left out without harm, if used right.
So I didn't bother to mention it.
One Button would be used to controll the clock/load-enable of the output registers. Bouncing would just increase the "randomness" of the design. Sincethere are no feedbacks from these registers even a rare metastable event should cause no harm.

The other button would control the output mux to the LEDs and therfore drives simple combinatorical logic. Nothing's going metastable here.

In general, one would create a module that does the debouncing for all buttons and switches for a board and then use the debounced outputs of this block as described.

Have a nice synthesis
Eilert

 

[Gabor]

Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

On 21 Nov., 09:48, (e-mail address removed) wrote:

[..]

if Button ='0' then

-- do this

-- do that

end if.

Note: Using the button this way is perfect for the first steps in

VHDL. It is a complete nogo later on.

You should be aware that direct usage of an input pin driven by a

switch offers no protection for the signal at change from the

asynchronous outer world to the internal used clock domain and you

also ignore bouncing of the input during switch events.

This will likely cause some strange missmatch between simulation and

real hardware.



Second step would be a module that debounces input and ensures, that

the input pin itself is used only after beeing clocked by the internal

clock domain (there has to be only one register, that is directly

driven by this pin, no logic, all other functionality uses the

registered value of input).



bye Thomas

Hi Thomas,
thanks for adding the hint to use debouncers on switch/button inputs.

For this special design they might be left out without harm, if used right.
So I didn't bother to mention it.
One Button would be used to controll the clock/load-enable of the output registers. Bouncing would just increase the "randomness" of the design. Since there are no feedbacks from these registers even a rare metastable event should cause no harm.

That is true as long as the counters are simple binary with recovery
from invalid states. Otherwise you could end up with "stuck" counters.
A common manifestation of this are one-hot (ring) counters, which
could go "zero-hot" if the input is not at least synchronized to
the clock before using it as a count enable. It would not need to
be debounced, however.

 

[goouse99]

Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:

Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

On 21 Nov., 09:48, (e-mail address removed) wrote:

[..]

if Button ='0' then

-- do this

else

-- do that

end if.



Note: Using the button this way is perfect for the first steps in

VHDL. It is a complete nogo later on.

You should be aware that direct usage of an input pin driven by a

switch offers no protection for the signal at change from the

asynchronous outer world to the internal used clock domain and you

also ignore bouncing of the input during switch events.

This will likely cause some strange missmatch between simulation and

real hardware.



Second step would be a module that debounces input and ensures, that

the input pin itself is used only after beeing clocked by the internal

clock domain (there has to be only one register, that is directly

driven by this pin, no logic, all other functionality uses the

registered value of input).



bye Thomas

Hi Thomas,

thanks for adding the hint to use debouncers on switch/button inputs.

For this special design they might be left out without harm, if used right.

So I didn't bother to mention it.

One Button would be used to controll the clock/load-enable of the output registers. Bouncing would just increase the "randomness" of the design. Since there are no feedbacks from these registers even a rare metastable event should cause no harm.

That is true as long as the counters are simple binary with recovery

from invalid states. Otherwise you could end up with "stuck" counters.

A common manifestation of this are one-hot (ring) counters, which

could go "zero-hot" if the input is not at least synchronized to

the clock before using it as a count enable. It would not need to

be debounced, however.

Hi Gabor,
I was talking about output registers, not counter registers.
The counter(s) could run continuously without a CE.
The registers are then used to hold the two dice values for the (long) time that the user needs to read them. (remember: there are only 6 LEDS but two dices)

However, if counters or FSMs are involved I would always recommend proper debouncing.

Regards.
Eilert

 

[rickman]

Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:

Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

On 21 Nov., 09:48, (e-mail address removed) wrote:

[..]

if Button ='0' then
-- do this

else

-- do that
end if.
Note: Using the button this way is perfect for the first steps in
VHDL. It is a complete nogo later on.
You should be aware that direct usage of an input pin driven by a
switch offers no protection for the signal at change from the
asynchronous outer world to the internal used clock domain and you
also ignore bouncing of the input during switch events.
This will likely cause some strange missmatch between simulation and
real hardware.
Second step would be a module that debounces input and ensures, that
the input pin itself is used only after beeing clocked by the internal
clock domain (there has to be only one register, that is directly
driven by this pin, no logic, all other functionality uses the
registered value of input).
bye Thomas
Hi Thomas,

thanks for adding the hint to use debouncers on switch/button inputs.

For this special design they might be left out without harm, if used right.

So I didn't bother to mention it.

One Button would be used to controll the clock/load-enable of the output registers. Bouncing would just increase the "randomness" of the design. Since there are no feedbacks from these registers even a rare metastable event should cause no harm.

That is true as long as the counters are simple binary with recovery

from invalid states. Otherwise you could end up with "stuck" counters.

A common manifestation of this are one-hot (ring) counters, which

could go "zero-hot" if the input is not at least synchronized to

the clock before using it as a count enable. It would not need to

be debounced, however.

Hi Gabor,
I was talking about output registers, not counter registers.
The counter(s) could run continuously without a CE.
The registers are then used to hold the two dice values for the (long) time that the user needs to read them. (remember: there are only 6 LEDS but two dices)

However, if counters or FSMs are involved I would always recommend proper debouncing.

Regards.
Eilert

That would be ok as long as you use a gray code or similar on your
counters. If more than one bit can change, the output register, not
being synchronized can capture wrong combinations of signals.

Rick

 

[goouse99]

Am Freitag, 23. November 2012 22:45:25 UTC+1 schrieb rickman:

Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:

On 11/22/2012 2:53 AM, (e-mail address removed) wrote:

Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

On 21 Nov., 09:48, (e-mail address removed) wrote:



[..]



if Button ='0' then



-- do this



else



-- do that



end if.







Note: Using the button this way is perfect for the first steps in



VHDL. It is a complete nogo later on.



You should be aware that direct usage of an input pin driven by a



switch offers no protection for the signal at change from the



asynchronous outer world to the internal used clock domain and you



also ignore bouncing of the input during switch events.



This will likely cause some strange missmatch between simulation and



real hardware.







Second step would be a module that debounces input and ensures, that



the input pin itself is used only after beeing clocked by the internal



clock domain (there has to be only one register, that is directly



driven by this pin, no logic, all other functionality uses the



registered value of input).







bye Thomas



Hi Thomas,

thanks for adding the hint to use debouncers on switch/button inputs.



For this special design they might be left out without harm, if used right.

So I didn't bother to mention it.

One Button would be used to controll the clock/load-enable of the output registers. Bouncing would just increase the "randomness" of the design. Since there are no feedbacks from these registers even a rare metastable event should cause no harm.





That is true as long as the counters are simple binary with recovery

from invalid states. Otherwise you could end up with "stuck" counters.

A common manifestation of this are one-hot (ring) counters, which

could go "zero-hot" if the input is not at least synchronized to

the clock before using it as a count enable. It would not need to

be debounced, however.

Hi Gabor,

I was talking about output registers, not counter registers.

The counter(s) could run continuously without a CE.

The registers are then used to hold the two dice values for the (long) time that the user needs to read them. (remember: there are only 6 LEDS but two dices)

However, if counters or FSMs are involved I would always recommend proper debouncing.


Eilert

That would be ok as long as you use a gray code or similar on your

counters. If more than one bit can change, the output register, not

being synchronized can capture wrong combinations of signals.



Rick

Hi Rick,
good point.
I didn't consider that the Registers are individual FFs, which may take the data at slightly diffenrt times due to many causes.

So once again it has been proven that nothing comes for free.

Kind regards
Eilert

 

[njozzy]

hey thank you to everyone that's replied!

im sorry that i havnt replied recently, i have been busy with other work.
yesterday i managed to demonstrate my program on the development board! thank you for all the ideas and help for this assignment made it a lot less confusing!