Notes on verification

Today I was bitten twice by the same issue: randomization .   When you randomize something you should always assert the randomization. This will allow you to find the source of the problem much quicker. I lament the fact that UVM sequence macros do not assert the randomization by default. Instead they issue a warning with id RNDZFLD .   By the way, in case the randomization failed, you can rerun the simulation with the -solvefaildebug switch if running Modelsim/Questa. This will give you an idea why the solver was unable to satisfy your constraints.

Back when I started using UVM, I had no use for a register model for the specific unit I was testing. As such, sequences were written which needed a sequencer which would hand the items in the sequence to the driver. Over time, we moved to use the register model and its uvm_reg_sequence. At first I would pass the sequencer of the agent responsible for sending the transaction to the sequence. But then I discovered this to be error prone: sometimes the sequencer would not exist because the agent had been declared to be UVM_PASSIVE, in another case I needed to dig deep to find the sequencer to be used. Looking at the code I also discovered that while sending a protocol sequence to a specific sequencer made a lot of sense, a register model (or more specifically a register map) would already be bound by the environment's maintainer to the correct sequencer causing the reg sequence to disregard the sequencer argument given to it and accessing the register according to the map's def