Extending a tran sim?

First of all, using writefinal followed by readns is a bad way of doing this, because it doesn't completely capture the state (even if you use skipdc=yes in the second simulation). More on that in a moment.

The default setup for a transient analysis in ADE will set writefinal=spectre.fc on the State File tab of the transient options. The file is written into the netlist directory (which is the working directory when the simulator is launched). This is still the case and nothing has changed. You can of course change the file name to something else, and it will have an effect. My guess is that you're looking at the spectre.fc file in the wrong location.

The correct way of doing this is to use the Save/Restart parameters on the same State File tab. You can choose a file name, and either specify a specific time (or set of times), or have it saved automatically periodically in simulation time (saveperiod) or on wall clock time, i.e real time, using saveclock. See "spectre -h tran" for more details. You then can use the recover field to recover from a previous state file; it will automatically restart at the time the file was saved at, and it stores the full state (including internals of various models and so on) and shouldn't suffer from discontinuities, nor need you to mess with skipping the DC operating point as you have to do with writefinal/readns (or readic).

Andrew

Dear kenc184,

Andrew's comments are absolutely correct - but that is nothing unexpected! 

If it is helpful at all, I assembled a set of specific instructions with examples of using the various options this issue has been raised a number of times and appears to be a source of confusion. If you are invested kenc184, I've placed the note is at URL:

www.dropbox.com/.../save_state_spectre_tran_sim_directions_results_sml_generic_091021v1p0.pdf

Good luck and I hope between Andrew's response and this note you are able to successfully able to restart your simulation!

Shawn

Dear kenc184,

(I am re-posting as my prior post was not proof read and incomplete when it was posted - sorry!)

Andrew's comments are absolutely correct - but that is nothing unexpected!

If it is helpful at all, I assembled a set of specific instructions with examples of using the various options as this issue has been raised a number of times. Further the terms used appear to be a source of confusion. If you are invested kenc184, I've placed the note at URL:

www.dropbox.com/.../save_state_spectre_tran_sim_directions_results_sml_generic_091021v1p0.pdf

I will also add that there is an example of the error that can be present when one uses the final transient operating point to restart the simulation in lieu of saving the circuit state. To save you or anyone with an interest some time, I've included Figure 14 from the note below.

Good luck and I hope between Andrew's response and this note you are able to successfully able to restart your simulation!

Shawn

Dear kenc184,

(I am re-posting as my prior post was not proof read and incomplete when it was posted - sorry!)

Andrew's comments are absolutely correct - but that is nothing unexpected!

If it is helpful at all, I assembled a set of specific instructions with examples of using the various options as this issue has been raised a number of times. Further the terms used appear to be a source of confusion. If you are invested kenc184, I've placed the note at URL:

www.dropbox.com/.../save_state_spectre_tran_sim_directions_results_sml_generic_091021v1p0.pdf

I will also add that there is an example of the error that can be present when one uses the final transient operating point to restart the simulation in lieu of saving the circuit state. To save you or anyone with an interest some time, I've included Figure 14 from the note below.

Good luck and I hope between Andrew's response and this note you are able to successfully able to restart your simulation!

Shawn

Shawn,

First of all, thanks for posting your document - always good to have real life guides from somebody other than me! I'm also going to caveat what I'm saying here by reiterating that the writefinal/readns/readic approach is the wrong way to do this (as I said before). Now...

I'm pretty certain that this simple circuit would have worked OK if you'd used readic="spectre.fc", skipdc=yes, start=500n on the transient. There's nothing in the circuit (I think) that would require additional state information (usually this is things like delays, nport, verilog-a models with internal state and so on). I didn't try to reproduce it, so I may be wrong. However, my point is that even if it can be made to work, it's very easy to get wrong and also not be aware of the fact that not everything is saved. For example, here you really need to use skipdc=yes and readic and also make sure that the start time is later so that the PWL source doesn't fire again.

So the summary (from both of us) is to use the save/recover mechanism because that's much more robust and easier to use...

Andrew

