The simulation environment for the VLSI Design Project consists of a number of SystemVerilog files which model a basic system built around the sports altimeter under test:
The system includes inputs from an altimeter sensor module (Altimeter SPI Slave) and inputs from buttons (Mode, Trip) plus either one or two display outputs (LED, LCD).
The LED display is a seven-segment, common-cathode, multiplexed type. Thus a segment is lit if and only if the relevant segment line is taken high and the relevant digit line is taken low. The following figure shows the waveforms required to display "P1013" (indicating a pressure of 1013mb) on the seven segment display.
The sensor module uses a serial peripheral interface (SPI) bus for communication, with the chip acting as master and the sensor acting as slave. The following figure shows an 8-bit command (C[7:0]) being sent to the slave which returns a 24-bit data value (D[23:0]).
This 8-bit + 24-bit format is used by the sensor module for ADC commands. In the case of a simplified slave (see below), this is the only format that is used.
The diagram below shows the hierarchy of the SystemVerilog models that make up the system:
Note that there are no altimeter DFT signals (Test, SDI, SDO) in the diagram. These signals may optionally be supported by the environment but they will not be used in the initial simulations and so are not shown here.
The hierarchy of the design is defined within the top-level module and testbench file which instances the sports altimeter and display modules:
system/system.sv
A minimal behavioural model (not synthesizable) of the Seven Segment Display module can be found in the SystemVerilog file:
system/led_display.sv
A minimal behavioural model (not synthesizable) of the LCD module can be found in the SystemVerilog file:
system/lcd_display.sv
A minimal behavioural model (not synthesizable) of the Simple Altimeter Sensor module can be found in the SystemVerilog file:
system/simple_altimeter_sensor.sv
A minimal behavioural model (not synthesizable) of the MS5803-02BA module can be found in the SystemVerilog file:
system/ms5803_02ba.sv
A behavioural model (not synthesizable) of the sports altimeter pad ring can be found in the SystemVerilog file:
system/altimeter.sv
This model is merely a shell which simulates the pad ring and which instances the core sports altimeter model (alt_core). This pad ring file is only used in initial behavioural simulations when no structural model of the pad ring exist.
Initialise your environment using the following command:
init_chip_examplethis command will
Using the following command, you can investigate the operation of the sports altimeter:
./simulate <model_dir> <simulation_time>
To run a simulation of a model in the behavioural directory for 100 seconds you would type:
./simulate behavioural 100s
-gate
-sdf sdf_file
You can use this and other "-" options by adding them after the word simulate
on the command line.
e.g. to run a 10 second gate-level simulation with timing annotation
based on the gate_level/altimeter.sdf SDF file
you might type:
./simulate -gate -sdf gate_level/altimeter.sdf gate_level 10s
-no_graphics
This can be really helpful if your simulation outputs information on the console.
+define+clock_period=t
This option allows the period of the system clock to be customised if the design to be simulated will not work with the default 32.768kHz clock.
You can use this and other "+" options by adding them on to the end of the
simulate command line.
e.g. to run a 1000 second behavioural simulation with a 500kHz clock (period = 2µs)
you might type:
./simulate behavioural 1000s +define+clock_period=2us
Note that setting a fast clock on a system-on-chip design can lead to excessively long simulation times especially for post-layout simulations. The simulation above with an apparently modest clock speed will require the simulation of 500 million clock cycles and will take approximately 15 times longer to simulate than a similar design which supports the default clock period. Keeping simulation times short encourages good testing practice and results in fewer mistakes in fabricated chips.
+define+num_modes=n
+define+Moden=mode_name
The num_modes option tells the simulator how many modes can be reached by pressing the mode button. The Moden options describe the order and names of the reachable modes. For example, the following options define 2 modes named Pressure and Altitude:
+define+num_modes=2
+define+Mode0=Pressure
+define+Mode1=Altitude
+define+include_lcd
This option indicates that the model being simulated supports an LCD display.
+define+use_simple_sensor
This option indicates that the the MS5803-02BA model should be replaced by the simplified version which returns pressure values in millibars (system/simple_altimeter_sensor.sv).
+define+no_scan_signals
This option indicates that the model being simulated does not support scan path signals (Test, SDI, SDO).
+define+stimulus=<stimulus_filename>
This option indicates that the simulation should use the stimulus information found in a custom stimulus file file. For example, the following option takes the custom stimulus from the system2/mountain1.sv stimulus file:
+define+stimulus=system2/mountain1.sv
+define+special_monitor
This option indicates that the simulation should use the advanced monitoring information found in a monitor.sv file in the model directory.
In addition, an options.sv file can be used to set specify default options for the the model. The example options.sv file specifies that no scan path is supported in the example model. In this case appending +define+no_scan_signals to the simulate command will have no effect.
(note that an uncustomised template for this file can be found in the system directory: system/options.sv)
For your own HDL design, copy the example files to a new directory:
cp -r example behaviouralThen edit the files in the new directory to reflect your design. You can simulate your design using a command such as:
./simulate behavioural 20s +define+stimulus=system2/mountain1.sv +define+special_monitorYou can also customise the display and sensor modules by placing copies in the system2 directory:
cp system/led_display.sv system/simple_altimeter_sensor.sv system2/ nedit system2/led_display.sv system2/simple_altimeter_sensor.sv &
Note that you should not need to edit any files within the system directory. Making any changes in these files is likely to result in simulation failures during automated post-submission testing.
Iain McNally
21-2-2024