Portable Stimulus : redefining verification play field yet again!

In the last 3+ decades, verification has come a long way! Right from quick testing by designers to dedicated verification teams moving from directed testing to constrained random and adding elements of formal apps at times, it has been an eventful journey! Standardization of UVM enabled a common framework with which the fraternity marched forward in sync with each other. Horizontal reuse viz. at the IP level experienced maximum benefits of UVM while vertical resume viz. from IP to SoC level observed limited returns. Apart from the methodology, verification has also proliferated beyond simulation or emulation into virtual prototyping, FPGA validation, post silicon functional validation & HW SW co-verification. Today, the reuse aspects are not limited from IP to SoC or across projects but between platforms too. It is extremely important to realize reuse of efforts at any level across different vehicles enabling first silicon success. The challenge however is that each of these vehicles involve multiple stakeholders like architects (Chip , SW, system), SystemC modelling engineers, RTL designers, verification engineers, prototyping experts, post silicon debuggers and SW developers, each defining & driving the stages of SoC design cycle. Different goals focusing on a specific stage, different approaches in solving these problems and different means of representing solutions has made the task of reuse across the platforms – a convoluted puzzle!!!

To solve this problem, Accellera initiated a task force called Portable Stimulus Working Group (PSWG) that reviewed the concern & potential solutions. After long & regular sessions of intense activity in last couple of years, the group has come up with a proposal in form of a standard.  Beta release of the preliminary version of the Portable Test and Stimulus Standard is now opened for public review.

The basis of the solution relies upon taking the stimulus definition across platforms to an abstraction layer where the focus is on what is needed instead of how it shall be implemented? The idea is to understand & represent the action/outcome i.e. the behavior of the DUT when the test runs. While representing these actions, the focus would be on what would be the inputs and outputs, what resources are required in the DUT, and their relationship with each other? The how part i.e. the implementation will be left to a hidden layer (read EDA tool) to generate the required stimulus for the target platform based on the scenario definition. The actions referred above are all declarative and not procedural or executable by themselves. A set of these static actions can be used to construct a scenario, analyzed for coverage to determine the paths to be traversed & dumped into a test format using the hidden layer.  

To represent these actions, the PSWG has proposed 2 formats - Domain Specific Language (DSL) that is close to System Verilog and a restricted C++ library. Both these formats have equivalent semantics that are completely interchangeable such that for each line in the DSL there is an exactly equivalent C++ library entry. If one defines the actions of an IP in DSL and another IP in C++ library, both can be read together to generate a SoC level scenario for the target platform.

While the road of moving from developing each testcase to a testbench that generates tests has been long, it’s time to take another step in the direction of standardizing the stimuli! This would feed the testbenches for IP/SoC verification & be reused by other workhorses of verification & validation in the SoC design cycle. Remember, reuse is one of the keys to keep up with Moore's law!!!

The public review period for this proposal is open until Friday, March 30, 2018. Download & review NOW!!!

Quick chat with Alok Jain : Keynote speaker, DVCon India 2016

Alok Jain

All of us have heard the story of a woodcutter and the importance of the quote “Sharpen your axe”. It applies well to everything we do including verification. Two decades back, the focus of a verification engineer was predominantly on “What to Verify”. As complexity grew “How to Verify” became equally important. To enable this, EDA teams rolled out multiple technologies & methodologies. As we try to assimilate & integrate these flows amidst first time silicon & cost pressure, it is important for us to sharpen our axe through continuous learning, applying the right tool for the right job and applying it effectively.

Alok Jain, Senior Group Director in the Advanced Verification Division at Cadence would be discussing on similar lines as part of his DV track keynote on Day 1 at DVCon India 2016. With 20+ years of industry experience, Alok leads the Advanced Verification Division at Cadence India. Having associated with different technologies around verification in the past 2 decades, Alok candidly shared his views on the challenges beyond complexity that verification teams need to focus on. Here is a curtain raiser for his talk "Verification of complex SoCs" –

Alok your keynote topic focuses on challenges in verification beyond the complexity resulting from Moore’s law. Tell us more about it?

The keynote is going to focus on challenges and potential solution for verification of complex SoCs. Verifying a complex SoC consisting of tens of embedded cores and hundreds of IPs is a major challenge in the industry today. One of the big challenges is performance and capacity. Given the size and complexity of modern SoCs, tests can run for 18-24 hours or even more. One has to figure out how to get the best verification throughput. Another challenge is generation of test benches and tests. The test benches have to be developed in a way which can achieve good performance in both simulation and hardware acceleration. Tests have to be created that stress the SoC under the application use cases, low power scenarios, and multi-core coherency scenarios. The tests have to be re-usable across pre-silicon and post-silicon verification and validation platforms. Yet another challenge is coverage. One has to measure verification coverage across formal, simulation, and acceleration platforms at the SoC level to know when you are done. The final challenge is how to effectively debug across RTL, test bench, and embedded software on multiple verification platforms.

