Sunday, June 29, 2014

Shift left and Reuse in verification

SNUG India 2014 was a jam packed event! All sessions including the keynotes, papers, tutorials and the design expo were full with engineers pouring in huge numbers. Follow up questions during the presentations and curiosity of the engineers during the expo to understand the solutions from partners were clear indicators of the value these conferences bring in apart from the freebies :) 

Papers on the first day of Verification track focused on the 'Shift Left' approach viz confirming that the design is an exact representation of the spec by uncovering the issues early in the design cycle. The first 3 papers discussed involvement of acceleration/prototyping to enable early SW development and validation of the design in parallel to verification. The 4th paper talked about how the X’s of GLS can be stimulated at RTL to save time & avoid ECOs. While shifting left helps in achieving the goals faster, it is equally important to deploy tools & flows improving 'Reuse'. This was the gist of papers presented on the second day where users shared their experience with enhanced scalability and reusability on different aspects of the verification paradigm be it Formal, low power or IP and SoC verification. 

‘Shift left’ & ‘Reuse’ are interesting concepts sure to reap wonders when applied in conjunction! Really? Let’s see.

Reuse in verification is achieved predominantly through VIPs and test scenarios. 

Expectations from the VIP are not only limited to reuse in the context of IP at block or SoC level simulations. There is a need to have VIPs architected in such a way so as to be reused while porting the target design to a prototyping or emulation platform. If it is the system bus, the VIP needs to be partitioned such that the timed portion of the VIP can move into the box while the untimed portion still continues to be on the work station. SCEMI protocol enables the required communication between the host and the target box. If the VIP is a model for a peripheral sitting outside the chip, it can either fully reside inside the box if everything is to be programmed through the corresponding host IP or else have the same partitioning as the system bus VIP. While the benefits of moving to faster platforms are obvious, the challenges to enable this transition are multi-fold. Porting the design to a target box demands a struggle with partitioning amidst the complexity arising due to multiple clock and power domains. Though the industry has evolved to a large extent on these aspects, architecting and developing verification code that is portable between simulation and emulation is still in its infancy. 

VIPs are available off the shelf but a lot of test development today still happens with home grown test plan and test suite with reuse from what is provided as part of the VIP. Given that the ultimate verification goal is to have a functional SoC with minimal probability of a design bug, C based tests play an important role in achieving it. These tests need to be defined & developed in a planned fashion so as to enable reuse at simulation, emulation and even for Si bring up. A well thought about strategy can actually enable the first level of test development right at the IP stage where a model of the processor can be plugged as part of the IP test bench enabling early test development. Once this suite is ready, complex cases can be covered either with a detailed use case test plan and/or deployment of tools that enable test definition and development in an automated manner. With HW SW teams working in silos and probably in different geographies, a comprehensive solution that converges the two is quite difficult to achieve.

To realize the above there is a need to conceive the end picture, enable development of the pieces and finally connecting the dots to bring up multiple platforms early enough in the ASIC design cycle.

Sunday, June 15, 2014

Sequences in UVM1.2

This post concludes our date with sequences in UVM with a quick overview on modifications related to sequences in UVM1.2. UVM that came out with an EA version in 2010 received mass adoption and has matured by the day since then. The working group is all set with another major release(UVM1.2) that should be out anytime. It opened up for public review during DVCON 2014. You may want to dabble with this release and share your feedback here. Given the wide adoption and maturity level, the plan further is to probably take it to IEEE. Victor from eda playground shared interesting insights on what’s new in the UVM1.2 release.  Given below are 4 important changes related to sequences in UVM1.2 –

#1 Setting default sequence from command line [Mantis – 3741]

A new plusarg has been added to the command line to allow setting of default_sequence that the sequencer executes during the start phase. With this change the user can have 1 test with default sequence that can be modified from command line thereby avoiding redundant test development just for changing the default sequence. You can also run regressions by replacing the default sequence with a sequence library (remember sequence library is derived from uvm_sequence).

How was this done in UVM1.1?


Additional control in UVM1.2?

+uvm_set_default_sequence = <seqr>,<phase>,<sequence>

How does it affect current code?

Existing code works without change while you move to UVM1.2. Users are free to choose either of the above. If both are present in the code the result may be a function of phase.

#2 Guarded starting_phase [Mantis – 4431]

The uvm_sequence_base::starting_phase variable is now protected and accessible only via set_starting_phase() and get_starting_phase() methods. One cannot set this variable again if retrieved using get method. The primary reason for this update was that any modification to the starting_phase variable in the code would lead to errors that were hard to debug.

How was this done in UVM1.1?

starting_phase as a variable was used to set phase, compare phase, raise & drop objections

How does it work in UVM1.2?

Use pre-defined methods set_starting_phase() & get_starting_phase()

How does it affect current code?

While moving to UVM1.2, if the code uses starting_phase variable then one can expect compile errors. The Accellera UVM team is generous enough to provide a script as part of the release that searches the starting_phase variable and replaces it with pre-defined methods based on how the variable is used in the code.

#3 Automatic raise & drop objection [Mantis – 4432]

set_automatic_phase_objection() method is added to raise and drop objections based on the starting_phase of the sequence thereby avoiding manual code. This change is mainly for ease of use.

How was this done in UVM1.1?


How does it work in UVM1.2?


How does it affect current code?

The existing code would need modification. As mentioned above, use the script provided by Accellera UVM team as part of the release.

#4 enum changes [Mantis – 4269]

A lot of verification code today involves a mix of different languages, methodologies and code developed by different teams. In UVM1.1 the enum values related to sequences didn’t have a unique signature and this lead to compilation errors when the uvm_pkg was wildcard imported into a scope that already had enum declarations with same name. To avoid this, those enum values are now prefixed with UVM_ string.

How was this done in UVM1.1?

UVM_ prefix missing in enum values for uvm_sequence_state_enum and uvm_sequencer_arb_mode

What changed in UVM1.2?

uvm_sequence_state_enum and uvm_sequencer_arb_mode enum values now have UVM_ prefix

How does it affect current code?

The existing code would give compile errors and you would need to update the values manually.

So when should you move to UVM1.2?

If you are not and early adopter and doesn't enjoy playing with new release, you can hold on for some time; otherwise go ahead, download the release and give it a shot with your code.

Recommended reading -