Scoreboard for checking interrupts !!!

Architecting a good interrupt monitor and an interrupt scoreboard is very essential to hit bugs and close coverage on the interrupt logic of the design.The architecture is very simple, you need to have a shadow register for your interrupt status register and predict the interrupt by writing in to this register, the predication should be done in the transactor based on the transaction class attributes for a regular transaction, error condition ect .. The interrupt scoreboard should reside on the passive interrupt monitor which reads the shadow register as well as the original hardware register and the mask and makes a comparison on the expected interrupts and flags an error if the interrupt is mismatching. The monitor should have options to clear the interrupt when it is available or accumulate interrupt and clear it when it is required. At end of the simulation a comparison of shadow register and real interrupt status register needs to be done to check if all the expected interrupts have arrived and flag appropriate error messages.

Interfacing CRV environment with procedural environments !!!

One of interesting challenges in verification is building constraint random verification environment on top of an existing code which is a procedural code.The challenges are unique to each of the environments; simplest solution is wrapping the procedural code in a transactor which is connected to a channel which interfaces with the constraint random generators. Transaction object attributes are mapped to different functionality in the procedural code.

Tips to improve constraint solver performance !!!

Performance issues are very hard to debug, especially to find the root cause of the issue. If the constraint solving time is at unacceptable limits, the first area to debug is the bidirectional nature of the constraint implemented. quickly review the constrains that does not require bi-directional functionality and convert constraints from bidirectional to unidirectional using void termination or solve before, also reduce the number of constraints solved at a single point of time to improve performance.

Structures and union in system verilog !!!

VERA/NTB users migrating to system verilog have a tendency of not using structures and union construct in system verilog when architecting or implementing a system verilog verification environment. The reason being, this constructs are not available in VERA/NTB. Struct is pretty useful construct to group fields which are logically related to each other. It helps to organize you code. The union construct is very similar to a structure, but only one of the fields will be valid at a given point of time. Using packed struct and packed unions helps to organize fields in the memory without gaps, which in turn results in faster access to memory and results in faster simulation time.

Factory replacement in the scenario generator scenario using ‘.using’ gotcha !!!

When you want to do a factory replacement of a transaction class in your scenario,we assign the factory to .using.

Scenario.using=transaction_factory;

The gotcha in this factory replacement is we need to implement the allocate() and copy() methods in the extended class for the factory replacement to work.


Many times i have seen people including myself spending time debugging their code when using “.using” for factory replacement as they are not aware of the gotcha.Maybe the RVM/VMM documentation should have this requirement highlighted so that the user can easily understand this requirement.

Atomic generator using allocate() !!!

RVM/VMM atomic and scenario generator randomizes a blueprint pattern which is assigned with the extended class (factory) , the copy of the randomized blueprint is pushed into the channel. Most of the RVM/VMM users use this approch in there custom generators. Is there a different way of implementing your atomic generator without using a copy() method ?. The answer is yes, following method can be used to generate atomic transaction without using copy().




For the above code to work you need to implement the allocate method in your extended class. The extended class is assigned to the factory before the start_xactor() method is called.

ASIC verification tasks verification engineers dislike the most !!!

I was having a friendly discussion with few of my fellow verification engineers, we were discussing about the verification tasks they dislike the most. The conclusion from the discussion was they disliked verification tasks which were laborious, which requires manual effort and had very little learning opportunity. The verification task they disliked are as follows.


1)Language migration without the help of a commercial language conversion tool
2)Code coverage analysis and identification of code coverage exclusions.
3) “X” tracing while debugging gate level simulation.
4)Release management ( Tagging the release code ,Triggering regression and debug of regression results ,becomes messy when more that 25 people are involved and release management is handled by a single person)
5)Working on outdated technology which is away from the verification market movement.