This is a simple testbench which uses GHDL simulator and OSVVM verification methodology. The goal is to verify the functionality of the gc_negedge (a simple falling edge detector). Through OSVVM, we can achieve randomization of the input data, with randomized seed value. The test cases of the testbench are defined through the different values assigned to the entity's generics.
The generics of this core are the following:
- g_async_rst : Synchronous or asynchronous reset
- g_clock_edge : Clock edge sensitivity of edge detection
Regarding on the values of the above generics, there are the following test cases:
1. TRUE, positive
2. TRUE, negative
3. FALSE, positive
4. FALSE, negative
Assertions are used to provide a self-checking approach. These are:
- The width of the output pulse is always one clock cycle long
- To always detect a negative edge of a falling input data signal
Coverage that is being covered:
- Reset has been asserted
- Input pulse detected
- Output pulse detected
Note: The values of the two last coverage bins are different because the input signal width is not always one clock cycle long
This is a simple testbench which uses GHDL simulator and OSVVM verification methodology. The goal is to verify the functionality of the gc_posedge (a simple positive edge detector). Through OSVVM, we can achieve randomization of the input data, with randomized seed value. The test cases of the testbench are defined through the different values assigned to the entity's generics.
The generics of this core are the following:
- g_async_rst : Synchronous or asynchronous reset
- g_clock_edge : Clock edge sensitivity of edge detection
Regarding on the values of the above generics, there are the following test cases:
1. TRUE, positive
2. TRUE, negative
3. FALSE, positive
4. FALSE, negative
Assertions are used to provide a self-checking approach. These are:
- The width of the output pulse is always one clock cycle long
- To always detect a positive edge of a rising input data signal
Coverage that is being covered:
- Reset has been asserted
- Input pulse detected
- Output pulse detected
Note: The values of the two last coverage bins are different because the input signal width is not always one clock cycle long
Testbench to verify the functionality of the gc_prio_encoder general core. It receives randomized input signals with random seed. It consist of 6 test cases (can be extented to more) regarding the incoming data width. These test cases are:
1. g_width = 1
2. g_width = 3
3. g_width = 7
4. g_width = 16
5. g_width = 31
6. g_width = 128
This testbench is using the simple logic of the priority encoder, like in the RTL code. The result is stored in a vector and then it is being compared with the one which coming from the RTL core.
Assertions are being used for better self-checking purposes. First of all, it checks if there is a mismatch between the output data of the testbench and RTL code. In addition, the other assertion, checks if the generic value is valid (should be 1 or higher).
Testbench to verify the functionality of the gc_pulse_synchronizer general core. It uses GHDL simulator and OSVVM verification methodology. Since in this core there are no generics in the entity, there is only one test case.
The testing process is very simple. It receives random input data (with random seeds). One assertion exist in the testbench to bring self-checking capabilities in it. What it does is that, after the de-assertion of ready_o, checks if, in the next rising edge of clock, the output is HIGH.
Testbench to verify the functionality of the gc_pulse_synchronizer2 general core. This testbench is very similar to the one for gc_pulse_synchronizer. One of the differences is that, this core, has two different reset ports. It uses GHDL simulator and OSVVM verification methodology. Since in this core there are no generics in the entity, there is only one test case.
The testing process is very simple. It receives random input data (with random seeds). One assertion exist in the testbench to bring self-checking capabilities in it. What it does is that, after the de-assertion of ready_o, checks if, in the next rising edge of clock, the output is HIGH.
Testbench to verify the functionality of the gc_reset general core. It uses GHDL simulator and OSVVM verification methodology. This core is using 3 generics in the entity:
- g_clocks : Number of clocks
- g_logdelay : Delay duration
- g_syncdepth : Synchronization depth
A combination of them, create these test cases (there can be even more than them):
- 1, 1, 1
- 2, 2, 2
- 1, 5, 3
- 4, 3, 4
The testing process is very simple. It receives random input data (with random seeds). It uses a similar logic to the one that RTL uses and generates a testbench output. One assertion exist in the testbench to bring self-checking capabilities in it and compare the output of the testbench with the one in the RTL code.
Simple coverage is being covered also:
- Asynchronous reset has been asserted
- Output reset has been asserted
Note: It is advised, for simulation purposes, to keep the generic values quite low in order to see the behavior of the module. For higher generic values, increase the simulation time.
Testbench to verify the functionality of the gc_reset_multi_aasd general core. It uses GHDL simulator and OSVVM verification methodology. This core is using 2 generics in the entity:
- g_clocks : Number of clocks
- g_rst_len : Number of clock ticks (per domain) that the input reset must remain deasserted and stable before deasserting the reset output(s)
A combination of them, create these test cases (there can be even more than them):
- 1, 2
- 1, 4
- 2, 2
- 2, 4
- 1, 1
The testing process is very simple. It receives random input data (with random seeds). It uses a similar logic to the one that RTL uses and generates a testbench output (in case of more than one clocks). One assertion exist in the testbench to bring self-checking capabilities in it and compare the output of the testbench with the one in the RTL code.
Testbench to verify the functionality of the gc_rr_arbiter general core. It uses GHDL simulator and OSVVM verification methodology. The test cases of this testbench arise from the g_size generic and they are : 1, 3, 7, 16, 31, 128.
The testing process is the following: It receives random input data (with random seeds). Two assertions are being used to bring self-checking capabilities in the testbench:
1. Output grant_o is the delayed (by 1 clock cycle) version of grant_comb_o
2. The valid values of grant_comb_o are 0, 1.
An example to the second assertion is the following, for g_size = 3:
req_i grant_o
000 000
001 001
010 010
011 010 / 001
100 100
101 100 / 001
110 100 / 010
111 100 / 010 / 001
Note: It is advised, for simulation purposes, to keep the generic values quite low in order to see the behavior of the module. For higher generic values, increase the simulation time.
Testbench to verify the functionality of the gc_serial_dac general core. It uses GHDL simulator and OSVVM verification methodology. This core is using 4 generics in the entity:
- g_num_data_bits : Number of DAC data word bits, LSBs
- g_num_extra_bits : Number of padding MSBs sent as zeros
- g_num_cs_select : Number of chip select inputs
- g_sclk_polarity : Serial clock polarity (0 for rising, 1 for falling edge)
A combination of them, create these test cases (there can be even more than them):
1. 2, 0, 1, 0
2. 2, 1, 2, 0
3. 4, 4, 2, 0
4. 16,8, 1, 0
5. 2, 0, 1, 1
6. 4, 2, 1, 1
7. 8, 4, 2, 1
8. 16,8, 2, 1
The testbench, receives random input data (with random seeds). It uses a similar logic to the one that RTL uses and generates a testbench output. One assertion exist in the testbench to bring self-checking capabilities in it and compare the output of the testbench with the one in the RTL code.
Simple coverage is being covered also:
- Reset has been asserted
- DAC is not busy
Note: It is advised, for simulation purposes, to keep the generic values quite low in order to see the behavior of the module. For higher generic values, increase the simulation time.
