Functional Verification

Built-in Message Logging – Part 2 of 2

teamspecman — Wed, 17 Mar 2010 22:30:00 GMT

[Team Specman welcomes back guest blogger, Michael Avery from our Services Group in the UK]

Building on the Part 1 introduction to Specman’s messaging built-in infrastructure, allow me to share some tips on how to programmatically control and scale message display to help shorten your debug time.

First and foremost: please, please, please avoid manually commenting out/in debug messages. While it’s very tempting to use this classic, quick & dirty technique, it’s always a waste of time in the end because Specman makes it very easy to control message viewing in a scalable, automated manner. Specifically, we can control which messages we see or don't see by configuring the loggers as follows:

Via constraints on the logger.
Via Specman commands or message logger GUI
By calling methods of the logger instances.

Additionally, message_loggers also have hook methods which allow us to customise how messages are handled. Consider the following example of a situation that may occur with big environments.

There you are with a large environment and find that you are seeing lots of low level messages that are not relevant to the area you are presently trying to debug. All these messages are simply creating a large amount of noise such that it’s hard to see the important messages relating to your current debug requirements.

Remember that a message request can potentially be displayed by any one of several loggers on the way from the unit that made the message request up through the hierarchy to sys.logger. If we set the message format to "long" then we get more detail about the message which is automatically added by the messaging infrastructure. An example Specman command to do this:

Specman> set message -format=long

So lets say that a message request is made like this:

mytcm() @myclk is { message(T1, LOW, "This is the text of my message"); };

This message will be passed up towards sys.logger. It may or may not get displayed. It will only be displayed if a message_logger has been configured to display messages with the “tag” T1 and a verbosity setting of LOW.

If such a message_logger exists then we will see in the Specman window the message like this:

[55] ENV UNITC (LOW) at line 113 in @msg_log_top in UNITC unit_c_u-@3:
This is the text of my message

So the information we get with message format=long can be described like this:

     [55]              - Time the message request was made
     ENV UNITC - Return value of short_name_path() method of unit which made the message request
     (LOW)          - Verbosity of the message
     line 113 in...  - Line of source code where message request was made
     UNITC unit_c_u-@3 - Unit instance which contained the message() request

We can see where the message request is made but cannot easily see which message logger actually displayed the message.

If we are seeing lots of low level messages we don't want then it is probably because a message_logger is incorrectly configured, but which one? There is no easy way to find this out but we can extend a predefined method of the pre defined message_logger unit. The predefined method called format_message() is called automatically every time a message is to be displayed. We can extend this method to add more information to the message:

   extend message_logger {
   format_message():list of string is also {
        result.add( append( "Logger instance ", me, " displayed this message"));
   };
   };

Now our message request which looks like this:

message(T1, LOW, "This is the text of my message");

..will be displayed like this:

[55] ENV UNITC (LOW) at line 113 in @msg_log_top in UNITC unit_c_u-@3:
This is the text of my message
Logger instance message_logger-@12 displayed this message

Now we have identified the offending logger and can configure it so that we no longer see the messages which are currently irrelevant to us.

Even better: a very useful command option added in Specman 9.2 allows us to recursively turn off messages from some stated point in the hierarchy.

What it does:

Recursively traverse a unit tree starting from the specified root (which is "sys" by default)
Replace, add, or remove the messages specified by the filter on all loggers that are allocated the specified tags

Specman> set message -rec [-root=unit-exp] [-replace|-add|-remove] [-tags=tag-list|all] [filter]

For a more in-depth view of message loggers attend the Advanced Specman Training Course - http://www.cadence.com/Training

Michael Avery
Cadence Services, UK

UVM = OVM 2.1: Even Better!

tomacadence — Tue, 16 Mar 2010 17:00:00 GMT

Since I'm not a member of the Accellera VIP TSC, I did not attend the 2.5-day face-to-face meeting held last week in Massachusetts. But with the steady stream of tweets coming from several of those who did attend, I almost felt as if I were there. That experience will be subject of my next blog entry, but for today I want to touch on some of the interesting news from the face-to-face. Perhaps the most exciting was that the group has apparently decided to base its Universal Verification Methodology (UVM) on OVM 2.1 rather than on OVM 2.03 as voted back in December.

