Home > Community > Blogs > Functional Verification > tech tip easy way to re run using the same seed
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

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

Email

* 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: Easy Way To Re-Run Using The Same Seed

Comments(0)Filed under: Specman, IES-XL, Funcional Verification

[Team Specman welcomes back Application Engineer Hilmar Van Der Kooij as this week’s guest blogger]

Often we want to re-run a simulation with the exact same random seed that was used in the previous one.  Unfortunately far too many people (ok, maybe just me) have used little scraps of paper or sticky notes with random numbers on their desk to carry forward this information.  However, thanks to a tip from some colleagues, I’ve just discovered there is an easy way to reload your environment in Specman while retaining the same seed.  It only takes a little bit of code, and it can be done right from the Specman or Incisive Enterprise Simulator-XL (IES-XL) console.

To do this from inside the IES-XL console, use this code:

sn simulator_command(append(\"set curSnSeed ",covers.get_seed()))
reset
sn reload
sn test –seed=$curSnSeed


Of course you can add this code to a command script, and even create your own button for this in SimVision.

If you are using stand-alone Specman with a 3rd party simulator, use this code:

 

simulator_command(append("set curSnSeed ",covers.get_seed()))
simulator_command("reset")
reload
simulator_command("sn test –seed=$curSnSeed")

 
This bit of code stores the seed in a TCL variable in the simulator, reloads the environment in Specman (which does an implicit restore, therefore removing all history of existing seeds) and gives a test command to Specman using the stored seed. The latter is done through the simulator interface, to easily retrieve the saved seed.  Of course you can put this in an .ecom file to make (re-)execution of this a breeze.

WARNING: don’t forget to "turn this off" when you are done debugging.  This tech tip came with cautionary tale from a customer on the East Coast of the USA that forgot to switch back to random seeding after they were done debugging; where, long story short, the lack of randomness masked a bug that crept back into the DUT and “escaped” into production.  (Thus proving the hard way that e/Specman’s “infinity minus” philosophy of constrained random generation is truly the safest approach.)

Finally, I’d like to thank my colleagues Patrick Oury and Nils Luetke-Steinhorst for their contributions.

Happy coding!

Hilmar van der Kooij


Short bio on this guest blogger:
Hilmar van der Kooij is a Cadence Application Engineer for our Metric Driven Verification solutions, based in sunny California. He has expertise in applying Metric Driven Verification both in simulation as well as formal analysis. Besides living the jet-set Verification lifestyle, he enjoys playing around with old-fashioned film cameras.

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 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.