In the last decade, advancements in verification was focused primarily on unifying HVL(s) & methodologies. What changes do you foresee in verification flows ‘Beyond UVM’?

UVM is very well suited for IP, Sub-system and some specific aspects of SoC verification. However, UVM is not the best approach for general SoC verification. UVM is essentially developed for “bottom-up” verification where the focus is on trying to exhaustively verify IP/sub-systems. SoCs require a more “top-down” verification where the focus is on stressing the SoC under important application use cases. There is a need to reuse SoC content across simulation, emulation, FPGA and post-silicon. UVM is optimized for simulation and is too slow and heavy for high speed platforms. Finally, there is a need to drive software stimulus on CPUs in coordination with hardware interfaces. It is difficult in UVM to drive and control software and hardware interfaces. All this is asking us to explore options beyond UVM. The keynote will cover some more insights into options beyond UVM.

The rise of IoT is stretching the design demands to far ends i.e. server class vs edge node devices. How do you see verification flows catering to these demands?

Several of the requirements for IoT verification are similar to the ones for complex SoCs. But then there are some unique additional requirements from the IoT world. The first is simply the cost of verification. For complex SoCs, the cost of verification has been steadily rising. For IoT applications, one has to consider alternative methods and flows that can reduce the cost. One option is to use some form of a correct by construction approach where the design is specifically done in a way to enable a simpler form of verification. Another approach is to put much more emphasis on reuse. This includes horizontal reuse which is portability across multiple platforms and vertical reuse which is reuse from IP to sub-system to SoC. Another requirement is verification throughput for design with considerably more analog, mixed signal and low power content. Finally, one has to devise verification techniques and flows that can cater to the security and safety requirements of modern IoT applications.

Formal took a while to become mainstream. The rise of Apps in Formal seems to have accelerated this adoption. What’s your view on this?

Yes, I do agree that Apps has considerably accelerated the pace of adoption of formal. Traditionally, formal tools have been developed and used by formal PhDs and experts. The main charter and motivation of these experts was to solve the coolest and hardest problems in formal verification. It was only after some time that both sides (developers and users) started realizing that formal can be used in a much more practical and usable way by engineers to solve specific problems. This lead to the development of various formal apps which greatly enabled the mainstream usage of formal.

This is the 3rd edition of DVCon India. What are your expectations from the conference?

I am expecting to attend keynotes, technical papers and panel discussions that give me an understanding of some the latest work in the domain of design and verification of IPs, sub-systems and SoCs. In addition, I am looking forward to the opportunity to network with some of my peers from the industry and academia.

Thank you Alok!

Come join us in this exciting journey to contribute, collaborate, connect & celebrate @ DVCon India 2016!

Disclaimer: “The postings on this blog are my own and not necessarily reflect the views of Aricent”

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?

uvm_config_db#(uvm_object_wrapper)::set(this,“<seqr_path>.<phase>”,“default_sequence”,<sequence>::type_id::get());

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?

starting_phase.raise_objection(this);

…

starting_phase.drop_objection(this);

How does it work in UVM1.2?

set_automatic_phase_objection(1); 

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 -

UVM : Just do it OR Do it right!

Hierarchical Sequences in UVM

Sequence Layering in UVM

Sequence Library in UVM

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

Sequence Layering in UVM

Another year passed by and the verification world saw further advancements on how better to verify the rising complexity. At the core of verification there exist two pillars that have been active in simplifying the complexity all throughout. First is REUSABILITY at various levels i.e. within project from block to top level, across projects within an organization and deploying VIPs or a methodology like UVM across the industry. Second is raising ABSTRACTION levels i.e. from signals to transaction and from transaction to further abstraction layers so as to deal with complexity in a better way. Sequence layering is one such concept that incorporates the better of the two.

 

What is layering?

 

In simple terms, the concept of layering is where one encapsulates a detailed/complex function or a task and moves it at a higher level. In day to day life layering is used everywhere e.g. instead of calling a human being as an entity with 2 eyes, 1 nose, 2 ears, 2 hands, 2 legs etc. we simply refer to it as human being. When we go to a restaurant & ask for an item from the menu say barbeque chicken, we don’t explain the ingredients & process to prepare it. Latest is apps on handhelds where by just a click of an icon everything relevant is available. In short, we avoid the complexity of implementation & details associated while making use of generic stuff.

 

What is sequence layering?

 

Applying the concept of layering to sequences in UVM (any methodology) improves the code reusability by developing at a higher abstraction level. This is achieved by adding a layering agent derived from uvm_agent. The layering agent doesn’t have a driver though. All it has is a sequencer & monitor. The way it works is that there is a high level sequence item now associated with this layering sequencer. It would connect to the sequencer of the lower level protocols using the same mechanism as used by sequencer & driver in an uvm_agent. The lower level sequencer would have only 1 sequence (translation sequence that takes the higher level sequence item & translates it into lower level sequence item) running as a forever thread. Inside this sequence we have a get_next_item similar to what we do in a uvm_driver. The item is received from the higher level sequencer. It is translated by this lower level sequence & given to its driver. Once done, the same item_done kind of response is passed back from this lower level sequence to the layered sequencer indicating that it is ready for the next item.
 

