Stats

  • Locked Locked
  • Replies 8
  • Subscribers 125
  • Views 19453
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Spectre: How to get rid of spectre.ic and spectre.fc?

dontpanic

Hi! I am running batch simulations over a large extracted design, so I need to trim down the size of the results directories to the bare minimum. The spectre.ic and spectre.fc occupy almost 50MB each, so I want to avoid generating them, but I haven't been able to figure out how...

-In my transient sim setup, tab "State file" I removed the text "spectre.ic"  and "spectre.fc" in the fields "write" and "writefinal", respectively, but the simulator seems to ignore this.

-In the "enviroment" options I have checked "Save state (ss)" and "Recover (rec)" to "n", but this also doesn't seem to have any effect.

Any ideas on how to achieve this? I'm using spectre version 15.1.0.679.isr14 64bit.

Thanks and regards,

Jorge.

P.S. I also noticed that even though I made sure to have no outputs selected for saving/plotting, and my "save all" setup is as in shown below, a "tran.tran.tran.dat" is still generated in the results directory. When I check its contents with the Results Browser tool, I see that one voltage node of my circuit is still being saved. Is this a bug, or spectre must by all means save at least one circuit node?

Parents
  • dontpanic

    Well, normally I define the corners as parameter sweeps, the tests as testbenches grabbing different config views (e.g. schematic, pex CCc, pex RCc, etc) and the interactive runs I mainly use for (in actual order in my design flow): (1) normal iterations over the design, (2) incremental simulation time / accuracy / number of corners simulated (i.e. I'll ran first few corners over smaller FFTs and relaxed maxstep and if results look ok then re-run more corners with larger FFTs and higher accuracy), and finally (3) simulations with transient noise. So after all these I easily end up with tens of interactive runs (and I do keep the history of the simulations for reporting/comparison purposes). So, within this usage context, it's common for me to receive disk quota warnings when dealing with large PEX netlists :\

    The saving to one level higher approach does work for the wave dumping issue, but I remembered my postprocessing scripts also read other results files (mainly spectre.out and designParamVals.info) from the results directory, and what's worse, I noticed I also read the .modelFiles FROM THE netlist DIRECTORY for getting the device model used in the runs! Thus I see that I do rely on the netlist directory to exist! So really the only option for me is to find an automated way to delete just the actual netlist file.

    For the time being the one-netlist-per-run solution is good enough, though. I cannot change my postprocess flow right now, but I'll see if I can come up with a clean solution after my tapeout. Will definitely get back to this thread by then! :D

    As usual, thanks so much for your help, Andrew!

    Cheers,
    Jorge.

Reply
  • dontpanic

    Well, normally I define the corners as parameter sweeps, the tests as testbenches grabbing different config views (e.g. schematic, pex CCc, pex RCc, etc) and the interactive runs I mainly use for (in actual order in my design flow): (1) normal iterations over the design, (2) incremental simulation time / accuracy / number of corners simulated (i.e. I'll ran first few corners over smaller FFTs and relaxed maxstep and if results look ok then re-run more corners with larger FFTs and higher accuracy), and finally (3) simulations with transient noise. So after all these I easily end up with tens of interactive runs (and I do keep the history of the simulations for reporting/comparison purposes). So, within this usage context, it's common for me to receive disk quota warnings when dealing with large PEX netlists :\

    The saving to one level higher approach does work for the wave dumping issue, but I remembered my postprocessing scripts also read other results files (mainly spectre.out and designParamVals.info) from the results directory, and what's worse, I noticed I also read the .modelFiles FROM THE netlist DIRECTORY for getting the device model used in the runs! Thus I see that I do rely on the netlist directory to exist! So really the only option for me is to find an automated way to delete just the actual netlist file.

    For the time being the one-netlist-per-run solution is good enough, though. I cannot change my postprocess flow right now, but I'll see if I can come up with a clean solution after my tapeout. Will definitely get back to this thread by then! :D

    As usual, thanks so much for your help, Andrew!

    Cheers,
    Jorge.

Children
No Data

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.