OpenCores
URL https://opencores.org/ocsvn/yifive/yifive/trunk

Subversion Repositories yifive

[/] [yifive/] [trunk/] [caravel_yifive/] [verilog/] [dv/] [README.md] - Blame information for rev 2

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 2 dinesha
18
 
19
# Simulation Environment Setup
20
 
21
There are two options for setting up the simulation environment:
22
 
23
* Pulling a pre-built docker image
24
* Installing the dependecies locally
25
 
26
## 1. Docker
27
 
28
There is an available docker setup with the needed tools at [efabless/dockerized-verification-setup](https://github.com/efabless/dockerized-verification-setup)
29
 
30
Run the following to pull the image:
31
 
32
```
33
docker pull efabless/dv_setup:latest
34
```
35
 
36
## 2. Local Installion (Linux)
37
 
38
You will need to fullfil these dependecies:
39
 
40
* Icarus Verilog (10.2+)
41
* RV32I Toolchain
42
 
43
Using apt, you can install Icarus Verilog:
44
 
45
```bash
46
sudo apt-get install iverilog
47
```
48
 
49
Next, you will need to build the RV32I toolchain. Firstly, export the installation path for the RV32I toolchain,
50
 
51
```bash
52
export GCC_PATH=
53
```
54
 
55
Then, run the following:
56
 
57
```bash
58
# packages needed:
59
sudo apt-get install autoconf automake autotools-dev curl libmpc-dev \
60
    libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo \
61
    gperf libtool patchutils bc zlib1g-dev git libexpat1-dev
62
 
63
sudo mkdir $GCC_PATH
64
sudo chown $USER $GCC_PATH
65
 
66
git clone https://github.com/riscv/riscv-gnu-toolchain riscv-gnu-toolchain-rv32i
67
cd riscv-gnu-toolchain-rv32i
68
git checkout 411d134
69
git submodule update --init --recursive
70
 
71
mkdir build; cd build
72
../configure --with-arch=rv32i --prefix=$GCC_PATH
73
make -j$(nproc)
74
```
75
 
76
# Running Simulation
77
 
78
## Docker
79
 
80
First, you will need to export a number of environment variables:
81
 
82
```bash
83
export PDK_PATH=
84
export CARAVEL_ROOT=
85
export UPRJ_ROOT=
86
```
87
 
88
Then, run the following command to start the docker container :
89
 
90
```
91
docker run -it -v $CARAVEL_ROOT:$CARAVEL_ROOT -v $PDK_PATH:$PDK_PATH -v $UPRJ_ROOT:$UPRJ_ROOT -e CARAVEL_ROOT=$CARAVEL_ROOT -e PDK_PATH=$PDK_PATH -e UPRJ_ROOT=$UPRJ_ROOT -u $(id -u $USER):$(id -g $USER) efabless/dv_setup:latest
92
```
93
 
94
Then, navigate to the directory where the DV tests reside :
95
 
96
```bash
97
cd $UPRJ_ROOT/verilog/dv/
98
```
99
 
100
Then, follow the instructions at [Both](#both) to run RTL/GL simulation.
101
 
102
## Local
103
 
104
You will need to export these environment variables:
105
 
106
```bash
107
export GCC_PATH=
108
export PDK_PATH=
109
```
110
 
111
Then, follow the instruction at [Both](#both) to run RTL/GL simulation.
112
 
113
## Both
114
 
115
To run RTL simulation for one of the DV tests,
116
 
117
```bash
118
cd 
119
make
120
```
121
 
122
To run gate level simulation for one of the DV tests,
123
 
124
```bash
125
cd 
126
SIM=GL make
127
```
128
 
129
# User Project Example DV
130
 
131
The directory includes four tests for the counter user-project example:
132
 
133
### IO Ports Test
134
 
135
* This test is meant to verify that we can configure the pads for the user project area. The firmware configures the lower 8 IO pads in the user space as outputs:
136
 
137
        ```c
138
        reg_mprj_io_0 =  GPIO_MODE_USER_STD_OUTPUT;
139
        reg_mprj_io_1 =  GPIO_MODE_USER_STD_OUTPUT;
140
        .....
141
        reg_mprj_io_7 =  GPIO_MODE_USER_STD_OUTPUT;
142
        ```
143
 
144
* Then, the firmware applies the pad configuration by enabling the serial transfer on the shift register responsible for configuring the pads and waits until the transfer is done.
145
        ```c
146
        reg_mprj_xfer = 1;
147
        while (reg_mprj_xfer == 1);
148
        ```
149
 
150
* The testbench success criteria is that we can observe the counter value on the lower 8 I/O pads. This criteria is checked by the testbench through observing the values on the I/O pads as follows:
151
 
152
        ```verilog
153
        wait(mprj_io_0 == 8'h01);
154
        wait(mprj_io_0 == 8'h02);
155
        wait(mprj_io_0 == 8'h03);
156
        ....
157
        wait(mprj_io_0 == 8'hFF);
158
        ```
159
 
160
* If the testbench fails, it will print a timeout message to the terminal.
161
 
162
### Logic Analyzer Test 1
163
 
164
* This test is meant to verify that we can use the logic analyzer to monitor and write signals in the user project from the management SoC. Firstly, the firmware configures the upper 16 of the first 32 GPIO pads as outputs from the managent SoC, applies the configuration by initiating the serial transfer on the shift register, and writes a value on the pads to indicate the end of pad configuration and the start of the test.
165
 
166
        ```c
167
        reg_mprj_io_31 = GPIO_MODE_MGMT_STD_OUTPUT;
168
        reg_mprj_io_30 = GPIO_MODE_MGMT_STD_OUTPUT;
169
        .....
170
        reg_mprj_io_16 = GPIO_MODE_MGMT_STD_OUTPUT;
171
 
172
        reg_mprj_xfer = 1;
173
        while (reg_mprj_xfer == 1);
174
 
175
        // Flag start of the test
176
        reg_mprj_datal = 0xAB400000;
177
        ```
178
 
179
        This is done to flag the start/success/end of the simulation by writing a certain value to the I/Os which is then checked by the testbench to know whether the test started/ended/succeeded. For example, the testbench checks on the value of the upper 16 of 32 I/Os, if it is equal to `16'hAB40`, then we know that the test started.
180
 
181
        ```verilog
182
        wait(checkbits == 16'hAB40);
183
        $display("LA Test 1 started");
184
        ```
185
 
186
* Then, the firmware configures the logic analyzer (LA) probes `[31:0]` as inputs to the management SoC to monitor the counter value, and configure the logic analyzer probes `[63:32]` as outputs from the management SoC (inputs to the user_proj_example) to set the counter initial value. This is done by writing to the LA probes enable registers.   Note that the output enable is active low, while the input enable is active high.  Every channel can be configured for input, output, or both independently.
187
 
188
 
189
        ```c
190
        reg_la0_oenb = reg_la0_iena = 0xFFFFFFFF;    // [31:0] inputs to mgmt_soc
191
        reg_la1_oenb = reg_la1_iena = 0x00000000;    // [63:32] outputs from mgmt_soc
192
        ```
193
 
194
* Then, the firmware writes an initial value to the counter through the LA1 data register. Afte writing the counter value, the LA probes are disabled to prevent the counter write signal from being always set to one.
195
 
196
        ```c
197
        reg_la1_data = 0x00000000;     // Write zero to count register
198
        reg_la1_oenb  = reg_la1_iena = 0xFFFFFFFF;     // Disable probes
199
        ```
200
 
201
* The firmware then waits until the count value exceeds 500 and flags the success of the test by writing `0xAB41` to pads 16 to 31.  The firmware reads the count value through the logic analyzer probes `[31:0]`
202
 
203
        ```c
204
        if (reg_la0_data > 0x1F4) {          // Read current count value through LA
205
                reg_mprj_datal = 0xAB410000; // Flag success of the test
206
                break;
207
        }
208
        ```
209
 
210
### Logic Analyzer Test 2
211
 
212
* This test is meant to verify that we can drive the clock and reset signals for the user project example through the logic analyzer. In the [user_proj_example](verilog/rtl/user_proj_example.v) RTL, the clock can either be supplied from the `wb_clk_i` or from the logic analyzer through bit `[64]`. Similarly, the reset signal can be supplied from the `wb_rst_i` or through `LA[65]`.  The firmware configures the clk and reset LA probes as outputs from the management SoC by writing to the LA2 enable register.
213
 
214
        ```c
215
        reg_la2_oenb  = reg_la2_iena = 0xFFFFFFFC;      // Configure LA[64] LA[65] as outputs from the cpu
216
        ```
217
 
218
* Then, the firmware supplies both clock reset signals through LA2 data register. First, both are set to one. Then, reset is driven to zero and the clock is toggled for 6 clock cycles.
219
 
220
        ```c
221
        reg_la2_data = 0x00000003;      // Write one to LA[64] and LA[65]
222
        for (i=0; i<11; i=i+1) {        // Toggle clk & de-assert reset
223
                clk = !clk;
224
                reg_la2_data = 0x00000000 | clk;
225
        }
226
        ```
227
* The testbench success criteria is that the firmware reads a count value of five through the LA probes.
228
        ```c
229
        if (reg_la0_data == 0x05) {
230
                reg_mprj_datal = 0xAB610000;   // FLag success of the test
231
        }
232
        ```
233
 
234
### Wishbone Test
235
 
236
* This test is meant to verify that we can read and write to the count register through the wishbone port. The firmware writes a value of `0x2710` to the count register, then reads back the count value after some time. The read and write transactions happen through the management SoC wishbone bus and are initiated by either writing or reading from the user project address on the wishbone bus.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.