Team Specman Blog

Mode Support for SimVision “Stop Simulation” Button

teamspecman — Wed, 08 May 2013 13:32:00 GMT

Prior to Incisive Enterprise Simulator (IES) 12.1, clicking the SimVision "Stop Simulation" button would stop the simulation both in an HDL context and in a Specman context if Specman was present in the simulation. To provide better flexibility in the exact place where you want to pause, the "Stop in Specman only" functionality has been introduced.

As of IES 12.1,whenever Specman is present in the simulation, the SimVision "Stop Simulation" button provides a drop-down menu that lets you choose between two switchable modes: "Stop Simulation" (wherever the simulation is now), and "Stop in Specman" (see the following figure).

SimVision will immediately perform the "Stop" operation in the mode you select, and keep that mode persistent. It will also indicate the selected mode in the button icon and tooltip (see the following figure).

Note the "e" over the button. The "e" indicates that you selected "Stop Specman" mode. (Had you chosen Stop Simulation, no indicator would appear over the button.)

When you click the "Stop" button while SimVision operates in "Stop Specman" mode, the simulation will stop only when it is in Specman, not before.

To toggle between the Stop Simulation modes, just make your new choice in the dropdown menu.

Note that if you run the simulation without Specman, or invoke standalone Specman, the drop-down menu is absent and the "Stop" button works in "Stop Simulation" mode (see the following figure).

Alex Chudnovsky

Develop For Debugability – Part II

teamspecman — Tue, 23 Apr 2013 13:00:00 GMT

Looking at Coding Styles for Debug

In this blog post we are going to discuss 3 different cases where coding style can help you debug easier:

1. Declarative vs. Sequential Coding

2. Method Call Depth

3. Calculating if-else Conditions

Declarative vs. Sequential Coding

When modeling your testbench you will need to write code that describes time-consuming or complex steps of some intended behavior. This will be considered sequential code.

You will also most likely need code that keeps the current state of your object accessible to other objects, as well as tracking these object states over time. This will be considered declarative code.

While developing your testbench you will find yourself asking quite often: "Should I make this declarative or sequential?" As a general guideline, reducing the number of sequential lines of code and keeping as much information as possible in the declarative code will help you to debug a lot quicker.

Specman has a superb data-browser and step-debugger and it is important to keep this in mind. When debugging code you usually want to see where the testbench and the RTL go out of sync. The common approach would be to fire up your failing simulation and set the breakpoints:

Specman> break on error

Specman> break on gen err

This will make your simulation stop on an error and open up the debugger, highlighting the precise line where the error occurred. In an ideal case, you can already tell from your error description what went wrong. This however is rather rare and you should get acquainted with the current state of your testbench and gather all declarative information you can get through Specman's data browser. This will give you an understanding of where the simulation has headed, and chances that you will understand the error are pretty good if you tracked enough information in your declarative code. If you are fortunate enough you can already resolve the error or at least have a conversation with the person that might have to fix this scenario.

However, there are still quite a few cases where you need to rerun the simulation. Here you will have to dive into the remaining sequential code and do a step-by-step debugging session. Step-debugging is very tedious and will get more cumbersome the more sequential code you have to examine. It gets even more cumbersome if you are relying on a lot of temporary variables inside your methods.

Method Call Depth

While developing sequential code you will be defining and implement a bunch of methods. Crafting methods is usually a straightforward process. In verification you need to think aboiut whether you need a time-consuming method (TCM) or a timeless method. As a general rule, if you are modeling event-based models or checks, then you need a TCM -- otherwise try to stick with a regular, timeless method.

Mostly you will be developing methods for:

Interface and Virtual Sequences
Interface Monitors (not block-level monitors)
Bus-Functional Models (BFMs)
Reference Models
Scoreboards

Due to this separation of functionality, given by the UVM-e, there is already a given blueprint for how to integrate these methods with each other.

One issue that may come from developing methods is that one may feel tempted to create methods for reusability and hence encapsulate even trivial steps in a method and have that method called, instead of typing out these steps. The problem with debugging code that relies heavily on method calls is that you always step into a new method and lose the scope of your method's callee.

The opposite problem of creating too many methods implements mega-monolithic methods. These kinds of methods are hard to debug and understand as well, since they usually not only carry the context of one specific modeled aspect.

Pre-Calculating if-else Conditions