This is a welcome move since it adds some important and widely used features to the initial release of the UVM father than delaying them for the future. In fact, I have been vigorously advocating exactly this action for a while. I've also been suggesting that Accellera get UVM 1.0 out as quickly as possible, and then worry about adding major features such as a register-memory package that will require lots of discussion and even more validation. It sounds as if the TSC is on the right path here as well, with a stated goal to get the first UVM release out by the end of April.

As far as I can tell, the TSC has not made a strong statement about the UVM being fully compatible with OVM 2.1 as it exists today and is being used by countless thousands of users. I still think that full compatibility makes sense on order to foster rapid adoption of the UVM when it is released. Despite this concern, based on what I've gathered from the tweets and those who attended, the Accellera VIP TSC seems to have wisely separated a fast initial UVM release looking a whole lot like OVM 2.1 from all the additional features to be added in future releases. That's good news!

Tom A.

The truth is out there...sometimes it's in a blog.

Built-in Message Logging – Part 1 of 2

teamspecman — Thu, 11 Mar 2010 14:00:00 GMT

[Team Specman welcomes guest blogger Michael Avery, from our Services Group in the UK]

Messaging is important for two main reasons:

It is essential for debugging

It can greatly impact simulation performance

This is why Specman has a messaging infrastructure built-in to provide an easy to use, scalable and efficient mechanism. Furthermore, Specman’s messaging capabilities allow you to do almost anything which you can conceive with messaging: colouring, formatting, rejection, modification, redirection, etc.

The infrastructure uses a predefined unit called a message_logger to deal with message requests. Message requests are made using the message() action. By default, the “sys.logger” message logger is available, where sys.logger will deal with all message actions if you do not specify your own. However, you can and should instance your own message_loggers, where at a minimum I’d recommend each UVC in a testbench should have its own message_logger. In practice, it is very likely that major units like agents and monitors will also have their own message_loggers.

Given this background, here are some message_logger first principals:

When a message request is made, this message is "seen" by every message_logger from the unit containing the message action, through each direct ancestor, all the way up until it reaches sys.logger.

Each message_logger has associated with it a maximum of 2 destinations: the screen and a file.

Each of these loggers may have been configured differently, where some loggers may have been configured to ignore a given message. In the “ignore” case, message requests still get passed on up the chain to sys.logger, but only message_loggers which have been configured to respond to the message will do so; and only if that message request has not already been sent to the same destination by a message_logger closer to the origin of the message request. i.e. the same message request will not be sent to the screen by more than 1 message_logger.

Even if a message logger deals with a message request, it still passes that message request up the hierarchy. This is because that message_logger does not know if a message_logger further up the hierarchy is configured to send the same message to a different destination (for example, a file to which the message has not been sent by another message_logger).

What about the amount of messages and the level of detail required from them? In general, two factors come into play:

Clearly different levels of maturity of verification environment or RTL strongly influence the message quantity & quality. For example, it’s oftern helpful to have lots of detailed messaging early on in the environment bring up and debugging process, then thin it out as the environment matures so you don't have thousands of detailed messages in our logs potentially obscuring important activity.

Verification at different levels of abstraction also influences messaging. While similar in practice to (1) above, in this case as we move from module to system level verification then the messages from the lower level become less relevant. In fact, the system integrator probably does not have enough detailed knowledge of the low level block to make sense of the message anyway. That said, unearthing the roots of a system level bug may require a temporary reactivation of detailed messaging for a particular monitor instance connected to a particular DUT interface.

In the next installment of this series, I’ll share some tips on how to programmatically control message display to help speed your debug process.

Michael Avery
Cadence Services Organization, UK

VIP Portfolio Extension: New AMBA 4 Protocol Support

teamspecman — Tue, 09 Mar 2010 00:30:00 GMT

ARM-loving Specmaniacs's rejoice: we are now at liberty to announce that we are providing Verification IP (VIP) support for the new AMBA 4 protocol simultaneously with ARM’s introduction of said protocol. Here is the official announcement, which includes AMBA4 and VIP highlights.

What this means in practical terms:

If you have licenses for the Cadence VIP Portfolio (part number "VIP100"), you will receive the AMBA 4 VIP for no additional charge when it goes into production. If you are qualified and willing to be an Early Access user, you will receive it even sooner. To request early access, contact your friendly local AE or Salesperson (or email us an we'll forward the request).

Like all VIP in the Cadence VIP Portfolio, this OVM-compliant UVC has the Compliance Management System (CMS) built-in -- meaning the full set of AMBA4-specific sequences&scenarios, its coverage model, and detailed compliance checks and metrics -- all automagically tracked via a Compliance vPlan -- are all included.

FYI / brief history lesson: the AMBA UVC is easily one of the most popular, time-tested UVCs in the Portfolio. It's in use / has been used by 1,000s of projects, and the code base is one of the most mature pieces of VIP anywhere -- built on almost 10 years of AMBA VIP experience!

Happy verifying!

Team Specman

Have You Considered e Lately?

tomacadence — Fri, 05 Mar 2010 14:00:00 GMT

Richard Goering's recent interview with Mitch Weaver on the future of Specman and e put me in a reflective mood about my own evolving opinions. My hands-on experience with Specman is minimal; back in my 0-In applications days I co-developed a joint demo with Verisity (prior to acquisition by Cadence) in which I had the chance to do a bit of e testbench coding. I was very familiar with formal at that point, but it was my first exposure to constrained-random simulation and I was impressed.

Six months later I was working at Synopsys, where I was deeply involved in their SystemVerilog rollout. My impression there, based largely on the fact that I talked almost exclusively to SystemVerilog and Vera users, was that e was dead or dying. Fast-forward a couple of years, and I joined Cadence. I can honestly say that nothing I have seen or learned in my time at Cadence has surprised me as much as finding out as soon as I joined just how powerful and popular e really is.

Mitch does not overstate reality at all - Specman and e continue in very broad usage with very few users switching to SystemVerilog and, in fact, new projects and new companies signing up every year. Of course, by now I've had the chance to talk to many e users and I understand how its technical advantages fuel their passion for the language. It's nothing against SystemVerilog to acknowledge that e has some unique features for advanced verification; it's a simple statement of fact.

However, I do talk to the occasional customer who is "e-lergic" (an old Verisity term) and who doesn't even want to hear e mentioned. Some are actually suspicious that our support for e somehow compromises our support for SystemVerilog! As Mitch explains in the interview, this is simply not the case. We support all IEEE-standard languages equally well, and enable just about any combination of e, SystemVerilog, and SystemC models in customer verification environments.

Since there are such strong opinions about e out there, I'm frankly surprised that there have been no comments on Richard's interview. I'll try for some response here since I'm quite curious to know what all you testbench developers really think. If you're unwilling to consider e, I'd like to know why. If you have an open mind on verification languages but didn't choose e, I'd like to know why. If you did choose e, I'd still like to know your reasons. So ... have you considered e lately?

Tom A.

The truth is out there...sometimes it's in a blog.

Why OOP Falls Short For Verification

teamspecman — Thu, 04 Mar 2010 01:30:00 GMT

Last week at DVCon, frequent Team Specman guest blogger Matan Vax of R&D gave a paper on "Where OOP Falls Short of Verification Needs". In the following video, Matan elaborates on his paper, where it becomes clear that OOP languages like -- well, you know -- are at an inherent disadvantage vs. AOP approach (like in e) when it comes to the unique requirements of verification.

Click here if the embedded video doesn't play.

Joe Hupcey III for Team Specman

DVCon 2010 - Day 3

jvh3 — Tue, 02 Mar 2010 14:00:00 GMT

Click here or on the image below to go to the annotated photo blog of DVCon 2010 Day 3.

The images and notes include highlights from:

A paper on "Where OOP Falls Short of Verification Needs" (And there is also a video interview of Matan elaborating on the paper

The paper "Tweak Free Reuse With OVM"

A paper on "Mixed Signal Verification of Dynamic Adaptive Power Management in Low Power SoCs"

The closing panel "Ever Onward! Minimizing Verification Time and Effort"

I also had the pleasure of interviewing one of our long time Verification Alliance partners, AMIQ, in their first appearence at DVCon (yes, they are growing even in these tough times!). In this video, their director of marketing Corina Mitu introduces their company, their "OVM aware" integrated device environment "DVT", and some new announcements ...

If video fails to launch click here.

Last but not least, my colleague Richard Goering has been writing detailed articles on the main keynote and panel sessions.

Enjoy!

Joe Hupcey III

DVCon 2010 Rocked!

tomacadence — Sat, 27 Feb 2010 07:32:00 GMT

I've spent much of this week at the San Jose Doubletree Hotel for DVCon 2010, and I have to say that it was a really good show. This is arguably the most important conference of the year for verification. DAC is lots bigger of course, but DVCon is really focused and there's a core group of colleagues and customers that always make it a fun and simulating event. Although DVCon is still officially the "Design & Verification Conference & Exhibition" every year it looks more and more as if the first ampersand is living on borrowed time.

Cadence and our customers had an especially active presence at DVCon this year, plus I always like to check out what our competitors and their customers are doing, so I couldn't possibly attend every session I wanted. I was really impressed with the technical papers that I did see, especially talks from Doulos on connecting SystemVerilog withC/C++/SystemC and on asynchronous assertions. They have a knack for presentating complex topics in a way that works even for those of us who no longer think about simulation timewheels on a daily basis.

The panels were generally lively, with some pithy comments that I (and others) tweeted in real time. I was really pleased with our sponsored lunch and its panel on debug. It was great that our CEO Lip-Bu Tan made his DVCon debut with a well-attended keynote address. Finally, I was just delighted with the pervasive OVM-related content -- our lunch, the UVM update at the Accellera lunch, exhibition floor demos, three tutorials, and at least five technical talks including the Best Paper award. It's only a day after the closing session and I'm already looking forward to next year!

Tom A.

The truth is out there...sometimes it's in a blog.

DVCon 2010 - Day 2

jvh3 — Fri, 26 Feb 2010 14:45:00 GMT

Click here or on the image below to go to the annotated photo blog of DVCon Day 2.

Photos & notes include highlights from:

Brett Lammers' paper on "Apples to Apples HVL Comparison Finally Arrives"

Lunch panel on "OVM found the bugs, now how do we debug them faster"

Cadence CEO Lip-Bu Tan's keynote on "Breaking Through The Efficiency Barrier"

Industry Leaders panel on "What Keeps You Up At Night?"

Some shots of the show floor

Enjoy!

Joe Hupcey III

DVCon 2010 - Day 1

jvh3 — Wed, 24 Feb 2010 15:00:00 GMT

Click here or on the image below to go to the photo blog of DVCon Day 1.

While I've added descriptive captions to the images, allow me to address the FAQ: "How was the traffic on show floor?". My unscientific observation was that the floor was a little lighter than last year, but this was a result of the tutorials being better attended and/or they "held" their audiences for longer.

Enjoy!

Joe Hupcey III

DVCon "Day 0" - Quick Report From SystemC Day

jvh3 — Tue, 23 Feb 2010 04:32:00 GMT

If you were looking for more evidence that the transition from RTL to ESL is gaining momentum, today at "Day 0" of DVCon (a/k/a "SystemC Day") you would discover plenty of supporting data points. Here is a brief video interview with my colleague Steve Svoboda on the day's events, how far we've come from the first wave of SystemC hype back in 2000, and what Cadence is doing in this space:

If the video fails to launch click here.

Additionally, I had the pleasure of sitting in on the TLM 2.0 tutorial. While all 3 presenters -- John Aynsley of Doulos, Michael "Mac" McNamara of Cadence, and Michael Meredith of Forte -- had a great mix of detailed technical & high-level information. In particular, Mac's blunt declaration, "You can keep your head in the sand, or realize that today we need to move to higher abstraction for design and verification", was a bracing standout.

Mac outlines to the TLM 2.0 tutorial audience why the time for higher level abstraction is NOW.

Bottom-line: this "day 0" of events was a great warm-up for the rest of the show, and I'm looking forward to day 1!

Joe Hupcey III

Reference Links
The official DVCon site
http://www.dvcon.org/

Comprehensive list of Cadence-sponsored events & papers
(Be sure to sign up for our free lunch panel on the growing debug crisis on Wednesday)
http://www.cadence.com/mail/dvcon2010.html

Images from last year's show to give you an idea of what it's like, in case you have never been to a DVCon before.
http://www.flickr.com/photos/24605532@N08/collections/72157614716018724/

Editor For OVM Field Registration Macros

Team genIES — Mon, 22 Feb 2010 23:20:00 GMT

The OVM SystemVerilog Class Library has built-in automation for many service routines that classes need for printing, copying, comparing and so on. OVM allows you to specify the automation needed for each field and to use a built-in, mature and consistent implementation of these routines. For each field you must use OVM field registration macros as in the example below:

...

rand bit [15:0] addr;

rand xbus_read_write_enum read_write;

rand int unsigned size;

rand bit [7:0] data[];

rand bit [3:0] wait_state[];

...

`ovm_object_utils_begin(xbus_transfer)

`ovm_field_int (addr, OVM_ALL_ON)

`ovm_field_enum (xbus_read_write_enum, read_write, OVM_ALL_ON)

`ovm_field_int (size, OVM_ALL_ON)

`ovm_field_array_int(data, OVM_ALL_ON)

`ovm_field_array_int(wait_state, OVM_ALL_ON)

...

Inside a single dedicated `ovm_*_utils_begin...end block, you must use dedicated macros for each field type. For example `ovm_field_int for a simple int or `ovm_field_aa_int_byte_unsigned for an associative array of integral types indexed by the byte unsigned.

If you are hesitant and your head aches when matching the right macro with the right type, the OVM Field Editor of the already well known DVT (Design and Verification Tools) Eclipse Plug-in IDE comes to rescue:

You can quickly check whether you have unregistered fields or registration errors. The DVT OVM Field Editor allows you to click on a field and register it with the right macro or customize it's printing, copying, packing and other controls. Based on the enclosing class type (object, component or sequence), the right `ovm_*_utils_begin...end< enclosing block for the registration macros is also created.

From now on, just declare your fields, then open the OVM Field Editor, select all fields and click Register. That's it!

Just don't forget to read more about the DVT Eclipse Plug-in and get your free trial license from www.dvteclipse.com.

=genIES

DVCon: Showcasing The Cadence Passion For Verification Excellence

Adam Sherilog — Mon, 22 Feb 2010 21:15:00 GMT

Yeah, I know I'm a marketing guy but I really like this stuff! For sure, we are going tech-deep in our tutorials and papers, but we are also setting vision and direction for verification in our keynote presentation. For all of the details, visit our DVCon events page. Highlighted below are two of the items that I think will be of special interest.

Tutorial: OVM Advanced Topics

With UVM based on OVM, this is a must see. We will start by describing the latest on OVM for multiple languages -- a requirement voiced by many users for UVM. The tutorial will then get into the guts of the OVM Low-power methodology, OVM for Assertion Based Verification, and OVM for Acceleration. If you are an OVM user today, this will show you what's coming. If you are a VMM user, it will show you what you'll be getting as you move to the UVM.

Panel: OVM Found the Bugs, Now How Do We Debug Them Faster?

As our technical team travels the world, we hear time and time again that debugging complex environments is becoming a huge challenge. This panel will dive into real-world debug challenges users face and we'll be debating the approaches and methodology to address them. Since this is really a state-of-the-art discussion, the panel will include representatives from Cadence, SpringSoft, the verification user community.

People Make DVCon Great

The biggest thing that makes DVCon so special is that it attracts the best people in our vibrant community. Our contribution this year includes a number of our lead technologists delivering papers and demos as well as the keynote address. See us in our booth, tutorials, papers, and panels or just stop us in the hall to talk. If there is one thing that binds us all it is the passion for verification excellence.

=Adam Sheriblog

Rev 2 of OVM e Scoreboard on OVMWorld.org Now

teamspecman — Thu, 18 Feb 2010 22:30:00 GMT

Just in time for DVCon 2010, I'm happy to inform you that revision 2 of the OVM e Scoreboard was just uploaded to OVMWorld: http://www.ovmworld.org

The main changes from rev1:

A proper User Guide containing detailed descriptions and code examples for several popular use models
Performance improvements in the search algorithm

I encourage everyone who has already downloaded the original OVM e Scoreboard to download this new version (if only to get the new User Guide for reference). From mails we get, I know that several companies already have implemented a scoreboard using this infrastructure. Now, with the new examples and documentation, I am sure this task will become even easier.

As always any comments and questions are most welcome.

Happy verifying!

Efrat Shneydor
Cadence Methodology R&D
(and frequent Team Specman guest blogger; author of the hit series on Performance Aware e-Coding Guidelines)

Cadence Exec: Why Cadence is Comitted to e/Specman

teamspecman — Tue, 16 Feb 2010 19:00:00 GMT

In case you or your management are wondering about Cadence's commitment to supporting the e language and/or Specman technology, allow us to direct your attention to this interview of Cadence Verification VP Mitch Weaver (who never worked for Verisity, BTW) by industry analyst Richard Goering.

As you'll see, with statements like, "Bottom line: cutting back on Specman/e would be like cutting our own throat", Mitch doesn't mince words about the depth of Cadence's commitment to our favorite platform.

Happy verifying!

Team Specman