Hello!
Is it possible to make an ideal comparator, that can generate events for time step controlling algorithm?
B-sources obviously won't work without step-size limit, what are the another options?
I thought about voltage-controlled switches, but not sure if they actually generate events...
Thank you in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, yes I know, but the issue is that i need element that can be distributed separately from ngspice, but currently custom XSPICE model could be used only after recompiling together with ngspice :(
As far as I know, we cannot use xspice models as shared library
Last edit: George 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If your comparisons are of things that have pulsed / pwl
source precursors then maybe this happens for free
already?
Or, maybe place a busy pulsed source that happens to
put timepoints where they do some good (not a whole
prop delay too early, or whatever the solution challenge
wants).
But something that catches "hurt fixin' to happen" by
observation of circuit activity, rather than netlist parsing,
sure sounds helpful.
Last edit: dick freebird 2024-05-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I know, we cannot use xspice models as shared library
?? Please elaborate. Maybe you mean that a *.cm can't be used outside of ngspice? The solution to that is to write an XSPICE model that uses sockets or shared memory as its input and output port.
-marcel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I meant that I have to recompile ngspice together with xspice model, there is no way to independently compile only xspice model. This is opposite to the approach that used with verilog-a osdi modules, you can compile them out of source.
Last edit: George 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I meant that I have to recompile ngspice together with xspice model, there is
no way to independently compile only xspice model.
Well, the *intention* of code models (*.cm) is definitely to make them independent of compiling ngspice. (That's one reason why you need to load them with codemodel (17.5.12)). It may take some make-file-magic to disentangle it from the current generation process -- I only ever tried the reverse (compiling XSPICE models as native ones).
-marcel
Last edit: marcel hendrix 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The adc_bridge XSPICE element with differential input makes an ideal comparator if both thresholds are set to zero. Output is digital, so an "event", if that is what is wanted. (The problem posed in the original post is not easy to interpret!) If the output is fed to a dac_bridge to return to the analogue domain, a transient simulation breakpoint is inserted at transitions. And then the output might drive a somewhat realistic output stage; open drain ...
The XSPICE discussion is interesting to me. Yes, you could build an XSPICE model independently, but in practice everything is tightly bound to the ngspice build system. Mostly by cmpp, but you must also use the header files of the XSPICE binary that will run. The d_cosim and d_process code models provide some distance. I have been developing some d_cosim clients entirely outside ngspice, except for the cmtypes.h file to define Digital_t. Both are digital-only, but adding analogue nodes seems straightforward. And with d_process, anything is possible. Your model may be a shell script or ...
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My limited understanding is that the sources'
"event flagging" happens at netlisting where the
timepoints are harvested. Not a "real time, as it
goes" type surveillance.
So I am not too optimistic that other SPICE elements
can do this.
XSPICE is a "personal growth area" not yet taken up.
But I wonder about the veriloga option, "events"
seem to be created there. Whether these pass to
the ngspice engine, presently or possibly, no clue.
But there's "event-y" stuff that transitions the outputs
at finite slew at edges, etc. that maybe "could".
Wonder if there's a pipe for that.
Secondary notion - if the "breakpoints" are a managed list,
could that list evolve "real time", "just in time" to take in
"discovered events"? Maybe with enough of a "smart
step-back" to then apply that logic (whatever) to timestep
control, without having first to fail convergence (in my
gut understanding, this has some probability of getting
out over its skis before it notices, and maybe this "be
ready to step back, on warning" would help some of that
(if precursors to failure are recognized, along with
"something's coming" from veriloga modules and such)?
And, could a "code model" be educated how to jam a
warning to that list too? Presuming it works anything like
imagined?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure that I understood everything there, but I think you described how things work now, and for many years. The transient analysis code maintains a list of breakpoints (times when a step will be forced to end) and circuit elements may add to it as simulation proceeds. Grepping the code shows that 8 XSPICE elements currently do that (including dac_bridge and bidi_bridge), also the independent sources (PULSE and PWL) and one of the transmission lines. I did not find it in the OSDI sub-system, but I am unfamiliar with that.
But this technique is not applied everywhere that may be useful. It seems to me that such code might be added to all PWL sources and switches, leading to improved convergence. And one that may be tricky to implement: a breakpoint might be inserted whenever the controlling term of a "?" operator in the expression for a controlled source changes value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
Is it possible to make an ideal comparator, that can generate events for time step controlling algorithm?
B-sources obviously won't work without step-size limit, what are the another options?
I thought about voltage-controlled switches, but not sure if they actually generate events...
Thank you in advance
Such features are available in the XSPICE api. Maybe have a look at cm_event_queue() and
cm_analog_set_temp_breakpoint()?
-marcel
Hello, yes I know, but the issue is that i need element that can be distributed separately from ngspice, but currently custom XSPICE model could be used only after recompiling together with ngspice :(
As far as I know, we cannot use xspice models as shared library
Last edit: George 2024-05-20
If your comparisons are of things that have pulsed / pwl
source precursors then maybe this happens for free
already?
Or, maybe place a busy pulsed source that happens to
put timepoints where they do some good (not a whole
prop delay too early, or whatever the solution challenge
wants).
But something that catches "hurt fixin' to happen" by
observation of circuit activity, rather than netlist parsing,
sure sounds helpful.
Last edit: dick freebird 2024-05-21
?? Please elaborate. Maybe you mean that a *.cm can't be used outside of ngspice? The solution to that is to write an XSPICE model that uses sockets or shared memory as its input and output port.
-marcel
I meant that I have to recompile ngspice together with xspice model, there is no way to independently compile only xspice model. This is opposite to the approach that used with verilog-a osdi modules, you can compile them out of source.
Last edit: George 2024-05-20
Well, the *intention* of code models (*.cm) is definitely to make them independent of compiling ngspice. (That's one reason why you need to load them with codemodel (17.5.12)). It may take some make-file-magic to disentangle it from the current generation process -- I only ever tried the reverse (compiling XSPICE models as native ones).
-marcel
Last edit: marcel hendrix 2024-05-20
The adc_bridge XSPICE element with differential input makes an ideal comparator if both thresholds are set to zero. Output is digital, so an "event", if that is what is wanted. (The problem posed in the original post is not easy to interpret!) If the output is fed to a dac_bridge to return to the analogue domain, a transient simulation breakpoint is inserted at transitions. And then the output might drive a somewhat realistic output stage; open drain ...
The XSPICE discussion is interesting to me. Yes, you could build an XSPICE model independently, but in practice everything is tightly bound to the ngspice build system. Mostly by cmpp, but you must also use the header files of the XSPICE binary that will run. The d_cosim and d_process code models provide some distance. I have been developing some d_cosim clients entirely outside ngspice, except for the cmtypes.h file to define Digital_t. Both are digital-only, but adding analogue nodes seems straightforward. And with d_process, anything is possible. Your model may be a shell script or ...
yes, this is what I wanted, brilliant idea to use the adc/dac bridges, thank you very much!
Super dumb question - how to configure adc in differential mode?
Variants: [ (vc_i ramp) ]
[ vd(vc_i ramp) ]
[ d(vc_i ramp) ]
(vc_i ramp)
don't work...
Upd: found it, sorry [ %vd(vc_i ramp) ]
Last edit: George 2024-05-20
My limited understanding is that the sources'
"event flagging" happens at netlisting where the
timepoints are harvested. Not a "real time, as it
goes" type surveillance.
So I am not too optimistic that other SPICE elements
can do this.
XSPICE is a "personal growth area" not yet taken up.
But I wonder about the veriloga option, "events"
seem to be created there. Whether these pass to
the ngspice engine, presently or possibly, no clue.
But there's "event-y" stuff that transitions the outputs
at finite slew at edges, etc. that maybe "could".
Wonder if there's a pipe for that.
Secondary notion - if the "breakpoints" are a managed list,
could that list evolve "real time", "just in time" to take in
"discovered events"? Maybe with enough of a "smart
step-back" to then apply that logic (whatever) to timestep
control, without having first to fail convergence (in my
gut understanding, this has some probability of getting
out over its skis before it notices, and maybe this "be
ready to step back, on warning" would help some of that
(if precursors to failure are recognized, along with
"something's coming" from veriloga modules and such)?
And, could a "code model" be educated how to jam a
warning to that list too? Presuming it works anything like
imagined?
I am not sure that I understood everything there, but I think you described how things work now, and for many years. The transient analysis code maintains a list of breakpoints (times when a step will be forced to end) and circuit elements may add to it as simulation proceeds. Grepping the code shows that 8 XSPICE elements currently do that (including dac_bridge and bidi_bridge), also the independent sources (PULSE and PWL) and one of the transmission lines. I did not find it in the OSDI sub-system, but I am unfamiliar with that.
But this technique is not applied everywhere that may be useful. It seems to me that such code might be added to all PWL sources and switches, leading to improved convergence. And one that may be tricky to implement: a breakpoint might be inserted whenever the controlling term of a "?" operator in the expression for a controlled source changes value.