will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST). login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Functional Verification > tech tip double wall clock performance with one easy step
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Tech Tip - Double Wall Clock Performance with One Easy Step

Comments(2)Filed under: IES, Incisive Enterprise Simulator (IES), e, Specman, Aspect Oriented Programming, AOP

[Please welcome guest blogger Silas McDermott, an Application Engineer in our Field Organization]

There is one very easy step that Specman users can take to roughly double the wall clock, run time performance of their testbench.  In a word, "compile"!

That's right: by simply compiling their e testbench, we've seen customers enjoy substantial performance increases, often up to 2x faster than uncompiled runs (i.e. up to 1/2 the uncompiled wall clock run time).  The reason behind this increase is the simple physics of running code through Specman's interpreter, where additional time is needed to parse the code on-the-fly before the simulation phase can start.  With pre-compiled code, Specman does a quick read of the compiled library and launches into the simulation.

Of course, as the saying goes, "your mileage may vary", and you might not see a 2x improvement.  But unless you have written total spaghetti code you WILL see some performance improvement for very little effort; so as the marketing folks say, the return on investment is very high.

So if the performance gain from compilation is so dramatic, why doesn't everyone compile their code? To answer this question, consider the following:

Thanks to clever leveraging of e's Aspect Oriented Programming architecture, Specman can run any mix of compiled and interpreted code.  This a great thing to support verification work, since in verification you are always adding new tests on top of a base layer of testbench code, and this simultaneous support of both modes give users the best of both worlds (i.e. you get the speed of compiled code with the flexibility tossing new logs on the fire via interpreted mode).  Of course, once new tests are themselves matured and considered to be part of the standard regression suite, it makes sense to do a full recompile on everything to get the performance benefit.  Naturally, this convenience vs. performance "re-compile all" tipping point is different for every testbench.

Finally, since interpreted mode works very smoothly, it's not unusual for new Specman users to incorrectly assume that their code is being compiled vs. interpreted every time (especially if the testbench is relatively small).  To be sure you are compiling your code, you can simply execute the following two commands:

1) -shlib -exe top.e

2) setenv SPECMAN_DLIB ./

The first command creates a shared library "" and the simulator then uses the SPECMAN_DLIB environment variable to find the shared library.

For more information, please see in the Specman Command Reference.

Happy compiling!

Silas McDermott
Application Engineer
Cadence USA


By Srinivasan Venkataramanan on February 10, 2009
Thanks for this very useful tip.  FYI:      I couldn't agree more with that post - it is really beneficial to explore what can be pushed to compiled code. Some more data from my own experience during my Intel days:
1. We got 3 to 4x gain in compiled mode, though it is 5+ year old data.
2. There are (were?) some restrictions with the usage of computed macros across such compiled SO files/partitions. Not sure if they are still around. I don't recall all the details on top of my head, though if someone is interested I can try and recollect.
3. A very *important* aspect is the debuggability of compiled code. Line stepping feature gets disabled for compiled portions, so if you need to debug with line step go back to loaded mode.
4. Note that "function" level breakpoint is still possible with compiled mode.
5. If there is a null obj access, compiled mode won't reveal much details, while interpreted/loaded mode will point to exact issue. We have used this facility so often that we infact automated this process via script - i.e. if there is a null obj access, a separate process shall spawn off with same test/seed but in loaded mode. This was part of our automation we presented in DesignCon  though this specific tip/trick was left undocumented there.
6. Lastly, we did see few corener case scenarios wherein the random generation was different in both modes, Verisity knew about it back then (around 2003?) and said they will fix it sometime in future. Not sure if that still is an issue. Note that it was not easy to reproduce and was truly corner case, so don't ask me for "testcase" now :-)
Srini, CVC

By teamspecman on February 18, 2009
Srinivasan, it's good to hear from you again,and thanks for the many detailed comments!  You have made so many great points that rather than try to squeeze in quick response here, you inspired us to write a whole new posting to address & respond to your notes.  Stay tuned ...

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.