In this directory, we provide commonly used interfaces used to construct
testbenches for DV. These interfaces are instantiated inside
tb module for
connecting dut signals. They are described in detail below.
This is a passive clock interface that is used to wait for clock events in
testbenches. This interface has two clocking blocks,
synchronizing to positive and negative clock edges, respectively. The interface
also has the following tasks:
wait_clks: waits for specified number of positive clock edges
wait_n_clks: waits for specified number of negative clock edges
clk_if, this interface can generate a clock and a reset signal. These
are connected as
inout signals and the interface observes them passively
set_active function is called.
clk_if, this interface has clocking blocks
wait_n_clks utility tasks. It also has
wait_for_reset: wait for a reset signaled on
To generate a clock signal, call
set_active at the start of the simulation.
This is typically called from an
initial block in the testbench. To configure
the frequency and duty cycle of the generated clock, use the following
set_freq_khz: set the clock frequency in MHz / KHz. This is 50MHz by default.
set_period_ps: set the clock period in picoseconds. This is 20_000ps by default (giving a clock period of 50MHz).
set_duty_cycle: set the duty cycle (as a percentage: 1 - 99). This is 50 by default.
The clock can also have jitter added. This is generated as an offset in picoseconds added to randomly selected clock half-periods. It can be enabled and configured with:
set_jitter_chance_pc: set the percentage probability of adding a jitter to a given half-period. By default, this is 0 and the clock has no jitter.
set_max_jitter_ps: set the maximum jitter to add to each clock half-period in picoseconds. This is 1000ps (1 ns) by default.
To start and stop the clock or apply a reset, use the following tasks. These
will have no effect if
set_active has not been called.
start_clk: start the clock. The clock is started by default, so this task is only needed after a call to
stop_clk: stop / gate the clk
apply_reset: signal a reset on
rst_n. The length of this reset and whether it is synchronous or not can be configured with arguments to the function.
This parameterized interface provides the ability to drive or sample any signal in the DUT.
interface pins_if #( parameter int Width = 1 ) ( inout [Width-1:0] pins );
By default, it behaves as a passive interface. The values of the pins can be read with the following functions:
sample: sample and return all the pin values
sample_pin: sample just the given pin
The interface can also be configured to drive, pull up, or pull down its outputs. To do this, call
drive_pin: Drive the output to the given value.
drive_en_pin: Configure output enable; when enabled, this drives value previously stored by a call to
set_pullup_en_pin: Configure pull-up setting. If true and output enable is false, drives the output to
set_pulldown_en_pin: Configure pull-down setting. If true and both output_enable and pull-up are false, drives the output to
The diagram below gives a schematic view of
pins_if. The driver shown is
replicated for each bit.
The IPs in the entropy subsystem (
EDN) raise fatal alerts if they
detect that data is lost in one of the intermediate FIFOS, either through:
- Write errors (Overflow) wvalid_i asserted when full
- Read errors (Underflow) rready_i asserted when empty (i.e. rvalid_o == 0)
- State errors: Anomalous behavior rvalid_o deasserted (FIFO is not empty) when full
Furthermore some instances of prim packer fifo’s also raise recoverable alerts if firmware tries to write data to it when it is not ready.
The events described above need not be treated as errors in general purpose designs.
In many general designs where the fifo is capable of applying backpressure (stalling
the read or write inputs) these do not have to be an error. One could in principal
only signal an alert if it is observed that data was indeed lost (e.g., if
deasserted or data changes before
wready_o is high). However most of the entropy complex
fifo stages do not respond to such backpressure, and thus the conditions above do
indicate a loss of data.
The entropy_subsys_fifo_exception_if.sv has pins that can map either to synchronous
FIFOs or to packer fifos. Though some interface ports will be unused in any case
the interface parameter
IsPackerFifo indicates which ports to use (True for
packer FIFOs or False for synchronous FIFOs.
The interface then generates error pulses in the
mon_cb clocking block under
mon_cb.error_pulses, which has one line per possible error condition.
The enumeration entropy_subsys_fifo_exception_pkg::fifo_exception_e lists the
types of exceptions and provides the mapping to the corresponding error pulse line.