Sequence Library in UVM

Looking into the history of verification we learn that the test bench and test cases came into picture when RTL was represented in form of Verilog or VHDL. As complexity grew, there was a need for another pair of eyes to verify the code and release the designer from this task that continues to transform into a humongous problem. The slow and steady pace of directed verification couldn’t cope up with the rising demand and constrained random verification (CRV) pitched in to fill the gap. Over the years industry played around with different HVLs and methodologies before squaring down to SV based UVM. The biggest advantage of CRV was auto generation of test cases to create scenarios that the human mind couldn’t comprehend. Coverage driven verification (CDV) further complimented CRV in terms of converging the unbounded problem. In the struggle to hit the user defined coverage goals, verification teams sometime forget the core strength of CRV i.e. finding hidden bugs by running random regressions. UVM provides an effective way to accomplish this aim through use of sequence library.

What is Sequence Library?

A sequence library is a conglomeration of registered sequence types derived from uvm_sequence. 

A sequence once registered shows up in the sequence queue of that sequence library. Reusability demands that a given IP should be configurable so as to plug seamlessly into different SoCs catering varied applications. The verification team can develop multiple sequence libraries to enable regressions for various configurations of the IP. Each of these libraries can be configured to execute sequences any no. of times in different order as configured by the MODE. The available modes in UVM include –

UVM_SEQ_LIB_RAND   : Randomly select any sequence from the queue

UVM_SEQ_LIB_RANDC :  Randomly select from the queue without repeating till all sequences exhausted

UVM_SEQ_LIB_ITEM    : Execute a single sequence item

UVM_SEQ_LIB_USER   : Call select_sequence() method the definition of which can be overridden by the user

Steps to setup a Sequence Library?

STEP 1 : Declare a sequence library. You can declare multiple libraries for a given verification environment.

STEP 2 : Add user defined & relevant sequences to the library. One sequence can be added to multiple sequence libraries.

STEP 3 : Select one of the 4 modes given above based on the context i.e. to run random or run a basic sequence item for sanity testing or a user defined mode as applicable like a set of sequences that test a part of the code for which bug was fixed.

STEP 4 : Select the sequence library as default sequence for a given sequencer from the test. This kind of depends on the STEP 3 i.e. the context.

Advantage

Sequence library is one of the most simple, effective but sparingly used mechanism in UVM. A user can plan to use sequence library by changing modes to achieve sanity testing, mini regression and constrained random regressions from the same test. Further, the library helps in achieving the goal of CRV in terms of generating complex scenarios by calling sequences randomly thereby finding those hidden bugs that would otherwise show up in the SoC verification or the field. 

As Albert Einstein rightly said "No amount of experimentation can ever prove me right; a single experiment can prove me wrong". It is important to run those experiments random enough so as to improve the probability of hitting that single experiment to prove that the RTL is not an exact representation of specification. Sequence library in UVM does this effectively!!!

Previous posts -

Hierachical Sequences in UVM

UVM : Just do it OR Do it right!

Hierarchical Sequences in UVM

Rising design complexity is leading to near exponential increase in verification efforts. The industry has embraced verification reuse by adopting UVM, deploying VIPs and plugging block level env components at sub system or SoC level. According to a verification study conducted by Wilson research in 2012 (commissioned by Mentor) the engineers spend ~60% of their time in developing/running tests and debugging failures. While the report doesn’t zoom in further, the verification fraternity would agree that a considerable chunk of this bandwidth is spent because the test developer didn’t have flexible APIs (sequences) to create tests and ill planned verification environment lead to extra debug. UVM provides a recommended framework that if incorporated effectively can overcome such challenges. ‘Hierarchical Sequences’ in UVM is one such concept suggesting sequence development in a modular fashion to enable easier debug, maintenance and reuse of the code.

As in LEGO, hierarchical sequences postulate development of base structures and assembling them in an orderly fashion to build desired structures. This process demands considerable planning right from the beginning with theend goal in mind. Definition of the base sequences determine the flexibility offered for effective reuse. The aim is to develop atomic sequences such that any complex sequence can be broken down into a series of base sequences. A few aspects worth considering include –

TIP 1: Define a sequence that generates a basic transaction depending upon the constraints passed to the sequence. To implement this, local variables corresponding to the sequence item members are defined in the sequence. These fields can be assigned values directly while calling the sequence from the high level sequences or test. The values received by the sequence are passed as inline constraints while generating the transaction. This provides full control to the user to generate the desired transaction.

TIP 2: Bundle the fields to be controlled into a configuration object and use the values set for this object to derive the inline constraints of the transaction to be generated. This is a complex version of TIP 1 particularly useful when either there is large number of variables in the transaction class or multiple base sequences are created having similar variables to be configured. This class can have fields directly linked to the sequence item and additional variables to control the sequence behavior. It is best to define a method to set the Config object. Note that this Config object has nothing to do with Config DB in UVM.

