Functional Verification

Get Started on UVM-e with Free Introductory Video Tutorials

teamspecman — Thu, 24 May 2012 17:03:00 GMT

One of the many requests that we get from Specman/e customers is that they would like some basic e tutorials. So, as a first step, Axel Scherer has recently posted 24, very short, byte sized UVM-e basic tutorials. Check them out.

These e-based videos are targeted for design and verification engineers who are interested in learning about the basic concepts of UVM-e and the benefits that the e language provides.

As you may know, e is an IEEE 1647 standard hardware verification language (HVL) that is tailored to implementing highly flexible and reusable verification testbenches, leading to a significant productivity improvement. e is one of the most mature verification languages, used by specialists for advanced verification. It is, therefore, the most mature in its coupling to overall verification methodology, technology, and verification IP (VIP), and it can scale to the most complex block/unit, chip, system, and project levels.

These videos provide the basics of Aspect Orient Programming (AOP) capabilities, constrained randomization, scoreboarding, etc....

So, relax, make yourself comfortable and enjoy these videos. Hopefully, these videos will excite you enough to try out the e language on your new or existing verification project and join the elite team of Specmaniacs.

Here's a list of You Tube e videos for your enjoyment!

TeamSpecman

Tips on Writing Macros in Specman e Language

teamspecman — Tue, 22 May 2012 09:43:00 GMT

In this blog, I will present some tips that can be very useful when you write e macros. We will see which kind of macro we should use for our purposes, and what options we can use to better define our macro.

Let's begin by looking at the following simple example. Assume that you want to define a method that computes an expression of any type and assigns its value to two variables. Because the expression type is unknown, you cannot use a real method; instead, you can define a pseudo-method, presumably using a macro.

At the first glance, it seems that you can easily accomplish your goal by means of the following define-as macro:

define <double_assign'action>
"double_assign\(<lsh1'exp>,<lsh2'exp>,<rhs'exp>\)" as {

<lsh1'exp> = <rsh'exp>;

<lsh2'exp> = <lsh1'exp>;

};

However, it is not so simple after all. When you try to load the above code, you get the following load error:

*** Error: Between '\(' and '\)' in the match expression, there should only be a syntactic argument (with or without repetition)

Indeed, as you probably know, there are certain limitations on the syntax of macro match expressions. In particular, within parentheses or brackets you can only use either of the following:

A single syntactic argument; for example, <lsh1'exp> - which denotes an expression (the prefix lsh1 is a unique tag given to this syntactic argument).
A syntactic argument repetition, denoted by a separator character followed by an ellipsis; for example, \(<exp>,...\) - which denotes any number of expressions separated by a comma.

However, in the above example, the parentheses contain three syntactic arguments and two commas.

So, how can we define a macro that will match the desired syntax? The solution is to use a more general match expression, and check the specific syntax procedurally inside the macro body. Also, a define-as macro only allows you to specify a fixed template for the replacement code; it does not allow applying conditions on the original code. So, you need to use a define-as-computed macro.

In our example, as now modified (below), the match expression will match any sequence of <exp>s, and it will procedurally check that their number is exactly 3. Notice that when a repetition is used in a define-as-computed macro (<exp>,... in this example), it is treated as a list of strings, where each repetition element is represented as a separate string. Notice also that the repetition is referenced inside the macro body in the plural form (<exps> in this example).

define <double_assign'action> "double_assign[ ]\(<exp>,...\)" as computed {

if <exps>.size() != 3 then {

error("double_assign() must get exactly 3 parameters");

};

var lsh1: string = <exps>[0];

var lsh2: string = <exps>[1];

var rsh: string = <exps>[2];

return append(lsh1, "=", rsh, ";", lsh2, "=", lsh1);

};

If double_assign()is called with a number of parameters other than 3, an error message will appear at the time of load or compilation.

So far, so good. But what happens if there also exists a real method called double_assign(), and this method gets a different number of parameters? Now we have a problem. Any call to this method will now be matched by the macro we just introduced, and result in the error message.

So now the question is: Can we have both the method and the macro work without interfering each other? The answer is yes, provided that we use the predefined routine, reject_match(). When this routine is called from within a define-as-computed macro, its effect is the same as if the macro match expression did not match the code in the first place. The parser will then make other attempts to match the code, and eventually it will recognize it as a real method call.

To achieve this solution, the above macro should be rewritten as follows:

define <double_assign'action> "double_assign[ ]\(<exp>,...\)" as computed {

if <exps>.size() != 3 then {

reject_match();

};

var lsh1: string = <exps>[0];

var lsh2: string = <exps>[1];

var rsh: string = <exps>[2];