The essence of code execution is handling conditional branching constructs. Generally there is nothing wrong about simply writing a condition into your if-else actions. However, complex Boolean expressions should be evaluated before entering the expression query. By creating a temporary variable and assigning a Boolean evaluation to it, you will gain two advantages:

Create a meaningful variable name
Break on the if-execution with the condition already evaluated

To read part 1 of this blog series, click here.

Daniel Bayer

Develop for Debugability – Part 1

teamspecman — Mon, 08 Apr 2013 14:00:00 GMT

Debugging is the most time-critical activity of any verification engineer. Finding a bug is very often a combination of having a good hunch, experience, and the quality of testbench code that you need to analyze. Since having a good hunch and experience is something everyone needs to acquire for themselves, I am going to focus on potential code optimizations that help reduce debug time.

Encapsulate your Aspects

As in any other object-oriented language, modeling should be a planned rather than an ad-hoc process. However, as a verification engineer you are heavily reliant on others to help you in the planning process to develop your testbench. As such, you will quite often be forced to do ad-hoc programming to model a new requirement, or rewrite already existing code to meet a slight change in an already existing requirement. The UVM-e guidelines already provide a very solid basis; however even within those guidelines, your scoreboard can be very prone to becoming a dumpster for anything that you have to do on an ad-hoc basis.

You might be fine with just using your scoreboard for modeling all the RTL-to-testbench output checking. However, your testbench might have to handle more complex input-to-output transformations to provide the testbench output. This is where using the scoreboard as a dumpster for anything you can think of is a bad idea, and you should think about using a dedicated reference model to provide a well encapsulated input-to-output transformation or even an input predictor, based on the output you received.

As an e user you are in luck, because it is very easy to perform ad-hoc programming in e and avoid "the dumpster." In a series of steps, I am going to guide you through how to integrate your reference model into your block-level monitor unit.

Declare your scoreboard

<’

// This is just a place-holder for your scoreboard

unit my_scbd_u like uvm_base_unit {

// Place-holder method for input-to-output transformation

transform_received_to_expected( src_tr: src_prot_tr_s ): target_prot_tr_s is empty;

};

‘>

2. Instantiate your scoreboard in the Block-Level Monitor

<’

unit my_block_monitor_u like uvm_base_unit {

// the scoreboard instance

scbd: my_scbd_u is instance;

};

