Forcing a fixed time in transient simulation

[Anil Joshi]

Is there a way to switch off adaptive time stepping for trans analysis of a purely RLC circuit?

For example, with the following .tran card

.tran 2e-05 0.002

I would like to force 100 time steps of 20 us each for a total simulation time of 2 ms.

Same when CMOS devices are present.

Regards
Anil

[xyce-users]

Xyce uses the "output initial_interval" option to set the output interval.  This won't be the actual time stepping as Xyce will still do adaptive stepping, but it will output on the interval you specify.

For example

.options output initial_interval=20e-6

should force output at only 20us intervals.

You'll want to look up ".options output initial_interval" in the reference guide for more details.

[Anil Joshi]

So there is no way to force a fixed time step. I understand the convergence problems and all that good stuff but there are situations where the user (a sophisticated one at that) wants to force a fixed time step. Doesn't adaptive time step require refactoring the matrix? A fixed time step avoids those issues.

It would be nice if an enlightened user has the option to force a fixed time step. The underlying assumption is that the user knows what they are doing and are able to provide the requisite resources. They also know how to exploit this option judiciously.

Regards
Anil

[Kevin Cameron]

I did some stuff to use PWL sources from a digital simulator a while back -

http://cameron-eda.com/2020/06/03/rolling-your-own-ams-simulator/

Most Analog simulators will take a step on the corner of a PWL waveform input, so using that mechanism with a sawtooth waveform would probably do the trick.

Note: there's a bug in SPICE3 where it just breezes past the PWL points, YMMV.

Really, Xyce should have been built as an Verilog-AMS simulator, but it's something like a PSpice clone (AFAIK), Verilog-A has the function you want -

https://help.simetrix.co.uk/8.0/simetrix/mergedProjects/verilog_a_reference/topics/veriloga_verilog_areference_verilog_afunctions.htm#MiniTOCBookMark3

Regards,

Kev.

--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/a3baccd6-dcb6-4dd2-9b0b-4f51196fae7fn%40googlegroups.com.

[Marcel Hendrix]

> It would be nice if an enlightened user has the option to force a fixed time step.

> The underlying assumption is that the user knows what they are doing and are

> able to provide the requisite resources. They also know how to exploit this

> option judiciously.

A fixed timestep will only work when the waveforms are sufficiently smooth,

and the step is small enough to prevent aliasing. In such a case it is very

probable that setting the *maximum* timestep has exactly the effect you

want. In general a fixed step should be smaller than the smallest

timeconstant/delay in the circuit, leading to enormous output files.

If you want a stepsize that deliberately skips fast events, even when using

non-linear devices, I think it involves having special models with

controllable smoothness and delays (e.g. lookup table based). The DK

method comes to mind.

-marcel

[Francesc Serra-Graells]

Hi all,

Having the possibility of forcing a fixed time step for the outputs is a very interesting feature when you need to calculate PSDs on the resulting waveforms. It is not really easy to interpolate a non-uniform sampled waveform, specially for synchronous systems where outputs are built from bursts of samples around the clock slopes. 

When simulating our high dynamic range Delta-Sigma ADC designs with Cadence Spectre, we ended including a Verilog-A readout block triggered by the system clock, which writes the output waveforms in a file at an exact fixed time step. 

Best regards,

Paco 

El dia diumenge, 31 de juliol de 2022 a les 11:29:53 UTC+2, m...@iae.nl va escriure:

[Murat H Eskiyerli]

I thought Spectre had a switch in transient analysis to calculate the output at regular time intervals. You may want to check the documentation or Ken Kundert's book 

Murat H Eskiyerli

---

From: xyce-...@googlegroups.com <xyce-...@googlegroups.com> on behalf of Francesc Serra-Graells <francesc.se...@gmail.com>
Sent: Sunday, July 31, 2022 3:25:02 PM
To: xyce-users <xyce-...@googlegroups.com>
Subject: [xyce-users] Re: Forcing a fixed time in transient simulation

 

--

You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/768894b1-a6f9-4038-a458-8d014a727da7n%40googlegroups.com.

[Dan FitzPatrick]

Spectre uses a 'strobe' feature on the transient analysis to force solution points, with the objective of minimizing (eliminating) interpolation error in post processing.

For standard direct method spice simulators without this feature, you can kind of mimic this feature, but there are potential issues in how approached.  

   1.  Verilog-A with bound_step - would need to program a module such that the bound_step argument would hit your desired 'strobe' points.  This would

