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 pressure sensor module (I2C Pressure Sensor) and inputs from buttons (Mode, Trip) plus either one or two display outputs (LCD, OLED).
The LCD display is an 8 character x 1 row type.
The sensor module uses an inter-integrated circuit (I2C) bus for communication, with the chip acting as master and the sensor acting as slave. The following figure shows a read request for three data bytes from an I2C device with address 00010002.
In this diagram the yellow area indicates the time when the master controls the SDA line while the blue area indicates the time when the slave controls the SDA line. After each set of 8 bits there is an acknowledge cycle (SDA=0 indicates acknowledge - ACK). After the final 8 bits, the master sends NACK (SDA=1 indicates not acknowledge - NACK) indicating that it will not be reading any further data.
This three byte read format can be used to retrieve a 24-bit data value from the sensor. In the case of a simplified sensor (see below), this is the only format that is used.
In this example, the simplified sensor is being accessed and the three returned bytes
(CD16, 8B16, 0116)
represent a single 24-bit pressure value:
| 018BCD16 | = | 10132510 | Pascals | |
| = | 1013.25 | mb |
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 8 Character Display module can be found in the SystemVerilog file:
system/lcd_1x8_display.sv
A minimal behavioural model (not synthesizable) of the OLED module can be found in the SystemVerilog file:
system/oled_display.sv
A minimal behavioural model (not synthesizable) of the Simple Pressure Sensor module can be found in the SystemVerilog file:
system/simple_pressure_sensor.sv
A minimal behavioural model (not synthesizable) of the BMP390 module can be found in the SystemVerilog file:
system/bmp390.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_oled
This option indicates that the model being simulated supports an OLED display.
+define+use_simple_sensor
This option indicates that the the BMP390 model should be replaced by the simplified version which returns pressure values in Pascals (100 Pascals = 1 millibar) (system/simple_pressure_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/lcd_1x8_display.sv system/simple_pressure_sensor.sv system2/ nedit system2/lcd_1x8_display.sv system2/simple_pressure_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
28-1-2025