return append(lsh1, "=", rsh, ";", lsh2, "=", lsh1);

};

Before concluding our blog tips, let's examine another case where using reject_match() can be useful.

Assume that you want to introduce the following syntax to declare several cover items at once:

item a, b;

This seems to be easily done with the following macro:

define <multi'cover_item> "item <name>,..." as computed {

for each in <names> do {

result = append(result, "item ", it, ";");

};

However, after this macro is loaded, any cover item declaration causes a load time error message that suggests an infinite recursion in macro expansion. The reason is that in addition to matching the above syntax, the macro also matches the original cover item declaration syntax with a single item. The result is that its expansion code is exactly the same, and the macro continues matching the same code infinitely.

This problem can be easily solved by using reject_match() to reject cases with one item only:

define <multi'cover_item> "item <name>,..." as computed {

if (<names>).size() == 1 then {

reject_match();

};

for each in <names> do {

result = append(result, "item ", it, ";");

};

To summarize, when writing e macros where the basic match expression syntax is not sufficient, the following tips can be very useful:

Write a more general match expression, and perform additional checks procedurally.
Wherever useful, use reject_match(), especially if there is a possibility that another macro or built-in construct will match.

Yuri Tsoglin

e Language team, Specman R&D

UVM e (IEEE 1647) Video Series Features the Return of the Cowbell!

Axel Scherer — Tue, 22 May 2012 01:15:00 GMT

A significant number of readers of my previous post on this topic were not aware of the Saturday Night Live cowbell skit. This took me quite by surprise! The only prescription for this problem is that I pledge to continue to play the cultural ambassador and will introduce more vital trivia!

However, before we expand the scope, let's continue to honor the will of Bruce Dickinson and give you more cowbell! After all, the sound of his original cowbell "ding" traveled all the way from Oregon to Japan. So we must have done something right.

This time around, we have tuned our cowbell to the frequency 164.814 Hz or e (IEEE 1647). In other words, we are releasing the basics for UVM-e with another two dozen short videos as a YouTube playlist [direct access links below].

Keep on dinging!

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

The Facts: Why Accelerated VIP Is Needed for SoC Verification

PeteHeller — Tue, 15 May 2012 13:30:00 GMT

On Tuesday May 15^th Cadence announced the expansion of our VIP Catalog to include accelerated VIP (AVIP). You may be wondering why Cadence is investing in accelerated VIP (which runs on an accelerated platform such as the Palladium XP) when we already have the market leading simulation VIP. Good question. This blog will answer that and explain the rationale behind Cadence's AVIP and more about our products and plans going forward.

A key driving factor impacting verification approach is the size of the design. Today designs commonly are in the 10's and even 100's of millions of gates. And software size is growing at an even faster pace. There's no respite in sight for these torrid growth rates. So even if you don't face such verification challenges immediately, read on, because they're coming.

Verification teams have taken notice of these facts and are adapting their approaches. It's become a necessity to expand the set of functional verification tools employed beyond just simulation. That's because simulation times have become excessive for SoCs, and even for many subystems. Consequently, leading companies have adopted accelerated platforms and accelerated verification IP (AVIP) for their hardware verification.

In addition, to tackle the expanding firmware/software development challenge, acceleration is frequently being used in tandem with a virtual prototype such as Cadence's Virtual System Platform. This enables the CPU cycles to be run separately from the rest of the logic to maximize software execution speed. These verification techniques are enabling leading verification teams to meet their design goals such as shortening overall product development cycle, increasing design functionality, reducing power consumption, and/or improving quality.

Such leading companies have adopted a tiered approach to system integration and verification. Their best practices include setting verification goals for each integration tier and selecting the verification methods and metrics to maximize those specific goals. These include:

Hardware IP Development and Verification
Hardware Subsystem/SoC verification
Hardware/Software Integration and Validation

For a more detailed discussion regarding the verification approaches being employed, please see Cadence's just published Comprehensive Acceleration White Paper.

That begs the question: is simulation and simulation VIP a dead end? Absolutely not. Simulation has an important place in the verification continuum, but as Clint Eastwood so famously said in his Dirty Harry role "a man's got to know his limitations."

Simulation's role is increasingly limited to IP/block verification. That's a critical role and a key reason that Cadence continues to invest heavily in simulation VIP in addition to accelerated VIP. But when it comes to SoC verification, the need for speed is crucial. We've seen from customers that SoC verification requires performance gains of at least 20X over simulation. And very commonly performance gains must be in the 100X-1000X over simulation when the full SoC is being validated and/or software is being developed. Meeting these needs is exactly why Cadence has brought acceleration and AVIP to market.