extend my_scbd_u {

// reference, do not generate

!p_block_mon: my_block_monitor_u;

connect_pointers() is also {

p_block_mon = get_enclosing_unit( my_block_monitor_u );

};

‘>

3. Create your reference model aspect feature and instantiate it in the monitor

<’

unit my_model_aspect_a_u like uvm_base_unit {

// reference to your monitor unit

!p_block_mon: my_block_monitor_u;

// All your fields, events, methods etc go in here

// ...

my_transformation_algorithm( src_tr: src_prot_tr_s ): target_prot_tr_s is {

// algorithm that models the transformation from input to output

};

connect_pointers() is also {

p_block_mon = get_enclosing_unit( my_block_monitor_u );

};

// Add a name for your model

short_name(): string is also {

result = ”ASPECT_A”;

};

extend my_block_monitor_u {

model_aspect_a: my_model_aspect_a_u is instance;

};

‘>

4. Integrate the first model aspect into the scoreboard

<’

extend my_scbd_u {

// Reference the aspect

!p_model_aspect_a: my_model_aspect_a_u;

// Add the transformation hook

transform_received_to_expected( src_tr: src_prot_tr ): target_prot_tr is {

result = p_model_aspect_a.my_transformation_algorithm( src_tr );

};

connect_pointers() is also {

p_model_aspect_a = p_block_mon.model_aspect_a;

};

‘>

5. Adding more aspects to the verification environment.

<’

extend my_scbd_u {

// Reference another aspect

!p_model_aspect_b: my_model_aspect_b_u;

// Add the transformation hook for another model aspect

transform_received_to_expected( src_tr: src_prot_tr ): target_prot_tr is also {

// This could be an example of a filter that alters or removes transactions

result = p_model_aspect_b.apply_filters( );

};

connect_pointers() is also {

p_model_aspect_b = p_block_mon.model_aspect_b;

};

‘>

In this flow, steps 1 through 4 have to be done once, and step 5 is simply just extending your transformation hook method with any additional algorithms you need to add to your scoreboard.

By following these steps as a guideline, you can quickly change reference model aspects to your scoreboard without creating a dumpster and this will help you debug any issues tremendously. Don’t forget to extend the short_name() method in your units for your messaging!

Daniel Bayer

Specman: Getting Source Information on Macros

teamspecman — Tue, 12 Mar 2013 23:31:00 GMT

When you write a define-as or define-as-computed e macro, you sometimes need the replacement code to contain or to depend on the source information regarding the specific macro call, including the source module and the source line number.

For example, a macro may need to print source information, or it may need to create different code when used in one module than it needs to create when used in other modules.

You can achieve this as follows.

Define-as macro

In a define-as macro, you can use the following two special kinds of replacement terms inside the replacement block:

<current_line_num>	This is replaced with the decimal numeric representation of the source line number in which the macro is called.
<current_module_name>	This is replaced with the name of the module in which the macro is called.

For example, the following macro modifies the given left hand side expression (such as a field or a variable) to the given value, and prints an informational message reporting this change.

define <my'action> "modify_and_print <field'exp> <value'exp>" as {

<field'exp> = <value'exp>;

out("*** The value of <field'exp> was changed to ", <value'exp>,

" at line <current_line_num> in @<current_module_name>");

};

‘>

Assume the following code is then written in a module called my_module.e:

extend sys {

!x: int;

run() is also {

modify_and_print x 10;

};

‘>

This code will assign the value 10 to the field x, and will print the following output:

*** The value of x was changed to 10 at line 5 in @my_module

Define-as-computed macro

In a define-as-computed macro, the following two pre-defined routines can be used to query the current source line number and the current module.

get_current_line_num(): int	This routine returns the source line number in which the macro is called.
get_current_module(): rf_module	This routine returns the reflection representation of the module in which the macro is called.

To get the module name string, similarly to <current_module_name> in define-as macros, use the get_name() method of rf_module.

For example, the following macro adds a new field of type int to the struct in the context of which it is called. The field name is constructed from the current module name and line number. However, if the module name has the "_xxx" suffix, no field is added.

define <my_field'struct_member> "special_field" as computed {

var m_name: string = get_current_module().get_name();

if m_name !~ "/_xxx$/" then {

result = append("f_", m_name, "_",

get_current_line_num(), ": int");

};

‘>

The following code, if written in a module called some_module.e, adds two integer fields to sys: f_some_module_3 and f_some_module_4:

extend sys {

special_field;

};

‘>

Note however that if the same code is written in a module called some_module_xxx.e, nothing is done.

Yuri Tsoglin

e Language team, Specman R&D

Using the ‘restore -append_logs' Feature

teamspecman — Tue, 12 Feb 2013 14:00:00 GMT

As described in Specman Advanced Option appnote, Specman Elite supports dynamic load and reseeding. This allows the user to run the simulation up to a certain point (often until right after reset) and save the simulation. The user can then restore the simulation and run many different tests either by changing the random seed (reseeding) or by loading additional e files which will change the test, e.g., adding constraints (dynamic load).

But many customers who use this new methodology have come across a problem. If a DUT error occurs in one of the new runs, and there is a need to debug the failure, usually the first step is to check the various log files. However, with this methodology we only have log files from the restore point and later; anything written to the log file from the original run until the save is lost. So we don't actually have the full log file, and this can make debugging more difficult.

To avoid this problem and be able to see the full log file, the user must first save the simulation with the log files (do not worry about the size, the file is compressed). Then, when restoring the simulation, the user must add a switch the tell Specman to append the current log files to the previously saved ones.

To support this capability, the following switches were added:

Specman:
- The save command will have an additional switch: -with_logs
- The restore command will have an additional switch: -append_logs
Ncsim:
- The save command will have an additional switch: -snwithlogs
- The restart command will have an additional switch: -snlogappend
Irun:
- The command line will have an additional switch: -snlogappend

So, how do you use this feature? We will show you, using the basic xor example which we shortened to 2 operations. If we run using the command:

irun xor.v -snload xor_verify.e -exit

the Specman log file will look like this:

Starting the test ...

Running the test ...

Running should now be initiated from the simulator side

it = operation-@7: operation of unit: sys

---------------------------------------------- @xor_verify

0 %a: 0

1 %b: 0

2 !result_from_dut: 0

p_out$ = 0

(it.a ^ it.b) = 0

sys.time = 150

it = operation-@8: operation of unit: sys

---------------------------------------------- @xor_verify

0 %a: 1

1 %b: 1

2 !result_from_dut: 0

p_out$ = 0

(it.a ^ it.b) = 0

sys.time = 350

Calling stop_run() from at line 45 in @xor_verify.

Last specman tick - stop_run() was called

Normal stop - stop_run() is completed

Checking the test ...

Checking is complete - 0 DUT errors, 0 DUT warnings.

Now let's run the example with save and restore. First we'll do the save:

irun xor.v -snload xor_verify.e -tcl

ncsim> run 200ns

ncsim> save foo -snwithlogs

ncsim> exit

Now, if we run using the command:

irun -r foo -exit

the Specman log will contain:

Restored Specman state INCA_libs/worklib/foo/v/savedir/sn_save.esv

it = operation-@8: operation of unit: sys

---------------------------------------------- @xor_verify

0 %a: 1

1 %b: 1

2 !result_from_dut: 0

p_out$ = 0

(it.a ^ it.b) = 0

sys.time = 350

Calling stop_run() from at line 45 in @xor_verify.

Last specman tick - stop_run() was called

Normal stop - stop_run() is completed

Checking the test ...

Checking is complete - 0 DUT errors, 0 DUT warnings.

However, if we run using the command:

irun -r foo -snlogappend -exit

The Specman log will contain:

Starting the test ...

Running the test ...

Running should now be initiated from the simulator side

it = operation-@7: operation of unit: sys

---------------------------------------------- @xor_verify

0 %a: 0

1 %b: 0

2 !result_from_dut: 0

p_out$ = 0

(it.a ^ it.b) = 0

sys.time = 150

Restored Specman state INCA_libs/worklib/foo/v/savedir/sn_save.esv

it = operation-@8: operation of unit: sys

---------------------------------------------- @xor_verify

0 %a: 1

1 %b: 1

2 !result_from_dut: 0

p_out$ = 0

(it.a ^ it.b) = 0

sys.time = 350

Calling stop_run() from at line 45 in @xor_verify.

Last specman tick - stop_run() was called

Normal stop - stop_run() is completed

Checking the test ...

Checking is complete - 0 DUT errors, 0 DUT warnings.

We see that in this latest run the log file was appended to the log file of the run of the save command.

It is important to note that only Specman log files are affected by this switch; irun and ncsim log files are not affected.

Avraham Bloch

Specman R&D

P.S. Reminder: To discuss this feature, Specman in general, and the new Incisive Debug Analyzer, R&D’s Nadav Chazan will be at DVCon Feb. 26-28, 2013. Ask for him by name in the booth, or sign-up for his tutorial on Thursday February 28 on “Fast Track Your UVM Debug Productivity with Simulation and Acceleration”. More info: http://dvcon.org/2013_event_details?id=144-5-T

DVCon 2013 for the Specmaniac

teamspecman — Fri, 08 Feb 2013 00:09:00 GMT

At the upcoming DVCon (in San Jose, CA February 25-28), Cadence will cover all aspects of our verification technologies and methodologies (full list of Cadence-sponsored events is here). Of course, Team Specman cannot resist drawing your attention to the many activities that will feature Specman and e language-related content, or be of general relevance to Specmaniacs. Hence, if you are going to the conference, please consider printing out the following "DVCon 2013 Guide for the Specmaniac".

* Specman-centric posters at the poster session on Tuesday from 10:30-11:30am

1P.21 "Taming the Beast: A Smart Generation of Design Attributes (Parameters) for Verification Closure using Specman", presented by Meirav Nitzan of Xilinx, Inc., with co-authors Yael Kinderman and Efrat Gavish of Cadence R&D.

1P.25 "Maximize Vertical Reuse, Building Module to System Verification Environments with UVM e", presented by Horace Chan of PMC-Sierra, Inc., with co-authors Brian Vandegriend and Deepali Joshi also of PMC-Sierra, Inc., and Corey Goss, a Solutions Architect in Cadence R&D.

The best part about the poster session is you can easily interact with the authors - asking them questions on the fly in a way that would be awkward if they were presenting the paper in a lecture format.

* The Cadence booth at the free expo on Tuesday & Wednesday Feb. 26-27, 3:30- 6:30pm each day

As always, Specman technology is directly or indirectly a cornerstone of the various demos -- UVM, Verification IP, metric-driven verification & Enterprise Manager updates, ESL & TLM updates, etc. This year we will be showcasing new automated debug technology - the Incisive Debug Analyzer - that works great with e/Specman testbenches. Even better: R&D leader Nadav Chazan will be present to walk through the tool with you and answer your questions. Of course, at a relatively small show like DVCon there is often the opportunity to digress from the primary demo(s) and discuss Specman technology updates in specific - Nadav and other members of Team Specman will be happy to give you the highlights of the new capabilities release in Specman 12.2 and more.

* Thursday morning Feb. 28 tutorial (8:30am-Noon), "Fast Track Your UVM Debug Productivity with Simulation and Acceleration"

In this comprehensive tutorial, Specman R&D's Nadav Chazan along with hardware assisted verification expert Devinder Gill will show how you can reduce debug turnaround time of class-based, software-like environments (i.e. like an e/AOP testbench). Specifically, they will show how to leverage low latency interactive debug techniques to improve debug efficiency, where the user has a much broader range of capabilities at their disposal. This includes interactive features such as forward and backward source code single-stepping, searching for arbitrary values and types, and automated go-to-cause analysis. Come prepared to take plenty of notes because Nadav and Devinder will walk through many detailed examples.

* Bonus: A free lunch on "Best Practices in Verification Planning" Wednesday Feb. 27!

On the Wednesday of DVCon Cadence is hosting an expert panel on "Best Practices in Verification Planning". Panel moderator, R&D Fellow Mike Stellfox (yes - *that* Mike Stellfox who's been with the team since Verisity days), will kickoff this important discussion on how creating and executing effective verification plans can be a challenging mix of art and science that can go sideways despite the best efforts of engineers and managers. Note that this won't be confined to RTL verification planning only -- the panel also includes experts on analog-mixed signal verification and formal analysis.

Panel discussion at DVCon 2012

We look forward to seeing you in-person soon!

Team Specman

Reference Links

The official DVCon website

Comprehensive list of Cadence-sponsored events & papers

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.

DVCon 2012 video playlist

60 second highlights video from DVCon 2012

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

And on Facebook: http://www.facebook.com/teamspecman

Specman: An Assumed Generation Issue and its Real Root Cause

teamspecman — Mon, 21 Jan 2013 16:00:00 GMT

Random generation is always a complex task, and differences in results are usually very hard to debug. Besides, generation misbehavior always rings many bells in R&D :-)

A customer reported a random stability issue, explaining that the generator (IntelliGen) generated different values with the same seed. One simulation was started from vManager, the other in a Unix shell, and they ran in different run modes (compiled vs. interpreted).

Looking into the (quite complex) environment, it turned out that the beginning of the simulation was identical, but as time advanced the results started to differ. I assume some of you have experienced similar behavior in the past.

A first look revealed that complex list manipulations were performed in many levels of nested method calls. Each list -- a list of units -- was manipulated by several list methods (sort, add, unique, etc.). The results were printed out to the screen where, after a while, the lists started to differ.

So an idea came to mind: The problem is probably not a generation issue, as the static generation was identical in all cases; rather it is a runtime issue, most likely caused by list manipulation. But how could the way the simulation was launched or the run-mode be responsible for the differences?

With no alternative, we proceeded to debug through the source code step by step, and examined the list after every manipulation. The complexity and deep nesting of the code (there were even recursive methods that touched those lists), resulted in about two days of painstaking analysis without finding a difference. Then, we hit pay dirt -- we came across the construct where the lists began to differ. Below is the sample code:

So where is the problem? The code identified that the list of units that was sorted, but did not identify the specific field used for sorting -- the argument (it) referred to the unit itself.

Looking up the sort() method in the Incisive/Specman documentation, we found the following:

The Note in the description seemed to suggest a possible clue.

A scan of the log files showed that the vManager run started a garbage collection at some point before the sorting action, and that the plain Specman simulation logs did not show this garbage collection. This difference in behavior was the result of different memory settings between different simulation runs.

The bottom line: Garbage collections can change the physical memory address of the units in the list, which can affect the sorting of these addresses before and after such a memory operation.

Summary:

The root cause for the problem was that the sorting statement contained a bad argument (the result of a copy and paste error) -- the construct was taken from code where it worked perfectly fine with a list of strings.
The problem was not generation-related, even if it looked that way in the first place.
More importantly, we uncovered usage of a problematic construct: The user based the sort on the physical address. This should be avoided even if garbage collection is not performed (and all the more so when garbage collection is performed).
Uncovering such an issue is a perfect task for the Specman Linter. Cadence intends to enhance the linter's capabilities in that direction.

Hans Zander

Specman: Determining a Good Value for optimal_process_size

teamspecman — Tue, 01 Jan 2013 16:00:00 GMT

Specman's Automatic GC Settings mechanism is aimed at eliminating the need for users to control the parameters which determine each Garbage Collection's behavior.

Setting config mem -automatic_gc_settings=STANDARD tells Specman to calculate all the parameters, to ensure that Specman's memory management system works in an optimal way.

The only parameter that is left for the user to play with is the -optimal_process_size (aka OPS). The importance of this parameter is that many of the other automatically calculated parameters are its derivatives. To set this parameter optimally, one should ask the following question:

WHAT SIZE MEMORY IMAGE DO I WANT MY PROCESS TO HAVE?

Let's say, for instance, that you have 20 GB free on your machine, and you have 2 simulations running in parallel. The optimal process size for each simulation would be 10GB, so you just assign OPS a value of 10GB.

Now, what if you don't know? Or don't care?

Specman then sets this value itself, based on the amount of available RAM on the machine on which the Specman process is to run on. Note - This can be quite a big number. It might make Specman run fast, (hardly perform GCs,) but it consumes lots of memory. The reasoning is that if the user does not care about process size, Specman will use the maximum available memory in order to create a smooth run.

Realistically though, most users do care about their process size and would want to limit it on one hand, while giving it enough liberty to avoid memory issues on the other. So, is there a good way to calculate efficient OPS, one that will ensure that the machine only uses as much resources as needed?

Let's start by saying it is not possible to know exactly how memory settings will affect a program run, if not already measured on EXACTLY the same run. Nevertheless, if we have such knowledge on similar runs, it may give us some hints. We can collect run information and analyze it in a way that can help us understand how efficiently the environment runs and if we need to take some actions to achieve fewer OOM (Out Of Memory) failures, better performance, more effective memory utilization, etc. However, when dealing with batch tests, choosing a specific test "as representative" for purposes of measurement can be as difficult as choosing specific memory settings, so the information must be collected on a representative group of runs, or on all the batch runs.

So what exactly do we need to search for in our log file, in order to calculate the optimal size for our environment? Let's first introduce three concepts:

1) "Static" (Live) Specman heap - this is the basic size of Specman dynamic memory that mostly belongs to persistent objects and generally remains stable during the simulation

2) "Static" non-Specman heap - Same as 1) but for all the rest of the players in the process

3) We would also like to define the memory requirement for the process during copy GC (since whilst Copy GC is operating, we are most likely to hit the peak of the memory consumption, as Specman might double its memory to perform the GC.

(2 X Maximum SN live heap) + (Garbage) + (Maximum non-SN heap)

Collecting the Relevant Data

Now in order to sample these values, we will need to collect the relevant memory and garbage collection related information. To collect this information, we need to set the following configuration parameters in our pilot simulation:

print_process_size=TRUE - Prints the entire process size in three stages for every GC: Before, At peak time, and After
show_mem_raw=TRUE - Prints Specman memory consumption, including top consumers
print_debug_msgs=TRUE - Prints messages, including the exact phases of GC
setenv SPECMAN_MEMORY_ACCOUNTING - Gives us information about Specman's Dynamic allocation.

Finding a value for Specman Live heap

Analyzing the result log, let's estimate the static Specman heap first. There are three printouts that can help us determine this value:

1. Last line in Copy (or disk based) GC printout; which is the new process size "after GC":

"Done - new size is nnn bytes"

For example:

MEMORY_DEBUG: process size after GC:

MEMORY_DEBUG: VSIZE = 1990940, RSS = 1792688

Done - new size is 1804478256 bytes.

2. "Total size of reachable data" line in show mem "Process sizes" table

For example:

Total allocated size of numerics: 12176 +

Total allocated size of structs: 34568K

Total size of reachable data: 1719M +

Total size in free blocks: 343K +

Total size of unreachable data: 375M

Heap size: 2096M

3. Last line in OTF GC printout: "Done - total size of reachable data is nnn..."

For example:

MEMORY_DEBUG: process size at the peak memory usage:

MEMORY_DEBUG: VSIZE = 3653716, RSS = 3514240

Done - total size of reachable data is 1,096,707,344 bytes (plus 2,417,146,640 free).

There will be several instances of those printings (the same number of GCs that you had in the simulation), and we need to choose the highest value that was printed. Printout no. 1 above should be most correct, and we should take the value from it, but the others should also be considered (if show mem is used and OTF GC is encountered).

Finding a value for Static non-SN heap

To estimate static non-SN heap, you need to take VSIZE after copy (or disk based) GC and subtract from it the "Done - new size is nnn bytes" value from the line below it (values obtained from OTF GC prints are not good).

MEMORY_DEBUG: process size after GC:

MEMORY_DEBUG: VSIZE = 1990940, RSS = 1792688

Done - new size is 1804478256 bytes.

In this case: 1990940K - 1804478256.

So the maximum of VSIZE after copy GC, which supposed to be "static SN heap" + "static non-SN heap", is an estimation of what is the minimum requirement for the environment.

Finding a value for Dynamic allocation (Garbage)

There is one more thing to be estimated -- the amount of memory used for dynamic allocations collected during GC. It will depend on the environment and how fast it allocates "transient" objects. If it happens fast, you need to have a large buffer so that GC is not triggered too often; if there are few dynamic allocations, it can be relatively small. In most cases, it's the same order of magnitude as static SN heap.

Example Calculation

Let's look at an example on how you could come up with some numbers for OPS on a typical simulation run.

As per the above example:

"process size after GC" : VSIZE = 1990940 (~1944M)

"Done - new size is" : 1804478256 bytes (~1721M)

Static non-SN heap = 1944 - 1721 = 223M

Live SN heap = 1721M

Recommended Optimal Process Size = (Static non-SN heap) + 2 X (Live SN heap) + Dynamic allocation

*OPS= (Static non-SN heap) + ~3X (Live SN heap)

OPS= (223) + (3 * 1721) = 5386M

*Since we estimated Dynamic allocation to be of the same magnitude as Live SN heap, we used 3 times the value of Live SN heap. In most cases the dynamic allocation value would be lower so we can round down the result we got. For instance, in the above example

OPS = 5386M =~ 5G.

Notes:

The result recommended OPS will not be effective if we notice disk-based GC occurrences in that pilot simulation. In this case we would want to give a higher value than the result OPS we calculated, in order to avoid disk-based GC, and re-calculate the OPS in the same manner, if we were successful avoiding it.
If you know your environment does not use a lot of dynamic allocations (in such cases you will see that the difference between values of Live SN heap before and after GC are small), you can change the above formula to something closer to

OPS= (Static non-SN heap) + 2X (Live SN heap)

And round it up. This way you won't encounter a situation where you have a simulation which consumes a lot of memory, but performs no GCs.

If you try setting the OPS to a very low value, Specman will automatically adjust it. Specman will notify you if it sets the optimal_process_size to a value other that what a user specifies, if you set the -notify_gc_settings option to TRUE. In that case, you will see a message as follows:

auto_gc_settings: Application too big, setting optimal_process_size to

760803328 which is sn_uintptr2ep(760803328)

Summary:

Calculating the optimal OPS is a bit tricky. You want it to limit Specman usage while giving it enough space not to encounter memory issues. The above example calculation gives you no more than a recommendation, which is based on the previous run. To get a better, more realistic value, you should run several pilot simulations, and perform the above analysis on the average of those runs.

* From SPMN 12.10s4 and forward this calculation is done automatically when you apply the config memory -print_process_size

Avi Farjoun

Muffadal Laila

Avoid Overly Long Expressions in Specman e Code

teamspecman — Tue, 11 Dec 2012 14:40:00 GMT

When you write your e code, a good practice is to avoid expressions that are "overly long" even though they are completely legal. While there is no hard definition of what constitutes an overly long expression, such long expressions can lead to human errors and parser processing errors.

Very long expressions are hard to read and understand. This also makes them error prone, as an accidental syntax error in the middle of such an expression is hard to notice.

Furthermore, such an expression can lead to undesirable results from the Specman parser. It can take it long time to parse, and in some cases (especially if you use a 32-bit platform) it can eventually run out of memory resources and crash. This is all the more likely to happen if the expression contains a real syntax error (which in a shorter expression would normally lead to a syntax error message). Thus, by avoiding expressions that are too long, you benefit twice:

1. You better avoid introducing accidental syntax errors in the first place.

2. You help the Specman parser to detect such errors faster in the event that they do occur.

On top of that, it is a good habit to use parentheses in long expressions where appropriate. This not only makes the code more readable, it can actually, in certain cases, make parsing faster.

One last recommendation is to break a long expression into several smaller ones. To illustrate the above recommendations, let's take a look at the following code:

print x == 0 or x == 1 or x == 2 or x == 3 or x == 4 or x == 5 or x == 6 or x == 7 or x == 8 or x == 9 or x == 10 or x == 11 or x == 12 or x == 13 or x == 14 or x == 15 or x == 16 or x == 17 or x == 18 or x == 19 or;

This expression contains a syntax error -- it has an extra "or" at the end. Because the expression is very long, the parser starts to perform a very long calculation, instead of immediately reporting the error. (In this case, the long calculation is avoided when the error is fixed.) Also, the long calculation might eventually lead to a crash.

If you add parentheses as follows, the expression becomes more readable, and you will likely not make the above syntax error in the first place:

print (x == 0) or (x == 1) or (x == 2) or (x == 3) or (x == 4) or (x == 5) or (x == 6) or (x == 7) or (x == 8) or (x == 9) or (x == 10) or (x == 11) or (x == 12) or (x == 13) or (x == 14) or (x == 15) or (x == 16) or (x == 17) or (x == 18) or (x == 19);

You can also break the expression into two smaller ones:

var tmp1 := (x == 0) or (x == 1) or (x == 2) or (x == 3) or (x == 4) or (x == 5) or (x == 6) or (x == 7) or (x == 8) or (x == 9);

var tmp2 := (x == 10) or (x == 11) or (x == 12) or (x == 13) or (x == 14) or (x == 15) or (x == 16) or (x == 17) or (x == 18) or (x == 19);

print tmp1 or tmp2;

In order to improve usability, and ease the pain of this limitation, Specman will automatically issue a warning message, where possible, when parsing an expression actually starts taking too long. This warning will not refer to an exact syntax error, even if there is one; it will, however, refer to the source line in which the problematic expression resides. You will then be able to stop parsing by pressing Control/C, and then examine your code and correct it if needed. This warning will be added in the coming HF releases of Specman, starting from 10.2.

Yuri Tsoglin

e Language team, Specman R&D

UVM e vr_ad -- Specman Read/Write Register Enhancements

teamspecman — Sat, 24 Nov 2012 05:00:00 GMT

If you are a Specman vr_ad user, you probably know that register access is implemented using the read_reg / write_reg. For reading/writing a register, you have to

1. Extend a vr_ad_sequence

2. Add a field of the type of the register you want to access

3. In the body() , call the read/write_reg

For example:

extend MAIN vr_ad_sequence {

!tx_data_reg : VR_AD_TX_DATA vr_ad_reg;

!tx_mode_reg : VR_AD_TX_MODE vr_ad_reg;

body() @driver.clock is only {

read_reg {.driver == reg_driver} tx_data_reg;

read_reg {.driver == reg_driver} tx_mode_reg;

};

For simplifying test writing, starting Specman 12.1 the read/write_reg actions can:

Be called from any TCM, not only from within a sequence
Access not only a local field, but also a variable, or a reference to a field within the e registers model

One of the nice capabilities achieved with these enhancements is that you can embed access to registers among other activities. For example -- in a system level sequence, as in this code example :

extend SEND_AND_CHECK system_seq {

!serial_frame : LEGAL frame;

body() @driver.clock is {

// Perform activity on serial interface, via the i/f driver

do serial_frame on driver.serial_driver;

// Local variable of a register, read it and check the value

var status_reg : STS vr_ad_reg;

read_reg {.driver == driver.reg_driver} status_reg;

check that status_reg.get_cur_value() == 0x37;

// Access registers without defining fields nor variables

write_reg {.driver == driver.reg_driver} driver.reg_model.reg0 val 0x12;

write_reg {.driver == driver.reg_driver} driver.reg_model.reg1 val 0xFA;

write_reg {.driver == driver.reg_driver} driver.reg_model.reg2 val 0x3;

write_reg {.driver == driver.reg_driver} driver.reg_model.reg3 val 0x0;

};

Note that register accesses are handled by the vr_ad_driver. So, when accessing a register from a TCM which is not a vr_ad sequence, you have to specify the vr_ad_driver to handle this operation.

We encourage you to check out the latest UVM e reference manual and user guide for details (both are part of Cadence Help).

Enjoy verification

Efrat Shneydor & Reuven Naveh,

UVM e