be preferred method, as only the actual simulator time points would be modified (see WARNING in #2 for issues this avoids).

   2.  Use the spice built in sources to force solution points.  The basic idea is to add a 'sidecar' circuit in your simulation to control the simulator time points.

Kevin mentioned PWL sources, but also noted the basic Spice3 simulator may not implement this appropriately.    Another approach would be to just add

a pulse source as your 'sidecar' (below simulates at minimum of every multiple of 1n to 200n - will also include intermediate points):

-------

vstep_ctrl 1 0 PULSE(1, 0, 0, 1n, 1n, 1n, 4n)

rstep_ctrl 1 0 1

*** rest of circuit

.tran 1n 200n

------

  Note:  This will force the simulator to do actual solutions at evern 1n (the PULSE source will force that.  WARNING:  in every simulator that I am aware

of, it also resets the integration algorithm to handle the expected discontinuities that occur at these IDEAL transitions.   Not likely the expected (wanted)

effect.  So, YMMV.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/DU0P251MB0719BB03A5B31EA7EED11D0FF89B9%40DU0P251MB0719.EURP251.PROD.OUTLOOK.COM.

[xyce-users]

Xyce already has the ability to output at specified intervals, and the technique was described in the first Xyce team response --- use ".options output_interval", which is quite flexible  -- for example, you can change the output interval at specified times during a run to, say, sample infrequently when you know the simulation details are of no interest, then switch to smaller intervals during the period of interest.  Without this option, Xyce outputs every time step it takes.  With the option the output is interpolated to the requested time points from the computed signals using an interpolation order that matches the integration order.  One could use PWL sources to force Xyce to take an actual time step at the requested time points, and in conjunction with this output interval option would get output at the chosen points without interpolation artifacts.  But Xyce will still be taking adaptive time steps under the hood to keep the integration error down.

What the original poster was asking for is to change the time integration method so that it does not use adaptive time stepping.  This is very different, and Xyce does not provide an easy mechanism of doing so.

There *is* code in Xyce to make it happen, but it is there for debugging, not for users.  It is not enabled by default as it was found in the early days of Xyce that such a feature being enabled and documented led to (theoretically enlightened) users using it inappropriately and getting bad results, with resulting support requests whose answers were "don't do that."  So we made it an option that is not available in a normal build and removed all documentation of it from our reference guide.  A sophisticated user who wanted to try it out would could look through the code for the "CONSTSTEP" time integration option and work out how to compile it in.  Be prepared to be disappointed, though, because while it is possible to take various shortcuts in solution when the timestep is fixed, this option does not do so (as I said, it is not an option intended for users, it's a debugging tool, and no effort has been expended in optimizing it, and indeed the debugging that it was created for was completed many years ago so nobody uses it, even on the development team -- it might not even work anymore).

[xyce-users]

On Sunday, July 31, 2022 at 9:12:10 AM UTC-6 xyce-users wrote:

Xyce already has the ability to output at specified intervals, and the technique was described in the first Xyce team response --- use ".options output_interval", which is quite flexible  -

Correction:  the original post had it right, and I had it wrong:  ".options output initial_interval=<interval> " is what you use, and it's fully documented in the reference guide.  The rest of my post stands: there is no easy way to force the time integrator not to do adaptive time stepping, and this is intentional.

 

[xyce-users]

I am coming to this discussion late, but wanted to add a few comments/ questions.

I am curious what the use case is for a sophisticated user to request constant time stepping.   Can you elaborate Anil?

I ask because depending on the specific need, there are various other Xyce features you could try.  Some of them have been mentioned in the thread, but some have not.   (more on this below)

As the previous commenter notes, we do have a feature for forcing constant time steps, but it is a debug-only feature.  ie, you have to compile Xyce with the "debug time" enabled to be able to use it.    There was a brief period many years ago when this feature was exposed in all builds of Xyce, but our experience was that a lot of users abused it.  

Also, it should be noted, that ".options timeint conststemp=1" doesn't necessarily do 100% constant steps.  Instead, it applies constant steps between pairs of breakpoints.  So, if your circuit is driven by a PWL source, it will still set breakpoints at each corner of the signal produced by that source.  If using constant time steps, it then uses a time step that will be constant for that segment.  For the next time segment, it will compute a new "constant" step to use.  Of course, if there are no discontinuous sources in the circuit, then it will just use a single constant step for the whole simulation.

As the previous commenter noted, this was only put into the code for debug purposes.  We have not exploited constant time stepping to reuse the LU factors.   There are other use cases in the code where we do reuse LU factors, such as for sensitivity analysis, but this isn't one of them.

The "output interval" option was mentioned earlier in the thread, but here are a few other Xyce time stepping features that might or might not be of interest.  Most of these are set from the ".options TIMEINT" line. 

1. You can manually set a comma-separated list of breakpoints for the time integrator, using ".options timeint breakpoints=1,2,3..."   Breakpoints force the time integrator the stop and restart at specified times.   In practice breakpoints for discontinuous sources (like PULSE and PWL) are generated by Xyce automatically so this isn't necessary.   But if Xyce's automatic breakpointing is somehow missing something this can be an alternative.  I'm not sure if I got the syntax 100% correct, but it is described in the guides.

2.  You can have time windows with differing maximum step sizes.   This is useful if one section of the transient is not resolved enough, but you don't want to impose a tiny maximum time step everywhere.  This is applied on the ".TRAN" line using the "schedule" command.

3.  You can disable the local truncation error (LTE) stepsize control and use the performance of the nonlinear solver to adjust the time step size instead. (this is an idea copied from one of Hspice's options).   This is set by .options TIMEINT erroption=1.  For some transient circuits, which fail with a time-step-too-small error, this can be a way to make them run all the way thru.

4.  If using local truncation error (which is the default), there are several options for the reference value used by the LTE analysis.  These are set via the ".options timeint NEWLTE=n" option.  See the guides for details.

thanks,

Eric

[Anil Joshi]

Hi Eric 

> I am coming to this discussion late, but wanted to add a few comments/ questions.
> I am curious what the use case is for a sophisticated user to request constant time stepping.   Can you elaborate Anil?

Here is the situation. We are developing a solver for RLC circuits. We generate our own RLC circuits - very large circuits 100 million to 1 billion nodes. We are planning to use Xyce as one of the two (the other being ngspice) references to validate our solver(s).

We have three requirements all of which are available only if we build Xyce ourselves.

1. SMP available when built with MPI

2. Fixed time step
3. Access to the flattened circuit (it is available in debug build only, IIRC)

The majorty of the Xyce users do not need any of the above as they are Electrical Engineers who are designing real circuits. I understand you are following the 80-20 or 90-10 rule.

I hope this clears up as to why I am asking for it. It is a very specific case but I am sure would be useful for those researchers/numerical analysts who are developing solvers of their own.

Regards
Anil

--
You received this message because you are subscribed to a topic in the Google Groups "xyce-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xyce-users/E0DlsVM1Qco/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/0f9a571f-38e2-4b0f-982f-a58ccd1548d9n%40googlegroups.com.

[Anil Joshi]

What Paco (Paco, thanks for putting it down succinctly) is saying is the reason why we want a fixed time step. We want to compare apples to apples to start with, i.e. fixed time step comparisons to eliminate any errors in our algorithm so that we can develop our own adaptive algorithm for our job mix characteristics.

For PWL current sources are really not PWL. There are no ideal PWLs in real circuits nor in non-electrical engg. domain problems modeled as electrical circuits.

Anyway, thanks for all the discussions and pointers.

Best regards
Anil

[Anil Joshi]

Unfortunately, we don't have the budget to buy expensive tools like Spectre. It is also closed source, even input/output formats are proprietary.

Best regards
Anil

[xyce-users]

It is sounding like most of the issues in this thread aren't germane to what Anil wants. 

However, having said that, for the benefit of anyone else who might be reading this;

Xyce has the equivalent of Spectre's "strobe" feature.  In Xyce, you can manually specify a comma-separated list of breakpoints on the ".options timeint"  line.    This will force the time integrator to land precisely on these points and restart the integration method.  This is the same mechanism that one gets from a PWL source, but it has the benefit that you don't have to specify a "sidecar" PWL source.

Regarding the bound_step from Verilog-A, isn't that just specifying a maximum time step?   Xyce allows that as well, and you can actually have different max time steps in different phases of the calculation, using the "schedule" command on the .TRAN line.

thanks,

Eric

[xyce-users]

Anil,

thanks for the detailed explanation.  I get it now.  it sounds like most of the suggestions in this thread (other than possibly the debug option CONSTSTEP) aren't relevant to what you need.

Regarding the output of a flattened circuit, we've never implemented this, even in debug builds of Xyce.  There are a few features in the parser that output modified versions of the original netlist to files, but they aren't focused on flattening.    From what I recall, those features preserve the original hierarchy.

For example, you can automatically add resistors to dangling nodes and have Xyce spit out the modified netlist that includes those extra resistors.  Similarly, if using Xyce's MOR/ROM capability, you can have it auto-generate a ROM.

thanks,

Eric

[xyce-users]

I would also like to point out that while the "CONSTSTEP" option was originally put in place as a "debug time" option and that's where it makes sense for it to be, some time ago a developer moved the conditionals as part of a big parameter handling refactor --- and didn't really tell everyone.  Since then, enabling CONSTSTEP requires use of the "--enable-debug_analysis" configuration option instead of the "--enable-debug_time" that was mentioned here.

[Anil Joshi]

Eric

Thanks for the explanation. I saw something in the debug build which says writeOutFlattenedCircuit or something. Or may be it is in ngspice. Let me check. 

Xyce code is very understandable and nice. Thanks for making it available under a generous license.

Thanks and regards
Anil

[Anil Joshi]

Regarding the flattened circuits, it would be nice if there is a standard for spice netlists. Writing a parser for spice is quite challenging as there is no definition of the language. I was hoping that I can use Xyce for parsing freeform netlists with all the ugliness of options, macro expansions, parameters to subcircuits, and a few other things which were probably added to spice as they went along. Ngspice as well Xyce both parse our netlists correctly. The parsing step in Ngspice is slower than parsing step of Xyce. Overall Xyce runs about 4 times faster than Ngspice on a few large problems (~10 million variable) we have tested.

On the other hand, Ngspice gives access to the flattened Netlist.

Thanks and regards
Anil

On Wednesday, August 3, 2022 at 2:00:39 PM UTC-5 xyce-users wrote:

[xyce-users]

Anil,

thanks for the information. I'm glad to hear that the code is understandable to you.  That is of course our goal, but I'm sure we don't always achieve it.  :)

Regarding flattened netlists, there is a function in the IO package called "produceUnflattenedNetlist".  So, possibly you saw that function, but didn't notice the "Un".    I think that function is the one that is used when we output a modified netlist, e.g. when we add grounded resistors to dangling nodes.  For that use case (which performs this very early in parsing) it was easiest to keep the netlist as close to the original as possible.

When you run the ~10M problem, I'm curious if (1) you are running in parallel and (2) which linear solvers you've tried.   That is beginning to get large enough that iterative solvers may be a better choice.  Also, in parallel, for a problem that big it will automatically choose an iterative solver, but with the "least fancy" preconditioner.   In serial, it will automatically choose the direct solver (KLU) regardless of problem size.

thanks,

Eric

[Anil Joshi]

Eric,

Yes. Probably that is what I saw and got excited.

For the ~10 M problem, we were running the Xyce binary for Linux. (RPM? I forget. Default solver, KLU. Overall Xyce is 4x faster than Ngspice in elapsed time. These are very sparse matrices. To run the large problems, we need to use MPI Xyce. Our sysadmin is working on building it.

Regards
Anil

[Kevin Cameron]

Verilog-AMS is the standard to use. Unfortunately, folks in industry have not insisted on vendors using it, so support is patchy, a proper open-source implementation would help a lot.

I did a whole parser years ago - https://github.com/kev-cam/v2k-top - but there isn't a proper compiler yet, ADMS covers a subset of it.

Kev.

You received this message because you are subscribed to the Google Groups "xyce-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/3d1cba90-0528-4d90-ad46-7db8c325c084n%40googlegroups.com.

[Anil Joshi]

Thanks for the pointer. We are facing the exact problem. Vendors have their Spice implementations with twists/quirks. It is very different in Mechanical CAD and CAE industry. Ansys Problem Description Language, Nastran, and Simulia languages are all reasonably well designed. Manuals are also available. Plugins are easy to implement.

Regards
Anil

[Kevin Cameron]

Languages aren't patentable, so the community could just pick a favorite and then build in the support.

Verilog-AMS is quite old now, and there are other efforts in SystemVerilog(-AMS) going on, however most of the System* stuff is a mess.

We could do our own version of SystemVerilog-AMS in the open-source community, I'd cut it down to stuff you can't just do in C++, and do the modeling with a plug-in approach. If you just view compiled modules as things that attach to wires, it's not that hard, SV & VHDL got bogged down with wires having types, rather than just disciplines.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/cc51259a-1079-4c55-bc3f-98942d572651n%40googlegroups.com.