But be wary! Other VIP suppliers have posited that a 4X gain in simulation VIP speed will enable its use in SoC verification. First of all, Even if you take such speedup claim at face value, a 4X gain in VIP performance only translates to a 13% gain in overall performance. That's why Cadence takes a very different perspective. For more information my colleague Tom Hackett just wrote an excellent article about how testbenches and testbench languages must be properly applied and used on the right verification platform for SoC level verification. And, unlike other unsubstantiated claims, Tom's article includes hard data and simple math to back up our positions.

Like other accelerated VIP, Cadence AVIP uses a SCE-MI interface to connect to a host workstation. However, that's pretty much where the similarities end. Cadence AVIP is uniquely architected to deliver a range of performance and verification tradeoffs, all under user control.

OK, so you're sold on the need for accelerated VIP, why should you select accelerated VIP from Cadence? Cadence AVIP has several advantages. A partial list includes:

Cadence AVIP delivers high performance. All customer engagements have demonstrated the AVIP meets or exceeds its performance targets. To achieve the high performance, the AVIP employs another unique architectural advantage: the Acceleration Optimized Core.
Cadence AVIP provides multiple user interfaces to enable you to use just one single AVIP for all your verification tasks. These interfaces and their uses are briefly described below:
Cadence AVIP supports a UVM interface for easy UVM testbench reuse in acceleration, with the same consistent user interface as the Cadence simulation VIP. This also enables the AVIP to support testbenches written in verification languages such as SystemVerilog and e.
For testbenches written in C or C++, the C/C++ interface is used to deliver a higher level of performance than with the UVM interface, typically hundreds of times greater than with simulation
It is also possible to eliminate the testbench completely using the embedded interface. With the entire design running on the Palladium platform users get the maximum validation performance. (This can also be referred to as emulation.)
The TLM 2 interface is used for software development and/or hardware/software co-development.

Figure 1. Cadence AVIP provides multiple user interfaces so you can use a single AVIP for all your verification needs

Cadence AVIP provides "knobs" enabling you to make tradeoffs between performance and verification functionality. For example, streamlined stimulus generation, checking, and coverage for UVM environments are all under user control.

Thanks for reading this far! I suspect you're now wondering what protocols does Cadence provide AVIP for? Great question. Today Cadence provides AVIP for AMBA AXI 3/4, AMBA 4 ACE (including ACE Lite), PCI Express 2/3, USB 3.0, HDMI 1.4, SATA, and Ethernet 10G. We have plans for more protocols including MIPI and DisplayPort. I encourage you to get in touch with your Cadence AE or salesperson to discuss your needs with us.

For more information on AVIP, click here.

Pete Heller

DAC 2012 Preview: Focus on Formal and ABV Events and Papers

TeamVerify — Mon, 14 May 2012 13:01:00 GMT

In a few short weeks DAC 2012 will be upon us (June 3-7, 2012 in San Francisco, CA), and Team Verify and our colleagues on the Incisive Verification team will be there in force with detailed briefings, panels, papers, posters, and of course live demos in the Cadence booth. Here are the formal and assertion-based verification (ABV) specific highlights:

* On the show floor Monday June 4 through Wednesday June 6, our main booth demo includes the hit formal app "Coverage Unreachability" with Incisive Enterprise Verifier (IEV). Since this app's release last year, its power mix of formal, simulation, and metric-driven verification (MDV) capabilities has enabled customers around the world to identify state spaces that are mathematically impossible to reach, saving a ton of time and confusion in the process. Technology Experts Bin Ju, Darrow Chu, Chris Komar, and Axel Scherer will be on-hand to give you an update, as well as field any questions you may have about other formal and multi-engine apps, and ABV technologies and methodologies in general.

* This year the DAC "User Track" features a whole session devoted to "Practical Formal Methods" (yeah!) - it's Session 8U on Wednesday June 6, 4pm-6pm in Room 106. Even better: Incisive Formal Verifier (IFV) plays a role in two papers in this track: paper 8U.2 "Deploying Model Checking for Bypass Verification" and paper 8U.5 "How we Verified 5000 Lines of a Complex Multiplexing Code with Three Assertions". Without giving too much away in advance, these papers will show very clever - yet widely applicable - abstraction techniques that enable formal to provide results in hours vs. weeks for a simulation-only flow.

* Last but not least, back by popular demand you will see the most amusing formal app of them all - Rubik's Cube solving with a Lego Mindstorms robot driven by IFV (right). If you are a "Speed Cuber" by all means we welcome you to test your skills against the machine like at DVCon and CDNLive San Jose.

Hope to see you soon!

Joe Hupcey III
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And now you can "Like" us on Facebook too:
http://www.facebook.com/pages/Team-Verify/298008410248534

