#105 Esave + rawfile

[Bohdan Tkhir]

Hello!

According to the manual, esave cannot be used in batch mode to write event results to a rawfile, only .save can be used to save analog nodes.
Wouldn’t it be a useful feature for simulating large mixed-signal circuits?
At the moment, if I need to capture, for example, event-driven 50 MHz oscillator data, I have to keep all the data in RAM.
Being able to stream the results directly to a .raw file would be a very nice feature to have.

Thank you!

[Giles Atkinson]

A simple work=round is to add a resistor to ground from each digital node that you want to save. That has the effect of creating an analogue node with the same name and (almost) the same value. Define ".param vcc=1" if you want 0/1 values rather than the default 0/3.3.

[Bohdan Tkhir]

As I understand it, this would add an auto-bridge.
If that is the case, the digital nodes would still be saved and would continue to consume a large amount of RAM.
This would work well if it could be used together with esave none, but then we end up back at the same issue :(

[Giles Atkinson]

Why would esave=none not work? The digital value memory is discarded at the end of every timestep and at the same time the analogue nodes are wriiten to the raw file.

[Bohdan Tkhir]

Adding the resistors to hi-freq node slows down the simulation and it just stucks.

Why would esave=none not work ?

Chapter 11 says:

The command lines described in this chapter are used to specify analyses and outputs within the circuit description file. They start with a ‘.’ (dot commands). Specifying analyses and plots (or tables) in the input file with dot commands is used with batch runs. Batch mode is entered when either the -b option is given upon starting ngspice
ngspice -b -r rawfile.raw circuitfile.cir

And esave in not a dot-command, so can not be used in batch mode, where raw file is used.

Correct me if I'm wrong.

[Giles Atkinson]

No, that is more or less correct. Control sections do work in batch mode, but the results of any simulations they do are not written to the raw file. And simulations specified by dot-commands run before the control section. Early execution with "pre-esave" will fail: no circuit is loaded at that point. I think the right thing is for batch mode to force an implicit "esave none".

My guess is that the slow-down is pretty much inevitable as monitoring the digital nodes will shorten the timestep.

Edit: extra timesteps are inevitable with this approach, but there might be mitigations. Currently, the DAC bridge tries hard to force fast digital edges into the analogue engine, adding a breakpoint at both corners. Then the transient algorithm takes extra steps accelerating away from the very short delta: reasonable behaviour if the original cause was difficult convergence.

All that is pointless if the analogue node is a dummy. It should be easy to add an option to the bridge to request only the second breakpoint. More speculatively, it may be possible to add a "pedal-to-the-metal" flag to the breakpoint request.

An example circuit where this would be useful may make implementation more likely.

[Holger Vogt]

We might think of an extension to ngsppice writing a VCD file with digital signals on the fly during a batch simulation, and then not storing anything in memory, similarly to our writing the raw file during the batch simulation.

I am not sure how then to evaluate this file. ngspice does not have the capability to read a vcd file, or how to synchronise analogue and digital data in a common tool for visualisation etc. Maybe such a tool does exist already?.

[Giles Atkinson]

Writing a VCD file would have the benefit of keeping the separation between digital and analogue. It might reuse existing support for digital nodes in iplot. Integrated XSPICE output into the raw file would involve stirring up code that has probably been stable for decades: I do not want to go there!

There is a program called vcdmaker that probably could be taught to convert rawfiles to VCD, perhaps with some scripting support. Its documentation says it can merge VCD files, so unified output should be possible. Unfortunately, gtkwave's support for viewing analogue data seems weak.

A VCD filesource in ngspice would certainly be helpful. I did spend some time looking for a re-usable VCD parser in existing open=source code without success.

[Holger Vogt]

This one looks promising:
https://xschem.sourceforge.io/stefan/xschem_man/graphs.html

I will have to talk to Stefan and ask him, if his XSCHEM might be enabled to read VCD files and ngspice rawfiles (which it probably already does) and to combine them.

[Giles Atkinson]

This looks readily adaptable as a parser. MIT license and only about 200 lines of straightforward C. I found it linked from the VCD page on Wikipedia.

[Holger Vogt]

So a VCD file source comes closer.

Next then a VCD write during batch sim, without filling the internal memory.

Giles, will you take this? Or shall we ask Brian, who has cated for digital and code models as well?

[Giles Atkinson]

I am happy take it, as I always thought there was a case for the filesource. And the VCD write may re-use code that I already learned in evtprint.c. It may not be so simple, as handling failed timesteps means either rolling back output or sorting events when a timestep is accepted.