Electronic Dice ( 3 die ) 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: snipped-for-privacy@doulos.com Fax: +44 (0)1425 471573 Web:

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

J>

accuracy.

Peter,

Was Jonathan not being ironic?

The original request reeked of 'late assignment'.

Nial.

------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design

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:

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.

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)

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

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

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.

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

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

-jg

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

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 appr> How about using linear feedback shift registers instead of counters.

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

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

...

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

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

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 snipped-for-privacy@andraka.com

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