Reference Links:
Comprehensive DAC preview by Richard Goering: "See Cadence at DAC 2012 - Panels, Tutorials, "I Love DAC," and the Denali Party"

DVCon 2012 Video: Product Engineer Chris Komar Reviews the Tutorial on Formal Apps

February 2012: Richard Goering, "How Formal Analysis ‘Apps' Provide New Verification Solutions"

February 2, 2012, Daniel Payne of SemiWiki.com, "Using "Apps" to Take Formal Analysis Mainstream"

Specman’s Memory Management Orientation Guide (or “Honey – Please Take out the Garbage”)

teamspecman — Fri, 11 May 2012 13:00:00 GMT

Memory management is not something the Specman user is supposed to worry about. Nobody likes to make notes about allocations and freeing up memory segments when he's programming, and Specman supplies a mechanism that allows the programmer to have some extra time for a cup of coffee.

Unfortunately, in some occasions, this cup of coffee will be very much needed in order to debug why Specman managed the memory this way, and why all of a sudden I can't run my simulation since it is consuming too much memory, or just failing for other various reasons that are related to memory.

The key to resolving these kind of issues (or better yet - not to reach these kinds of situations all together) is to understand how Specman decides which mechanism to use each time and how to influence those decisions. This paper will hopefully help you understand these points.

Let's start with a quote from documentation (Incisive Enterprise Specman Elite Testbench Specman Performance Handbook, chapter 5 - Managing Specman Memory):

The Specman memory manager periodically frees up space in memory by automatically recycling unusable data. Any object (struct, list, string, or long integer) that is not used by the Specman scheduler or is not connected to sys is considered unusable and defined by Specman as garbage. The recycling process is called "garbage collection" or "GC".

OK -- so garbage would be any unused data that Specman had allocated memory for. In order to identify what is garbage and what is not, Specman determines a very simple thing: whatever is reachable from sys struct (which is the root of anything a user would use) or the scheduler, is NOT garbage. All the rest IS garbage.

Types of Garbage Collection

Now Specman has to get rid of that garbage. Performing the common and most efficient process to do so, which is called Copy Garbage Collection, Specman would simply copy everything that is reachable to a different place in memory, and then free up the entire "old" memory. That would leave us "garbage free."

The main problem with this method is that it might consume a lot of extra memory from the OS just to accomplish this procedure. In worst case (that would be when we have no garbage), the entire memory image would be copied, and in the peak time of that procedure, Specman will consume double the memory than it actually needs.

If there is enough free space on the machine, this is not an issue. The problem starts when the machine can't allocate that much memory for the Specman process. In this case doing Copy GC will be not useful.

This is when the other type of GC is introduced - the Disc-Based GC. This GC comes to tackle the memory prodigal nature of Copy GC, and it does that by doing the exact same procedure as described above, but instead of copying the entire memory image into a different location in memory It copies it to a disc. This mechanism will be automatically used by Specman when it gets an "out of memory" indication from the OS, during the time of Copy GC.

Obviously, the Disc-Based GC will consume more CPU cycles, since it uses an external disc which has a (sometimes major) performance hit.

So what if I don't have enough memory to waste on a Copy GC, nor enough time to waste on Disc-Based GC? This is when the third type of GC gets into the picture - The On-The-fly GC. OTF GC is great from that perspective. It's a lot quicker than Disc-Based GC, and uses less memory by far than the Copy GC. It can also operate on demand by a method call (do_otf_gc()) and will kick in during a Specman tick - a thing that will not happen with the other two GC mechanisms that require a tick (you can think of it as a similar thing to a simulation delta cycle) in order to operate.

However, nobody's perfect. OTF GC does not use the copy principle, but the "mark and sweep" principle, which performs the cleaning job a lot less efficiently.

So as you can see, those three mechanisms complete each other, and each mechanism will be better used in different scenarios. So... who is in charge of when to use each?

GCs Triggers and Settings

It depends... You can ask Specman to do it by using the Automatic Garbage Collection Configuration mechanism (by setting configure memory -automatic_gc_settings=STANDARD - this is actually the default), or keep the decision making to yourself. If you do decide to maintain the memory management by yourself there are few configuration flags you should know and handle:

gc_threshold: The amount of memory that Specman can consume before copy GC kicks in.

max_size : Maximum amount of memory that Specman should use. This is the threshold for OTF GC.

absolute_max_size: Maximum amount of memory that Specman can use before fatally terminating execution.

disable_disc_based_gc: Don't use Disc-Based GC when Specman is "Out Of Memory" during GC (I probably don't have enough disc space, or can't wait for the slower Disc-based GC). Specman will use OTF GC instead.

