Electronic Dice ( 3 die ) In VHDL

[Amstel]

Hi to all,

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

I need help urgently ..
Anyone know how to write the program ?

Thanks a lot

 

[Jonathan Bromley]

"Amstel" <lange360@hotmail.com> wrote in message
news:56f7756d.0310140824.7d8fe744@posting.google.com...

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

Do you have any idea how incredibly hard this is?

I guess you are expecting to use a fast oscillator, and let
the dice "roll" very rapidly for as long as someone holds their
finger on the button. But of course you need 3 separate
oscillators, so that the three dice don't stay in lockstep.

Next you need to ensure that the three oscillators don't in any
way influence one another. This is amazingly hard, requiring
very sophisticated engineering of the oscillators and their
power supplies; they will need extremely careful shielding
from one another, and you will need to ensure that any
inductors in each oscillator's signal path are mutually
perpendicular to inductors in the other two oscillators.
(Presumably that's why you have been asked for only 3 dice,
because adding a fourth would make the mutual-perpendicularity
constraint quite hard to achieve in this universe).

Once you have your three uncoupled oscillators, you will need
to condition the user push button in such a way that it cannot
affect the oscillators' behaviour, and it enables the counts
in a way that is protected against the inevitable
metastability you will see given that the oscillators and
pushbutton are all asynchronous.

There are also some tricky issues about whether the LED
currents may affect the oscillators (via power supply
coupling effects) in such a way that the outcome is
biased.

Oh... and once you've done all that, you have to create
the trivial counters, enable logic and 7-segment decode.
But I'm sure that you can do that easily, after all the
other challenges.

It's nice to see people posting these really exciting
research-level problems on the group.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Peter Alfke]

Hi, Jonathan, let me disagree.
I would run this with a single 200 MHz oscillator, and drive the
indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I
am sure that the human hand cannot cheat with fractional microsecond accuracy.

Peter Alfke


Jonathan Bromley wrote:

"Amstel" <lange360@hotmail.com> wrote in message
news:56f7756d.0310140824.7d8fe744@posting.google.com...
I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

Do you have any idea how incredibly hard this is?

I guess you are expecting to use a fast oscillator, and let
the dice "roll" very rapidly for as long as someone holds their
finger on the button. But of course you need 3 separate
oscillators, so that the three dice don't stay in lockstep.

Next you need to ensure that the three oscillators don't in any
way influence one another. This is amazingly hard, requiring
very sophisticated engineering of the oscillators and their
power supplies; they will need extremely careful shielding
from one another, and you will need to ensure that any
inductors in each oscillator's signal path are mutually
perpendicular to inductors in the other two oscillators.
(Presumably that's why you have been asked for only 3 dice,
because adding a fourth would make the mutual-perpendicularity
constraint quite hard to achieve in this universe).

Once you have your three uncoupled oscillators, you will need
to condition the user push button in such a way that it cannot
affect the oscillators' behaviour, and it enables the counts
in a way that is protected against the inevitable
metastability you will see given that the oscillators and
pushbutton are all asynchronous.

There are also some tricky issues about whether the LED
currents may affect the oscillators (via power supply
coupling effects) in such a way that the outcome is
biased.

Oh... and once you've done all that, you have to create
the trivial counters, enable logic and 7-segment decode.
But I'm sure that you can do that easily, after all the
other challenges.

It's nice to see people posting these really exciting
research-level problems on the group.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Nial Stewart]

Peter Alfke <peter@xilinx.com> wrote in message
news:3F8C3A8E.46F71A51@xilinx.com...

Hi, Jonathan, let me disagree.
I would run this with a single 200 MHz oscillator, and drive the
indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I
am sure that the human hand cannot cheat with fractional microsecond
accuracy.

Peter Alfke

Peter,

Was Jonathan not being ironic?

The original request reeked of 'late assignment'.


Nial.

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Peter Alfke]

I admit, my "irony detector" was temporarily asleep, and the German
seriousness took over...
But the scare story was really so neat.
Beware of these super-urgent class assignments!
Peter
==================
Nial Stewart wrote:

Peter Alfke <peter@xilinx.com> wrote in message
news:3F8C3A8E.46F71A51@xilinx.com...
Hi, Jonathan, let me disagree.
I would run this with a single 200 MHz oscillator, and drive the
indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I
am sure that the human hand cannot cheat with fractional microsecond
accuracy.

Peter Alfke

Peter,

Was Jonathan not being ironic?

The original request reeked of 'late assignment'.

Nial.

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Jim Granville]

Peter Alfke <peter@xilinx.com> wrote in message

news:3F8C3A8E.46F71A51@xilinx.com...
Hi, Jonathan, let me disagree.
I would run this with a single 200 MHz oscillator, and drive the
indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I
am sure that the human hand cannot cheat with fractional microsecond
accuracy.

No, but suppose this has a single push button ?
Each spin is going to be close to random, but the designer might be
a tad dissappointed at the correlation _across_ the 3 displays ?

Maybe some prime number freq multiplies, to give three vfast
clocks with different spin rates, would be sufficent.

Could be a good exercise for the student, to check the
cross-correlation of the 3 displays ?


Nial Stewart wrote:

The original request reeked of 'late assignment'.

It certainly did

-jg

 

[Symon]

Jonathan,
Please pay attention to the OPs spec. He/she said 'randomly'. This
implies the measurement of some random process, I suggest radioactive
decay measurement is the preferred solution. This is why Xilinx offer
radiation hardened devices specifically so people can make reliable
unbiased dice. (It's no coincidence the chips are also called 'dice'.)
Note these parts are not usually offered in BGA packages, but in
leaded ones. The lead protects against radiation.
HTH, Syms.


"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:<bmh9qo$ohc$1$8302bc10@news.demon.co.uk>...

"Amstel" <lange360@hotmail.com> wrote in message
news:56f7756d.0310140824.7d8fe744@posting.google.com...
I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

Do you have any idea how incredibly hard this is?

snipped to avoid wrath of Uwe!

 

[Chip]

How about using linear feedback shift registers instead of counters.
I've never actually used one so someone correct me if I'm wrong.

They could be driven by a single clock. They each could be
initialized with a different seed and could be long enough to run for
a long time before repeating. They would still be coupled in the
respect that each time the electronic dice is powered up each shift
register will output the same pseudo random sequence. Then a roll
consists of registering some of the lfsr bits when the dice button is
released (the lsfr is still changing while the button is not pressed)
Thus, if you could roll the dice at exactly the same times throughout
an entire game you would get the same (pseuorandom) sequence of dice
values. (But this would be highly unlikely)

lange360@hotmail.com (Amstel) wrote in message news:<56f7756d.0310140824.7d8fe744@posting.google.com>...

Hi to all,

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

I need help urgently ..
Anyone know how to write the program ?

Thanks a lot

 

[Eric Smith]

john_doebertson@yahoo.com (Chip) writes:

How about using linear feedback shift registers instead of counters.
I've never actually used one so someone correct me if I'm wrong.

Wouldn't make any difference. Either way you can cycle through all 216
combinations very rapidly.

 

[Vinh Pham]

The original request reeked of 'late assignment'.

I have to disagree with you. I think what we're seeing here is an enabling
technology for a low latency, distributed, customer support system. Every
time an end user has a problem with your equipment, instead of waiting on
hold for a customer support representative, they receive immediate
assistance by simply pressing a button and a 3-digit Instant Solution Code
(tm) is generated. For example:


Code #003 - Insufficient Memory

The function you have chosen requires a Premium Platinum+ RAM Upgrade (tm).
Internal diagnostics shows your equipment is a baseline model that contains
only enough RAM to operate the Instant Solution Code (tm) functionality.
Your local sales representative will be more than happy to assist you in
improving your user experience.


Code #012 - Undocumented Feature

Congratulations End-User! You have discovered an undocumented feature.
Please be kind enough to send us your day time phone number so we may
forward to you all calls from other End-Users that also need to be educated.
Win the adulation of your peers and support the user community today!


Code #048 - Attention Deficit Disorder

Please RTFM. Thank you.


Code #192 - User Error

Please forward the following message to your immediate supervisor:
"Attention, I am a defective End-User. I do not meet the minimum system
requirements. Please replace me with someone that has 5 more years of
experience and a more advanced higher education degree, or two recent
graduates."


Code #768 - Product Defect

You have possibly discovered a fault in our product. To be sure, press the
Instant Solution Code (tm) button again to verify. If it generates Code
#1000 then please contact us immediately. Otherwise, it's probably your
fault.


No longer does a user have to waste an inordinate amount of time becoming
frustrated. Rather they can be frustrated immediately and use their
precious time being productive in other ways. Forward thinking that keeps
the customer's needs first is what will separate first class companies from
second rate ones in this difficult economy.


Regards,
Vinh

 

[Eric Smith]

Jim Granville <jim.granville@designtools.co.nz> writes:

No, but suppose this has a single push button ?
Each spin is going to be close to random, but the designer might be
a tad dissappointed at the correlation _across_ the 3 displays ?

Why would there be a correlation? You hold the button for tens or
hundreds of milliseconds, and the display will cycle through all 216
possible combinations in less than a microsecond. There will be no
measurable correlation between the individual dice unless the counter
doesn't work correctly.

 

[Vinh Pham]

indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I

Why are we assuming that he's simulating six-sided dice? He could be
talking about 1d4 or 1d8. Are there no gamers among us? Hmm then again a
two-handed sword does 3d6 damage, so 1d6 would make sense. I have
underestimated by peers.

--Vinh

 

[Jim Granville]

Eric Smith wrote:

Jim Granville <jim.granville@designtools.co.nz> writes:
No, but suppose this has a single push button ?
Each spin is going to be close to random, but the designer might be
a tad dissappointed at the correlation _across_ the 3 displays ?

Why would there be a correlation? You hold the button for tens or
hundreds of milliseconds, and the display will cycle through all 216
possible combinations in less than a microsecond. There will be no
measurable correlation between the individual dice unless the counter
doesn't work correctly.

You are right - I missread Peter's example, and did not register the
word cascaded.

-jg

 

[Ray Andraka]

no need to. The cycle time is short if clocked fast enough and the human interface injects enough
randomness to achieve a random result. See Peter's post above.

Why seven segment LEDs though? It would be more appropriate to use 7 LEDs arranged like the 'six' and 'one'
sides of the die superimposed.

Chip wrote:

How about using linear feedback shift registers instead of counters.
I've never actually used one so someone correct me if I'm wrong.

They could be driven by a single clock. They each could be
initialized with a different seed and could be long enough to run for
a long time before repeating. They would still be coupled in the
respect that each time the electronic dice is powered up each shift
register will output the same pseudo random sequence. Then a roll
consists of registering some of the lfsr bits when the dice button is
released (the lsfr is still changing while the button is not pressed)
Thus, if you could roll the dice at exactly the same times throughout
an entire game you would get the same (pseuorandom) sequence of dice
values. (But this would be highly unlikely)

lange360@hotmail.com (Amstel) wrote in message news:<56f7756d.0310140824.7d8fe744@posting.google.com>...
Hi to all,

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

I need help urgently ..
Anyone know how to write the program ?

Thanks a lot

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[Vinh Pham]

It's a seven segment display, so it might be up to 1d16

....

between 1d2 and 1d16. Bonus points for only allowing configurations
where an actual polygon would make a legal die (all sides the same
area).

Whew. I was freaking out for a moment there. I thought there was a gap in
my gaming lore, that I had somehow gone through life ignorant of the
16-sided die :_)

 

