• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Verification
  3. Tech Tip - Double Wall Clock Performance with One Easy …
teamspecman
teamspecman

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
Specman
e
Aspect Oriented Programming
Incisive Enterprise Simulator (IES)
IES
AOP

Tech Tip - Double Wall Clock Performance with One Easy Step

6 Feb 2009 • 2 minute read

[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) sn_compile.sh -shlib -exe top.e

2) setenv SPECMAN_DLIB ./libsn_top.so

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

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

Happy compiling!


Silas McDermott
Application Engineer
Cadence USA

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information