On the other hand, in case you want Specman to manage those configurations, all you should specify is the optimal_process_size that you would want for this process, and Specman will determine the values above automatically. You should be aware that manually changing any of the above values will cancel the Automatic GC Configuration mechanism.

If you just asked yourself: which one should I use? You probably better off trying the automatic mechanism first. This mechanism can handle most traditional mainstream environments. Nevertheless, if yours isn't such, or you find yourself suffering from memory issues, then switching to the manual mechanism will give you a lot more flexibility to tackle these issues.

Types of Failures

So, what are these memory issues mentioned above?

Let's differentiate between two types of issue:

1. Specman Memory Management errors / warnings

2. OS errors

The first one is easier and usually can be solved by changing the Memory Management parameters. It also deals only with Specman memory consumption and not the entire process that Specman is a part of. The first and more common error you might get from Specman's memory management is the following error:

*** Error: Total memory requested from operating system exceeds get_config(memory,max_size) (419430400). Will exit at get_config(memory,absolute_max_size) (471859200).

So this error tells us that we had hit some pre-defined values (max_size, absolute_max_size) that are supposed to limit Specman's memory consumption. These values are described above, and will be set either automatically by the automatic mechanism (which means in this case that the automatic mechanism was not very successful...) or by the user himself. There is another option in which the user does not use the automatic mechanism, but still did not specify those values. In this case, default values would be assigned to them (the numbers in the specific message above).

Another issue you might have -- one that is related to Specman Memory Management -- is getting too many consecutive GCs. This will slow down simulation tremendously, and will keep on printing GC messages to the screen. This will happen when the gc_threshold or max_size parameters are not tuned up correctly. This means that the "steady" memory Specman needs is actually higher than those thresholds, sending Specman to do GC all the time, but it will probably never get to equilibrium.

These are the easy errors to handle -- and you probably wish to be left dealing with them, as both of the problem's solutions are pretty easy.

On the other hand, the second type of errors -- OS errors -- is a bit more tricky to deal with. Let's first look at what we mean by a process:

PID #123456

As you can see from the diagram, the process with PID #123456 (just an example) can contain several applications running together, and sharing a specific allocated segment of memory on the machine.

If we are dealing with 32 bit applications, the maximum size of this process could not go over 4GB (if you run the 32 bit process on 32 bit machine - the OS allows just about 3G of user data to the process, and the rest is allocated to the kernel, so the quota is even less).

With 64 bit applications, the size is not limited by a specific number, but by other specific OS considerations. However, there might be several other processes on that machine that need some memory as well. For this the OS uses what's called "virtual memory" which fragments some of the process memory and puts it on disc instead of the RAM. We will not go into details of this mechanism now, but in general the entire process size (In RAM + disc) is called VSIZE, and this size is limited by the OS.

You can now understand, that when this VSIZE goes over what is given by the OS to this process, it doesn't really matter (to the OS) which of these applications is responsible for this amount of memory requested. But when it decides to "cut off" the supply (i.e. a memory allocation request will return NULL) the application that was doing the malloc in that time frame would have to deal with it, but the entire process is thrown out. Every application can deal with it differently. Specman will issue an "Out Of Memory" error in the best case, or crash with an OS11 signal in the worst case (usually when some memory corruption was caused by this excessive usage of memory).

When dealing with these kind of situations, we need to first identify which of these applications is the one taking most memory, and moreover, which is the one that can go on a diet for the sake of this process.

For this analysis, there are several tools and utilities we can use for every application. For Specman we have the memory debug flags, and the memory profiler. These will not be discussed in this paper, as debugging techniques are a broad issue which requires an entire paper to go over.

Summary

If we understand the basic behavior of Specman's Memory Management mechanism , we will be able to identify most of the memory problems that pop up during our work. It is very important to identify whether it's a Specman error that is complaining we have a setting that is responsible for this error, or an OS error that is complaining about the process that Specman is a member of.

The most important thing is to identify when Specman is not behaving as we think it should be. If we will identify this point, and the reason for this "misbehavior," we will be half way towards the resolution of the problem (or the identification of a Specman bug...).

The below flow chart is very useful to use when you want to analyze Specman actions and reactions, and the relations between all types of GCs and what will kick in each one of them. It will also show the paths to errors that could help identify what you need to focus on in order to make them go away.

Avi Farjoun, Cadence Design Systems

Video Tech Tip: Data Path Verification Using a Formal Scoreboard with Incisive Formal Verifier

TeamVerify — Wed, 09 May 2012 00:18:00 GMT

This 6 minute video is a quick overview of our formal scoreboard app. Specifically, the video references the same AXI bridge example included with Incisive Formal Verifier (IFV) and Incisive Enterprise Verifier (IEV) so you can follow along on your workstation!

