Get email delivery of the Cadence blog featured here
[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.
Silas McDermottApplication EngineerCadence USA
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 ...
Thanks for this very useful tip. FYI: vlsi-verif.blogspot.com/.../specmans-compiled-vs-interprted-mode.html 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 www.iec.org/.../3-wp1.pdf 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 :-)