Home > Community > Blogs > Functional Verification > using the restore append logs feature
 
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 Cadence 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: *

Using the ‘restore -append_logs' Feature

Comments(0)Filed under: Functional Verification, Specman, specman elite, debug, simulation, e language, AF, SAO, restore, dynamic load, log files, restore-append_logs, reseeding, restore append

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

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.