If video does not open, click here.

If you want even more background on this app, I invite you to watch the webinar recording on this topic, "Quickly Find Data Transport Bugs with Formal Scoreboarding".

Happy Scoreboarding!

Joerg Muller
Solutions Engineer
Cadence R&D
for Team Verify

On Twitter: http://twitter.com/teamverify, @teamverify

And now you can "Like" Team Verify on Facebook too:
http://www.facebook.com/pages/Team-Verify/298008410248534

UVM SystemVerilog Video Series Brings Verification World "More Cowbell!"

Axel Scherer — Thu, 03 May 2012 18:08:00 GMT

To quote an American pop culture catchphrase made famous by Saturday Night Live character Bruce Dickison, "I gotta have more cowbell!"

In the world of functional verification this translates to "more collateral!" Thererfore, we have released a set of byte-size videos about the basics of the Universal Verification Methodology (UVM) for SystemVerilog. Each video is under 5 minutes long and includes sound, so put on your headphones and get "more cowbell!"

This series is an introduction into the basic concepts, architecture and components of UVM. It features a mixture of slides and demos.

We decided to release the entire series publicly on YouTube [click here to view].

If you have UVM fever, remember the only prescription is "more cowbell!".

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

My Constraint was Ignored – Is it a Tool Bug? IntelliGen Gen Debugger Can Help!

teamspecman — Tue, 24 Apr 2012 13:06:00 GMT

The IntelliGen Gen Debugger is a powerful Specman tool that can debug any generation problem that you might face. The most obvious and common generation problem is a contradiction, but the Gen Debugger can handle various other problems, such as user errors, performance problems and unexpected generation results.

In this post, we will focus on one of the most extreme cases of unexpected generation: a constraint which is not enforced. This can happen due to problems with your code, even in a simple example such as the following:

Let’s explore a situation where the above code fails with a DUT error, and examine the full debug process – from detecting and identifying the problem to tracing its root cause.

Let’s debug!

Because the above code does a check that p.x == 100, we must conclude that if this check failed, it must be that p.x is not 100, and the constraint we gave was not enforced. Now our task is to identify the cause of failure.

We can do this by performing the following steps:

1. Open the Gen Debugger at the generation of the field. We do this as follows:

a. Issue the following command: ‘config gen –collect = ALL’. This activates the Gen Debugger, and ensures that it keeps all information. (Note: In Specman versions prior to version 11.1, the command is: ‘br gen err; config gen –del_old_dbg_info = FALSE’)

b. Issue the following command: ‘br on error’. This ensures that the Gen Debugger stops at the dut_error, so that we can determine what failed.

c. After the Gen Debugger stops, issue the following command: ‘show gen –instance p.x’ (you can specify any legal path to the relevant variable). This opens the Gen Debugger at the generation of the problematic field. This command is particularly useful when using the Gen Debugger in ‘offline’ mode, after the generation has finished. If you stop during generation (for example, on an error), the ‘gtree’ command will open the gen debugger in its current state.

In our example, the following figure illustrates the result.

Interestingly, the generated value (highlighted by the Gen Debugger in blue) shows us that the constraint was enforced.

This means that for an error to have occurred, that generated value had to have been changed later on during processing. But where? How do we find the procedural location of the change?

The good news is that we can use the Gen Debugger to help us as we try to pinpoint the location of the problem. But first we need to perform a rerun, stopping immediately after the generation.

2. Ascertain the needed values and then rerun the test as follows:

a. In the Gen Debugger, look for the Gen-Action and Connect Field Set (CFS) values. In our example (see the following figures), the Gen Action value is 2, and the CFS value is 20.

and

b. Reload the code and issue ‘br on gen action # cfs #’ (in our example, ‘br on gen action 2 cfs 20’), so that the test reruns and stops immediately after the generation.

c. After the run is completed, issue ‘gfinish’, which will advance to the completion of this CFS, and check the results (see the following figure). Notice that p.x. has the correct value.

At this point, the role of the Gen Debugger is over, and we need to use the source debugger. Since the problem is not in generation, we need to find out where in the procedural code this value was changed.

3. Issue the source-debugger command ‘br on change sys.p.x’ and continue. This will stop at the code which is responsible for the discrepancy (see the following figure).

In summary:

Through this example, we saw that what might seem to be an ignored constraint can actually be caused by a problem elsewhere (that is, that the constraint has not been ignored.)

And in the process, we learned how to use the Gen Debugger to help locate the actual source of the problem, and we saw several aspects of the Gen Debugger, including:

· its offline and online debug capabilities (Steps 1 & 2, respectively)

