2 digit dice (random counter 1 - 6)

Discussion in 'VHDL' started by Nathan Osborne, Nov 19, 2012.

  1. 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
     
    Nathan Osborne, Nov 19, 2012
    #1
    1. Advertising

  2. Nathan Osborne

    KJ Guest

    On Monday, November 19, 2012 4:01:42 PM UTC-5, njozzy wrote:
    > 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
     
    KJ, Nov 20, 2012
    #2
    1. Advertising

  3. Nathan Osborne

    Guest

    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
     
    , Nov 20, 2012
    #3
  4. Nathan Osborne

    njozzy Guest

    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
     
    njozzy, Nov 20, 2012
    #4
  5. Nathan Osborne

    rickman Guest

    On 11/20/2012 9:40 AM, njozzy wrote:
    > 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
     
    rickman, Nov 20, 2012
    #5
  6. Nathan Osborne

    njozzy Guest


    >
    >
    > 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
     
    njozzy, Nov 20, 2012
    #6
  7. Nathan Osborne

    Guest

    Am Dienstag, 20. November 2012 23:59:55 UTC+1 schrieb 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



    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
     
    , Nov 21, 2012
    #7
  8. On 21 Nov., 09:48, 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
     
    Thomas Stanka, Nov 21, 2012
    #8
  9. Nathan Osborne

    rickman Guest

    On 11/21/2012 10:59 AM, Thomas Stanka wrote:
    > On 21 Nov., 09:48, 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
     
    rickman, Nov 21, 2012
    #9
  10. Nathan Osborne

    Gabor Guest

    Thomas Stanka wrote:
    > On 21 Nov., 09:48, 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
     
    Gabor, Nov 21, 2012
    #10
  11. Nathan Osborne

    Guest

    Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:
    > On 21 Nov., 09:48, 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. 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
     
    , Nov 22, 2012
    #11
  12. Nathan Osborne

    Gabor Guest

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

    > 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, Nov 22, 2012
    #12
  13. Nathan Osborne

    Guest

    Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:
    > On 11/22/2012 2:53 AM, wrote:
    >
    > > Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

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


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

    >
    > >
     
    , Nov 23, 2012
    #13
  14. Nathan Osborne

    rickman Guest

    On 11/23/2012 1:53 AM, wrote:
    > Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:
    >> On 11/22/2012 2:53 AM, wrote:
    >>
    >>> Am Mittwoch, 21. November 2012 16:59:36 UTC+1 schrieb Thomas Stanka:

    >>
    >>>> On 21 Nov., 09:48, 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
     
    rickman, Nov 23, 2012
    #14
  15. Nathan Osborne

    Guest

    Am Freitag, 23. November 2012 22:45:25 UTC+1 schrieb rickman:
    > On 11/23/2012 1:53 AM, wrote:
    >
    > > Am Donnerstag, 22. November 2012 17:17:24 UTC+1 schrieb Gabor:

    >
    > >> On 11/22/2012 2:53 AM, wrote:

    >
    > >>

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

    >
    > >>

    >
    > >>>> On 21 Nov., 09:48, 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
     
    , Nov 26, 2012
    #15
  16. Nathan Osborne

    njozzy Guest

    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!
     
    njozzy, Nov 28, 2012
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fangs
    Replies:
    3
    Views:
    9,938
    darshana
    Oct 26, 2008
  2. Tomi Lindberg

    Dice probability problem

    Tomi Lindberg, Apr 4, 2006, in forum: Python
    Replies:
    11
    Views:
    743
    Antoon Pardon
    Apr 6, 2006
  3. Richard Buckle
    Replies:
    4
    Views:
    452
    Steven Bethard
    Sep 13, 2006
  4. globalrev
    Replies:
    4
    Views:
    810
    Gabriel Genellina
    Apr 20, 2008
  5. VK
    Replies:
    15
    Views:
    1,320
    Dr J R Stockton
    May 2, 2010
Loading...

Share This Page