[Symon]

Ah, the clues were there! 'UK' anywhere in the post is a giveaway!
Bloody island monkeys!
Cheers, Syms.
Peter Alfke <peter@xilinx.com> wrote in message news:<3F8C5BC4.641FA8DA@xilinx.com>...

I admit, my "irony detector" was temporarily asleep, and the German
seriousness took over...
But the scare story was really so neat.
Beware of these super-urgent class assignments!
Peter
==================
Nial Stewart wrote:

Peter Alfke <peter@xilinx.com> wrote in message
news:3F8C3A8E.46F71A51@xilinx.com...
Hi, Jonathan, let me disagree.
I would run this with a single 200 MHz oscillator, and drive the
indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I
am sure that the human hand cannot cheat with fractional microsecond
accuracy.

Peter Alfke

Peter,

Was Jonathan not being ironic?

The original request reeked of 'late assignment'.

Nial.

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Vinh Pham]

How about using linear feedback shift registers instead of counters.

One thing to keep in mind is that the LFSRs we mostly hear about are usually
base-2. So if you're trying to emulate a 6-sided dice, you'll have to pick
another number if an invalid value comes up.

I have seen a base-5 LFSR combined with a base-2 one to create a base-10
one. I suppose you could do the same thing with a base-3 and base-2 for a
six sided dice.