· its connection to the source debugger (Step 3)

In the next post, we will see additional possible causes for the “ignored constraint” behavior, and in the process we will further examine Gen Debugger functionality.

Reuven Naveh, IntelliGen team, Specman R&D

Analyzing Error Reports When Specman Crashes

teamspecman — Tue, 17 Apr 2012 16:46:00 GMT

One of the most frustrating events while running a tool would be to experience a tool crash.

In Specman you would usually see something like:

*** Error: OS signal 11 (segmentation violation) received

See the stack trace in ./specman.err

To debug:

---------

o Rerun the same test with the same seed in interpreted mode, after

setting "break on error". Load also any previously compiled modules.

** One user module is compiled.

o For help on debugging e code, see "Debugger Commands" and "Source

Code Debugging" in the online help.

o If any user C code is linked into the Specman environment, try

debugging it using a C debugger to ensure that you are not accessing

any null pointers or memories not allocated by the C program.

If the problem is still not resolved, please send to Cadence support :

1. Description of how you have tried to resolve the problem

2. ./specman.err

3. /home/avif/draft/crash.elog

(Error itself might vary, as we will see shortly)

However, there are some things you can do in such cases that will help you to either resolve the issue, or narrow it down so that Cadence Support can find a faster resolution.

In such event of a Specman crash, Specman will create a specman.err file. Your overall goal would be to determine the cause of the crash and then try to correct or eliminate the cause.

This post comes to help you understand what the elements in the Specman error report are, and how to use the report details, in order to identify the cause and what actions to take.

Error report layout

When Specman crashes, it creates an error report file (specman.err) in the run directory. This file contains the information that can help you identify the cause of the error, so that you can take steps to correct or eliminate the problem.

This specman.err file includes the following parts:

Top section - specifies the error
Raw stack trace - stack that contains the interpreted symbols of the compiled code (generated when the compiler is compiling Specman). You might not find this stack trace very useful, but its contents can be very important to Cadence Support and R&D, especially in cases where the crash was caused by a bug in an internal Specman module.
Interpreted stack trace - provides interpretation of the symbols found in the raw stack trace. It essentially translates C-functions to their corresponding Specman internal methods.
User View stack trace - Stack trace at the time of the failure, provided in user recognizable terms. This is the stack trace that you are likely to find most useful, because it generally identifies the module and line in the user code where the problem started.
# of compiled modules - single line that specifies how many files are compiled in this testbench.
Bottom section (environment data) - the bottom of the error file provides environment data such as the platform you are running on, the patches included in the simulation, packages loaded (including Specman and UVCs, and their versions).

Identifying the problem

Following a Specman crash, first thing you should do is examine the specman.err file, proceeding in the following sequence:

1. Examine the error message(s) in the top section to determine the error type (see the list below).
2. Examine the User View stack trace and identify to which module and line it points.
3. Open the identified module and examine the contents of the identified line. It should provide important details regarding the nature of the problem.
4. Handle the problem appropriately, according to the error type (listed below).

This post specifies problem identification, and will provide handling guidelines, for the following error types:

1. OS11
2. OS11 during garbage collection
3. Unhandled OS11
4. Memory exceeded absolute_max_size
5. Specman internal error

1. OS11 errors

Let's say you got an OS signal 11 error:

========================================================

OS signal 11 (segmentation violation) at Tue Aug 10 10:46:37 2010

OS signal 11 (segmentation violation) received

========================================================

As stated in the error message, the first thing to do is check is if the crash happened in compiled mode (that is, if the e-testbench is compiled):

