Electronic Dice ( 3 die ) In VHDL

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

"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.

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.

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

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

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

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!

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

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.

> 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