I don't know the math involved in designing non base-2 LFSRs though.
Plugging "lfsr gf(p)" into Google shows some promise but most of it is
pretty math heavy and hard to read. gf() stands for Galois Field. I
suppose there's no real difference with base-2 LFSRs. There's some sort of
polynomial that dictates the taps for the LFSR and your adders are modulo-p
instead of modulo-2 perhaps?

Hopefully someone else can explain it more clearly.


--Vinh

 

[Nicholas C. Weaver]

In article <VA2jb.12306$ZH4.3057@twister.socal.rr.com>,
Vinh Pham <a@a.a> wrote:

indicators with a simple counter ( three mod 6 counters cascaded).
The counter goes through all its 216 values once per microsecond, and I

Why are we assuming that he's simulating six-sided dice? He could be
talking about 1d4 or 1d8. Are there no gamers among us? Hmm then again a
two-handed sword does 3d6 damage, so 1d6 would make sense. I have
underestimated by peers.

It's a seven segment display, so it might be up to 1d16

To do it right, it would have to be a programmable (by DIP switches)
between 1d2 and 1d16. Bonus points for only allowing configurations
where an actual polygon would make a legal die (all sides the same
area).

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[jetmarc]

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

Use an LFSR type pseudo random number generator (PRNG). [you will find
a lot of documentation and VHDL example code in the crypto community,
just google for the two acronyms].

Clock it at an arbitrarty rate. Write VHDL code to convert the
output of the PRNG into dice values. Probably the easiest is to take
3 bits of output to form 1 dice value (0-5 => 1-6) and flag the other
states as illegal. Clocking the PRNG should not stop until all 3 dice
are legal. That solves the bias-by-mapping problem without adding
lots of complexity to the logic.

Write code to output the dice value on the 7-seg LCD.

Write code to stop the PRNG on user request (respecting the legal
state thing mentioned above).

Quite easy once you know how to do the "random" portion of it.

Marc

 

[Ray Andraka]

An LFSR output is only "random" for a single bit out per clock. The
remaining bits are delayed copies of the first bit. In order to use an
LFSR and really have a random stream of 3 bit numbers you'd need to clock
it 3x per die. If you go further to reject 'illegal' combinations, then
you are skewing the probabilities of the legal combinations so that they
are no longer uniform.

jetmarc wrote:

I'm trying to make an electronic dice (3 die). Basically the dice has
3 seven-segment displays and the 3 dice values will run randomly so
that we would always get different values combinations. However I
tried and was unable to write the program in VHDL .

Use an LFSR type pseudo random number generator (PRNG). [you will find
a lot of documentation and VHDL example code in the crypto community,
just google for the two acronyms].

Clock it at an arbitrarty rate. Write VHDL code to convert the
output of the PRNG into dice values. Probably the easiest is to take
3 bits of output to form 1 dice value (0-5 => 1-6) and flag the other
states as illegal. Clocking the PRNG should not stop until all 3 dice
are legal. That solves the bias-by-mapping problem without adding
lots of complexity to the logic.

Write code to output the dice value on the 7-seg LCD.

Write code to stop the PRNG on user request (respecting the legal
state thing mentioned above).

Quite easy once you know how to do the "random" portion of it.

Marc

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759