Dice Design Exercise

Dice Design

• Random Number Source (random.sv)

  module: random
  input: Clock, nReset
  output: [1:0]Ran

  The random number source must generate a new two bit random number every two clock cycles. For a random number source you should use the 8 bit pseudo-random binary sequence (PRBS) generator shown in the circuit schematic below:

  

  You should implement this sub-module as a structural model.

  Rather than redesign the dtype, you should use the structural dtype model that you have already met in the labs, dtype.sv.

  Note that PRBS generators such as this one, generate only one new pseudo-random bit in each clock cycle (via the XOR/XNOR circuit). Thus if we need a new n bit number, we must wait n clock cyles. In this case we get a new two bit number every two clock cycles.

• Encoder (encoder.sv)

  module: encoder
  input: [2:0]DiceValue
  output: L11, L12, L13, L21, L22, L23, L31, L32, L33

  The encoder takes a three bit binary dice value and produces nine signals which will light the nine LEDs which make up the display according to the dice coding shown below:

  

  Note that 0 and 7 are coded here to give recognizable error states.

  The naming of the 9 output signals is illustrated in the following figure:

  

  You should implement this sub-module as a behavioural model. This module should be synthesizable to produce combinational logic only (no clock, reset, latches or dtypes).

• Control (control.sv)

  module: control
  input: Clock, nReset, [1:0]Ran
  output: [2:0]DiceValue

  The control module produces a new three bit dice value for the encoder every two cycles, based on the two bit random number it recieves from the random number source.

  Note that the two bit number from the PRBS changes every clock cycle but can only be considered random if viewed every second cycle. The implication is that your controller output should remain stable on odd clock cycles and update on even clock cycles.

  The random number determines the direction of the roll of the dice. The dice may roll over to any adjacent side on each such occasion but will not roll to the one non-adjacent side nor will it stay on the same side.

  To help you decide which sides are adjacent you can either make up the dice model below or simply visualise it from this picture:

  

  You should implement this sub-module as a behavioural model. This module should be synthesizable to produce sequential logic. To support this operation it will share the Clock and nReset inputs which feed the Random Number Source unit. Note that the nReset operation should be asynchronous.

  Some designers will want to think of all or part of this module as an implementation of an Algorithmic State Machine (ASM). To help these people some notes have been provided on the mapping of ASM charts to SystemVerilog HDL code.

• Top-level Module (dice.sv)

  module: dice
  input: Clock, nReset
  output: TL, ML, BL, MC, TR, MR, BR

  The top-level module should be a structural model linking the three other modules. Its only inputs should be the Clock and nReset signals. Its outputs are the seven signals to control the LEDs of the dice; TL, ML, BL, MC, TR, MR, BR:

  

  Notes:

  1. the L21 and L23 signals are outputs from the encoder module but not from the top-level module
  2. the names of the outputs from the top-level module do not match the names of the outputs from the encoder

Dice Simulation

• Stimulus and Self Test (dice_stim.sv)

  module: dice_stim
  

  Your stimulus file should provide appropriate stimulus with a $stop; statement every 12 clock cycles. The simulation should not terminate (i.e. there should be no $finish; statement).

  Either of the following simulation commands should invoke your simulation:

      ncverilog  -sv  +gui +ncaccess+r  dice_stim.sv dice.sv control.sv encoder.sv random.sv dtype.sv  +tcl+dice.tcl
  
      ncverilog  -sv  +gui +ncaccess+r  -y .  +libext+.sv  dice_stim.sv  +tcl+dice.tcl
  

  N.B. The second version uses the "-y ." option to specify that the current directory "." is the library directory.

  It is important that your file names, port names and simulation commands match those described in this document to allow for automated testing.

  Note that, in the past, some students have included files in their simulations using the "`include" directive. Since this relies on knowledge of the location of files, it fails when files are moved into new locations for automated testing.

  This file is also the location for any self-test code that you write. This code is optional but allows you to test the dice without spending hours staring at waveforms. As an example it might output the dice value after each roll using a "$display" command and use one or more "assert" statements to flag illegal rolls (here we think of a roll to an adjacent side as a legal roll e.g 6->4 while a roll to a non adjacent side e.g. 6->1 or a roll to the same side e.g 6->6 is illegal). Your test code should not make use of information specific to your design. Thus it should be possible to use it to test any design against the specification.

  Using the following command to invoke the NC-Verilog simulator without a graphical interface should display the output from your self-test code.

      ncverilog  -sv  -q  -y .  +libext+.sv  dice_stim.sv
  

  Since this file is only a testbench, it is not necessary for code in this module to be synthesizable.

• Monitoring (dice.tcl)

  You should provide a SimVision command script along with your design so that I can reproduce your simulation. The file should provide a waveform display and a registers display.

  The waveform display should include the dice primary I/O together with important internal signals such as the generated random number and the dice value before coding.

  The registers display should include the final dice output. You should arrange the outputs in the pattern of the dice LEDs.

Submission

• Deliverables

  Prior to submission, the following files should exist in a directory named ~/design/verilog/dice

  • random.sv
  • dtype.sv (this should simply be a copy of the file provided to you, dtype.sv)
  • encoder.sv
  • control.sv
  • dice.sv
  • dice_stim.sv
  • dice.tcl

  • info.txt

    info.txt is a file indicating the first 24 results produced by your dice (where a new result is recorded each time a $stop; statement is reached). This should be different for each dice design, but will be the same for each simulation run since the PRBS is loaded with the same seed (0) at the beginning of each simulation. A script has been created to help you generate this file in the correct format. Simply type

        infogen
    

    in a directory containing the model files: random.sv, dtype.sv, encoder.sv, control.sv and dice.sv.

• Preparation for Handin

  Run the following script to collect the files for handin:

      prepare_dicd desex2
  

  The script will create a single file:

      ~/design/verilog/dice/handin.tar
  

  for the next stage of handin.

• Electronic Handin

  Use the electronic handin system to submit the handin.tar file.

• Deadline

  The deadline for this design exercise is 19:00 on Wednesday 13^th November.

  No documentation is required for this exercise other than an up to date log book.