EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

2 digit dice (random counter 1 - 6)

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - 2 digit dice (random counter 1 - 6)

Goto page 1, 2  Next

Nathan Osborne
Guest

Mon Nov 19, 2012 11:01 pm   



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
Guest

Tue Nov 20, 2012 3:31 am   



On Monday, November 19, 2012 4:01:42 PM UTC-5, njozzy wrote:
Quote:
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


Guest

Tue Nov 20, 2012 9:57 am   



Am Montag, 19. November 2012 22:01:42 UTC+1 schrieb njozzy:
Quote:
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
Guest

Tue Nov 20, 2012 4:40 pm   



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

rickman
Guest

Tue Nov 20, 2012 8:07 pm   



On 11/20/2012 9:40 AM, njozzy wrote:
Quote:
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
Guest

Wed Nov 21, 2012 12:59 am   



Quote:


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


Guest

Wed Nov 21, 2012 10:48 am   



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




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


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
Guest

Wed Nov 21, 2012 5:59 pm   



On 21 Nov., 09:48, goous...@gmail.com wrote:
[..]
Quote:
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
Guest

Wed Nov 21, 2012 8:42 pm   



On 11/21/2012 10:59 AM, Thomas Stanka wrote:
Quote:
On 21 Nov., 09:48, goous...@gmail.com 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
Guest

Wed Nov 21, 2012 11:12 pm   



Thomas Stanka wrote:
Quote:
On 21 Nov., 09:48, goous...@gmail.com 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


Guest

Thu Nov 22, 2012 9:53 am   



Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:
Quote:
On 21 Nov., 09:48, goous...@gmail.com 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.

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
Guest

Thu Nov 22, 2012 5:17 pm   



On 11/22/2012 2:53 AM, goouse99_at_gmail.com wrote:
Quote:
Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:
On 21 Nov., 09:48, goous...@gmail.com 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.

Quote:
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



Guest

Fri Nov 23, 2012 8:53 am   



Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:
Quote:
On 11/22/2012 2:53 AM, goous...@gmail.com wrote:

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

On 21 Nov., 09:48, goous...@gmail.com 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


Quote:


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



rickman
Guest

Fri Nov 23, 2012 10:45 pm   



On 11/23/2012 1:53 AM, goouse99_at_gmail.com wrote:
Quote:
Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:
On 11/22/2012 2:53 AM, goous...@gmail.com wrote:

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

On 21 Nov., 09:48, goous...@gmail.com 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


Guest

Mon Nov 26, 2012 11:17 am   



Am Freitag, 23. November 2012 22:45:25 UTC+1 schrieb rickman:
Quote:
On 11/23/2012 1:53 AM, goous...@gmail.com wrote:

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

On 11/22/2012 2:53 AM, goous...@gmail.com wrote:



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



On 21 Nov., 09:48, goous...@gmail.com 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

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

Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - VHDL Language - 2 digit dice (random counter 1 - 6)

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map