Figure 1 : Concept diagram of the layering agent

 

On the analysis front, the same layering agent can also have a monitor at higher level. This monitor is connected to the monitor of the lower layer protocol. Once a lower layer packet is received it is passed on to this higher level monitor wherein it is translated into a higher level packet based on the configuration information. Once done, the higher level packet is given to the scoreboard for comparison. So we need only 1 scoreboard for all potential configurations of an IP & the layering agent monitor does the job of translation.

 

Example Implementation

 

I recently co-authored a paper on this subject at CDNLive 2013, Bangalore and we received the Best Paper Award! In this paper we describe the application of Sequence Layering where our team was involved in verifying a highly configurable memory controller supporting multiple protocols from the processor side and a no. of protocols on the DRAM memory controller front. A related blog post here.

 

I would like to hear from you in case you implemented the above or similar concepts in any of your projects. If you would like to see any other topic covered through this blog do drop in an email to siddhakarana@gmail.com (Anonymity guaranteed if requested).

 

Wish you all a happy & healthy new year!!!

 

 

Essential ingredients for developing VIPs

The last post Verification IP : Build or Buy? initiated some good offline discussions over emails & with verification folks on my visit to customers. Given the interest, here is a quick summary of important items that needs to be taken care of while developing a VIP or evaluating one. Hopefully they will further serve the purpose of helping you decide on Build vs. Buy J.

 

1. First & foremost is the quality of VIP. Engineers would advocate that quality can be confirmed by extensive validation & reviews. However, nothing can beat a well defined & documented process that ensures predictability & repeatability. It has to be a closed loop i.e. defining a process, documenting it & monitoring to ascertain that it is followed. This helps in bringing all team members in sync to carry out a given task, provides clarity to the schedule and acts as a training platform for new team members.

 

2. Next is architecture of the VIP. Architecture means a blue print that conveys what to place where. In absence of a common architecture, different VIPs from the same vendor would assume different forms. This affects user productivity as he/she would need to ramp up separately for each VIP. Integration, debugging & developing additional code would consume extra time & effort. Due to inconsistency across the products, VIP maintenance would be tough for the vendor too. A good architecture is one that leads to automation of skeleton while providing guidelines on making the VIP simulator and HVL+methodology agnostic.

 

3. With the wide adoption of accelerators, the need for having synthesizable transactors is rising. While transactors may not be available with initial releases of the VIP, having a process in place on how to add them when needed without affecting the core architecture of the VIP is crucial. The user level APIs shouldn’t change so that the same set of tests & sequences can be reused for either simulator or accelerator.

 

4. While architecture related stuff is generic, defining the basic transaction element, interface and configuration classes for different components of the VIP is protocol specific. This partitioning is essential for preserving the VIP development schedule & incorporating flexibility in the VIP for future updates based on customer requests or protocol changes.

 

5. Talking about protocol specific components, it is important to model the agents supporting a plug & play architecture. Given the introduction of layered protocols across domains, it is essential to provide flexible APIs at the agent level so as to morph it differently based on the use cases without affecting the core logic.

 

6. Scoreboard, assertions, protocol checkers & coverage model are essential ingredients of any VIP. While they are part of the release, user should be able to enable/disable them. For assertions, this control is required at a finer level. Also, the VIPs should not restrict use of vendor provided classes. The user should be able to override any or all of these classes as per requirement.

 

7. Debugging claims majority of the verification time. The log messages, debug & trace information generated by the VIP should all converge in aiding faster debug and root causing the issue at hand. Again not all information is desired every time. Controls for enabling different levels based on the focus of verification is required.

 

8. Events notify the user on what is happening and can be used to extend the checkers or coverage. While having a lot of events helps, too many of them affect simulator performance. Having control knobs to enable/disable events is desirable.

 

9. Talking about simulator performance, it is important to avoid JUGAAD (work around) in the code. There are tools available that can comment on code reusability & performance. Incorporating such tools as part of the development process is a key to clean code.

 

10. As in design, the VIP should be able to gracefully handle reset at any point during operation. It also needs to support error injection capabilities.

 

11. Finally, a detailed protocol compliance test suite with coverage model needs to accompany the VIP delivery.

 

These are essential ingredients. Fancy toppings are still possible to differentiate the VIP from alternate solutions though.

 

Looking for more comments & further discussions ....

 

Relevant posts -

Verification IP : Changing landscape - Part 1

Verification IP : Changing landscape - Part 2

Choosing the right VIP