By Susana Sevilla. ASIC verification engineer at Rydev
susana.sevilla@rydevinc.com
After doing all the modifications described in parts I and II of this blog, we ended up at a dead-end. Errors in parametrized mailboxes were jumping at us, as shown in figure 1. After some researching we found out that there are some typedef issues in Verilator, which have not been successfully implemented yet and apparently not easy to solve when sharing items between components.
Figure 1. Error: Verilator can’t recognize that the CLASSREFDTYPE has already been defined.
We tried re–installing Verilator and z3 solver, cloning the repo again and running <<make verilator_run_pure_sv>>, to no avail.
Testing our test with the uvm branch
We then decided on another approach: using our UVM environment in the uvm_branch being developed. We modified the environment for having only one master and one slave, and used the same test where we sent write transactions followed by read transactions. In this branch we did the same modifications to the interface as in the cases described in parts I and II, and also the same modifications regarding the randomization.
But there was no support for the uvm_event_pool in order to communicate the monitor with the sequencer. Since the test used an event to know when the last written confirmation was received, we decided on deleting the events from the sequence and the monitor, and create an event in the driver. After a write or read transaction is sent to the DUT, the event waits for the response, when the response is received the event is triggered and a new item can be received by the driver.
Since using a typedef for creating a new sequencer as in Figure 2 was not supported, we opted for a class for the new sequencer as shown in Figure 3.
Figure 2. Unsupported typedef.
Figure 3. Supported way to define the new sequencer.
This let us move forward. Other features were then identified as not having support either: set_report_max_quit_count, get_initial_random_seed and enable_print_topology. As these were not essential for running the test, they were removed from the test.
All these modifications made the environment palatable to Verilator, but then errors started to show in the .cpp files, bringing us again to a dead end. After such efforts, we just decided on concluding that Verilator is fine for basic RTL checks using directed and simple testbenches but, as of now, it is just not ready for medium-complex functional verification. We’ll keep you posted on more advances on our explorations as updated versions of Verilator come to life. In the meantime, hold tight and, if necessary and without the funds, resort to DSim (see our blog on that).