Thank you both, and sorry for the delay in responding, for some reason I do not get informed of replies even though I have that field checked.

Shawn, I've downloaded your file for later perusal, thanks for all of  that effort!

IT is curious that the writefinal file is written into the netlist directory, yet clicking on the 3 dots at the end of the "writefinal" field takes you to the home directory.

Dear Andrew and kenc184,

First, thank you very much Andrew for even taking the time to review my post! I will never understand how you manage to fit "all of us" into your schedule!!

Andrew Beckett said:

I'm pretty certain that this simple circuit would have worked OK if you'd used readic="spectre.fc", skipdc=yes, start=500n on the transient. There's nothing in the circuit (I think) that would require additional state information (usually this is things like delays, nport, verilog-a models with internal state and so on).

You are absolutely correct - although I don't think you need to force the simulator to skip the DC operating point as it will choose the operating point from the spectre.fc file. I purposefully chose a test circuit that included an inductor current - whose value is a state variable. If one does not specifically save all the state variables at the last simulation point of one's initial simulation and set the state variables in the subsequent simulation to that value, the resulting re-started simulation will not produce the response of the simulation after the time point at which it was restarted.

In this example, the spectre.fc file that is saved and then invoked in the re-started simulation includes the inductor current. The file spectre.fc (and yes, kenc184, in the netlist directory - not the psf directory) is the following:

# CHECKPOINT_VERSION 1
# Generated by spectre (mode: APS) from circuit file `input.scs' during analysis tran.
# 1:38:26 PM, Fri Jul 29, 2022
# Number of equations = 10
# The default unit is V, otherwise its unit is after #unit
L0:1 0.000109665013850077 #unit A
n0 1
n1 0.994516537566612
n1checksim 0
n2 0.989033286874109
V0:p -0.000109669248667752 #unit A
V1:p 2.56894517538055e-21 #unit A
vout 1.07372976522574
vssa 0

Therefore, the re-started simulation does produce the expected response after the stop point of the prior simulation. I verified this in a few simulations and show the result in Figure 1. Although I do not include it below, I did also verify that without checking the "yes' radio button for skips, the results are the same.

Figure 1

kenc184 said:

Shawn, I've downloaded your file for later perusal, thanks for all of  that effort!

You are more than welcome! I just hopes it helps provide some insight if you have time and interest to peruse it.

Good luck!

Shawn

Dar Andrew and kenc184,

Spell checker caught me...and I missed that it changed my text - rats!

Unknown said:

Although I do not include it below, I did also verify that without checking the "yes' radio button for skips, the results are the same.

The sentence should read:

"Although I do not include it below, I did also verify that without checking the "yes' radio button for skipdc, the results are the same."

I finally got around to trying this, and met with problems.

I don't like the fact that the saved file is 20 layers deep in the hierarchy, and that the three "dots" to the right of "savefile" and "recover" on the state file form simply leave you at the home directory. Not very useful.

After copying and pasting the directory name from the netlist header, I found my saved file at

/home/kenc/simulation/Defib/crystal_osc_test/maestro/results/maestro/ExplorerRun.0/1/VVIR_gen1_crystal_osc_test_1/netlist/xtal_save_at_1.00ms

After entering this entire path in recover - and yes, I did remember to check the two environment boxes from your pdf description. - the simulation crashed with a segmentation fault and the xtal_save_at_1.00ms file simply vanished.

Not sure what I'm doing wrong.....but that's true to form.

I'm not sure why the simulator crashed (you should contact customer support about that), but there are a couple of points I'd like to make:

1. The "..." button should open in your working directory - it can't open in the simulation results directory because it
   1. can't do that if you've not run a simulation
   2. it wouldn't know which simulation results directory to open in anyway
   3. you might want to save the file anywhere in your system - the working directory is as good as anywhere to start from
2. Doing this with Explorer is likely to be challenging unless you do Results→Save because otherwise the ExplorerRun.0 data is going to get overwritten in the subsequent run. So you might want to save the results and then point at the previously saved file.

Andrew