If so, you should run it in interpreted mode (that is, so that the e-testbench is loaded), and see if you can get a meaningful error message in this mode.
If you cannot run in interpreted mode, you should recompile the environment with the -debug flag (‘sn_compile.sh -debug ...' or ‘irun -sncompargs ‘-debug'...'). Specman will then add additional checks, which might provide meaningful error messages than provided by the crash.

If the crash persists also after trying one of the above and you don't get any meaningful message, you will need to analyze the crash.

Recommended handling

1. Examine the User View stack trace and identify to which module and line it points.
2. Open the module and examine the line to which the User View stack trace points. See if it contains a call to a C routine.
3. Check Interpreted stack trace and see if it points to a user library. For example:

***** Interpreted stack trace:

( 0) 0x85f2601 ahb_create_instance + 0x9 [./libahb_mytb.so]

If (2) or (3) are correct, it probably means that the error comes from your C code, and you now need to debug your own library/C code. In this case:

4. You might try setting the environment variable SN_HANDLE_ALL to none (‘setenv SN_HANDLE_ALL none'), and rerun. This instructs Specman not to catch any signal. This will allow other tools to catch their signals, and might facilitate a more informative stack.
5. In either case, to debug your C code using gdb, you should
- Recompile your C code with -g.
- Rerun with gdb attached and debug your C code.

For more information regarding debugging C Interface code, please refer to "Incisive Enterprise Specman Elite Testbench Integrators Guide", Chapter 1.16 - Debugging C/C++ Code

2. OS signal 11 during garbage collection

The following is an example of an OS 11 message issued during garbage collection (GC). This error hints that GC probably found inconsistency with the e types that might have been caused by a memory corruption.

================================================================

Internal Error at Wed Nov 9 04:40:14 2011

: Fatal error

OS signal 11 (segmentation violation) during garbage collection - must exit.

================================================================

Recommended handling

Set ‘config mem -check_consistency=TRUE', and rerun. Specman will print the path to the corrupted struct, if one exists. This information might help Cadence Support to debug the issue.
If Specman's check consistency option did not return anything, try to get more information on the memory consumption by turning on the memory debug flags and rerunning; the recommended flags are: ‘config mem -show_mem_raw=TRUE' and 'config mem -print_debug_msgs=TRUE'. Then send the log to Cadence Support.

3. Unhandled OS signal 11

The following is an example of an Unhandled OS signal 11 message:

============================================================

OS signal 11 (segmentation violation) at Wed Mar 10 13:26:05 2010

Internal Specman Error: unhandled OS signal 11 (segmentation violation).

============================================================

An unhandled OS signal 11 message often indicates that Specman caught an OS signal which it should not have - for example, a signal that was sent to a third-party tool or to the simulator.

You should examine the User View stack trace and the Interpreted stack trace and see where they point.

In the following example, the User View stack trace clearly points to the simulator:

***** User View stack trace:

( 0x0) simulator

In another example, the Interpreted stack trace points to the simulator:

***** Interpreted stack trace:

( 0) 0x80c42bc

( 1) 0x80c4a0e

( 2) 0x80c5ef5

( 3) 0x80c635e

( 4) 0x839d775

( 5) 0x86a3612 TclInvokeStringCommand + 0x73 [ncsim]

( 6) 0x86a4f5f

( 7) 0x86a597f Tcl_EvalEx + 0x36e [ncsim]

( 8) 0x86a617f Tcl_EvalObjEx + 0x19f [ncsim]

Recommended handling

In order to identify the actual source of the crash, set environment variable SN_HANDLE_ALL to none (‘setenv SN_HANDLE_ALL none'), and then rerun. This instructs Specman not to catch any signal; this will allow other tools to catch their signals, and might also facilitate a more informative stack. Note: This flag should only be used for debug purposes.

4. Memory requested from the operating system exceeds limit

The following is an example of the messages issued when Specman reaches the user-defined maximum memory allowance granted to Specman (absolute_max_size):

========================================================

Internal Error at Mon Nov 7 22:29:34 2011

: Fatal error

Total memory requested from operating system

exceeds get_config(memory,absolute_max_size) (5242880000)

========================================================

You should try to determine why the memory's absolute_max_size was reached. For example, it might be that

this memory settings is not high enough for this environment and you need to increase the absolute_max_size value (config memory -absolute_max_size=<higher value>).
the environment's memory consumption is too high and you need to profile your testbench.

To resolve the later memory consumption problem, search for "Specman memory consumption is too high" in Specman documentation, and ascertain what steps you should take to tackle the problem.

5. Specman internal error

Although there is little you can do if a bug in a Specman module causes an internal error, there are some steps you can take in order to help Cadence Support identify the issue faster.

Internal errors are generally accompanied by additional information that helps to narrow the suspected area of code. If an internal error ((a) in the message below) is accompanied by a message that points to a line in an internal Specman module (d), it generally indicates that the error was caused by a bug in that Specman module (which is detailed in (b) and (c)).

(a) Internal Error at Wed Jan 25 13:13:38 2012
(b) : assert more_general != NULL
(c) In 'gen_constraint.get_status_for_me_role()' at line 896 in
(d) /vobs/specman/src/gen_static_gcroles.e

The accompanying User View stack trace shows the calls which lead to the crash:

***** User View stack trace:

( 0) analyzing constraint at line 39 in @intc_basic_types

( 1) gen context #145 tb_env_config_s

( 2) generation static analysis (finalize)

( 3) generation static analysis

( 4) pre specman run

( 5) specman

Recommended handling

When you encounter a Specman internal error, you should send the specman.err file to Cadence Support, along with the module file to which the User View stack trace points to. If you cannot send the module file, try sending the code around the line in that module to which the User View stack trace points.

Happy Debugging!

Semadar Sadeh & Avi Farjoun