TIP 3: UVM provides Configuration DB to program the components of environment for a given scenario. As complexity increases, it is desired to read the configuration of a given component or understand the current state of a component and use this information while generating the transaction. Having a handle of the UVM component hierarchy in the base sequence facilitates development of sequences is such cases.

Once the base sequences are defined properly, a hierarchy can be developed enabling reuse and reducing margin of error. Let’s apply this to a bus protocol e.g. AMBA AHB. Irrespective of the scenario, an AHB master would finally drive a READ or a WRITE transaction on the bus. So our base sequence can be L0_AHB_READ and L0_AHB_WRITE. These sequences generate an AHB transaction based on the constraints provided to them as in TIP 1. Next level (L1) would be to call these sequences in a loop wherein the no. of iterations is user defined. Further we can develop a READ_AFTER _WRITE sequence wherein the sequences L1_LOOP_WRITE and L1_LOOP_READ are called within another loop such that it can generate Single Write followed by Read OR Bulk Write followed by Read. Using the above set of sequences any scenario can be generated such as configuration of any IP, reading data from an array/file and converting it into AHB transactions or interrupt/DMA sequences etc.

Deploying UVM is a first step towards reuse. To control the efforts spent on developing tests and debugging verification code, UVM needs to be applied effectively and that is beyond the syntax or proposed base class library. Hierarchical sequences demand proper planning and a disciplined approach. The observed returns are certainly multi-fold. This reminds me of a famous quote from Einstein – “Everything Should Be Made as Simple as Possible, But Not Simple!”

Suggested Reading -

Sequence Layering in UVM 

UVM : Just do it OR Do it right!

No, the title is not a comparison of captions but a gist of the discussions at UVM 1.2 day – a conference hosted by CVC Bangalore celebrating their decade long journey. The day started with keynote from Vinay Shenoy, MD Infineon Technologies India where he discussed the evolution of Indian industry in the last 30+ years and why India is a role model for services but lags in manufacturing. He also shared some rich insights into the Indian govt initiatives to bridge this gap. Vikas Gautam, Senior Director, Verification Group, Synopsys delivered the next keynote raising a question on the current state of verification and what next after UVM? Later in the day, Anil Gupta, MD Applied Micro India in his keynote discussed the growth of semiconductor industry emphasizing the need for value creation and expectations from the verification team adopting UVM. Pradeep captured the summary of these keynotes here – Vinay, Vikas and Anil. Further to this, Dennis Brophy, Director of strategic business development, Mentor & Vice Chairman, Accellera unleashed UVM1.2 inviting engineers to participate in the open review before final release.

Begin with an end in mind

While the phenomenal adoption rate of UVM has alleviated obvious worries, applying it effectively to address verification at various levels is still challenging. Deploying UVM in absence of proper planning and a systematic approach is a perfect recipe towards schedule abuse. This point was beautifully comprehended by Anil Gupta referring to carpentry as a profession. UVM is a toolset similar to hammer, chisel, lathe etc. found with every carpenter. Successful accomplishment of the work depends upon a focussed effort towards the end goal. If a carpenter is building a leg of a chair, he needs to concentrate on the leg in the context of that specific chair. This ensures that when the chair is finally assembled it comes into shape instantly. Ignoring this would otherwise lead to rework i.e. delay in schedule while affecting the stability and longevity of the chair. Similarly, while developing a UVM based environment, it is critical for the verification engineer to define and build it at block level such that it integrates at the sub system or SoC level seamlessly.

My 2 cents

Verification today demands a disciplined approach for marching towards the end goal. To start with, the verification architecture document at block level needs to address the reuse aspect of UVM components. Next is definition of sequence item and config DBs, avoiding glue logic while knitting components at block level and extending clear APIs to enable effective reuse. Performance of the SoC test bench depends on the slowest component integrated. Memory and CPU cycles consumed by entities need to be profiled, analyzed and corrected at block level to weed out such bottlenecks. It is crucial to involve block level owners to understand, discuss and debate the potential pitfalls when aiming to verify a SoC that is nothing less than a beast. Breaking the end goal into milestones that can be addressed at block level would ensure verification cycles at SoC level are utilized efficiently. Early start on test bench integration for subsystem/SoC level to enable flushing the flow and providing feedback to block owners would be an added advantage. 

Following is a 5 point rating scale for measuring overall verification approach effectiveness particularly at IP level –

Remember to revisit this scale frequently while developing the leg of the chair.... I mean any UVM based entity that is scheduled for reuse further.... :)

Related articles –

Verification with JUGAAD

Constrained Random Verification : A case study

UVM : redefining verification play field

UVM : Recap before release