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

Jorge,

I don't see how the simulator can ignore this - if you don't' specify what file to write these to, it doesn't write them. Double check the tran statement in the netlist - if they're really not there, they shouldn't get written. I assume you're not just seeing the files from a previous run of spectre in the same netlist directory? (check the dates, or try deleting them before simulation).

I can't see what you had on the form because it's missing in  your post, but if you do pick "save=none" then it will indeed save a single signal. That's because the output is initialised, and so it has to save something in the file so that the results data is not invalid. If you really don't want to save anything, then leave all of the choices for "save" blank on the Outputs->Save All form (i.e. nothing checked) and then go to the Simulation->Options->Analog form, go to the Miscellaneous tab, and then at the bottom in the Additional arguments field, enter "save=nooutput". That will stop it writing anything from any analysis.

Not sure if that's what you want though, because presumably you want some output from the simulator because otherwise it's a  bit of a waste of time simulating it! Perhaps you're saving data via Verilog-A?

Regards,

Andrew.

Jorge,

You can control this via Options->Save in ADE XL. This controls whether it deletes the raw simulation data and/or the netlists after each point run is completed.

You can also cut down the numbers of copies of the netlist (and the size of the input.scs) by setting these two env vars in your .cdsinit:

envSetVal("adexl.simulation" "singleNetlistForAllPoints" 'boolean t)
envSetVal("adexl.simulation" "includeStatementForNetlistInSimInputFile" 'boolean t)

Regards,

Andrew.

Jorge,

I don't understand. There would only be one netlist directory for each test, regardless of how many points you ran in the verification. So why would it be gigabytes of data? You already turned off the simulation output (not sure how you're actually getting any output from the simulator - presumably you have to output something somewhere otherwise there's no point in running the simulation). If  you want to cut it down altogether, you can check the "Save Simulation Data" too which will delete the contents of the psf dir and then not save a shared netlist either. This doesn't  delete any measurement outputs which have resulted in a scalar value in the ADE XL outputs table, but those would have been dependent on having some psf results before the data got deleted (which doesn't match with your intent to use save=nooutput earlier).

Trying to write post-simulation triggers shouldn't be necessary here - mainly because I just don't understand why the built-in capability doesn't do what you want.

Regards,

Andrew.

Oh, the problem is that the reference netlist directory is generated on a per-run basis, instead of a per-test basis. From the experiments I've quickly ran I see that unchecking "Save Netlists" in Options->Save keeps the following shared netlist directory:

[results_dir]/[libname]/[cellname]/[adexl view name]/results/data/[run name. e.g. "Interactive.XYW"]/psf/[test name]/netlist

This folder is still created for every run, even after unchecking "Save Simulation Data". I also can't use this latter option altogether because I rely on separate results directories for each point to dump the actual outputs of interest to disk by means of a verilog-A module in my testbench, which I later postprocess in Matlab (I forgot to mention all this, sorry about that!); unfortunately unchecking that option breaks this functionality, so the post-simulation trigger seemes to me the easiest workaround to try...

Cheers,
Jorge.

Jorge,

However, if you're doing sweeps and corners (which I assumed you were), turning off the Save Netlists checkbox means that rather than having a full netlist directory per sweep point and corner (i.e. under the 1, 2, 3 directories within the Interactive.XX), you only have one.

Are you running lots of separate "Interactive" runs? If so, why?

In general this netlist directory has to be partially kept because of the need for the mapping data in the directory - otherwise plotting wouldn't work. In this case you don't care about that, but that's why in general there's no mechanism to completely remove the netlist dir unless you're not keeping the simulation directory.

I wonder whether a simpler solution might not be to get your veriloga to write the file to one level higher (i.e. add "../" to the beginning of the path) and then delete the simulation data and netlist? I've not tested this...

Andrew.

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.