#56 Multinode bus

[Bohdan Tkhir]

Hi!

There was a request . which gave me an idea:

Models can be so much more flexible with multi-inputs (multi-outputs).

For example:
Let's define a bus with 4 nodes and name it in_bus<3:0> instead of ** in0 in1 in2 in3.
After it we can call single node from this bus (smth like vector) ** in_bus<1> or in_bus<0>.
Also we can call full bus array in_bus< N:0>.
Bus width can be changed dinamically in single place which is decreasing chance for mistake.

.TITLE

V_Vss vdd 0 DC 3.3
V_pulse sine 0 DC 0 SIN(0 1 1000) 

.PARAM N = 2 $ BUS SIZE  ( Defines bus width)
.PARAM table_values_lut = "00010001" 

.subckt testcir in_bus<N:0> outlut1 outlut2 
    A_genlut1 [in_bus<N:0>] [outlut1] genlut   $ INPUTS FROM FULL BUS      
    A_genlut2 [in_bus<2> in_bus<1> in_bus<2>] [outlut2] genlut   $ INPUTS FROM SPECIFIC BUS ELEMENTS 
            .model genlut d_genlut (table_values = {table_values_lut}) 
.ends testcir

A_ADC [sine vdd 0] [in_bus<0> in_bus<1> in_bus<2>] ADC
        .model ADC adc_bridge(in_low=0.7 in_high=0.71)

X_subckt in_bus<N:0> out1 out2 testcir

    .control
        tran 1 1
        run
    .endc
.end

By the way: Is stable Ngspice-30 release date a secret? :)
Or you can tell approx. date?

[marcel hendrix]

On 2018-12-06 17:18, Bohdan Tkhir wrote:

There was a
request .
which gave me an idea:

Models can be so much more flexible with multi-inputs (multi-outputs).

For example:
Let's define a bus with 4 nodes and name it in_bus<3:0> instead
of ** in0 in1 in2 in3.
After it we can call single node from this bus (smth like vector) **
in_bus<1> or in_bus<0>.
Also we can call full bus array in_bus< N:0>.
Bus width can be changed dinamically in single place which is
decreasing chance for mistake.

You mean, like in LTspice?

-marcel

[Justin Fisher]

Hi Marcel.

Does LTspice do this in the simulator? This is not an uncommon feature in
integrated schematic editor/simulators, PSPICE, Cadence, Mentor etc, but
it's just a schematic thing converted by the netlister. A bus that looked
like bus<1:0> netlists to something like bus_1, bus_0...

It's on my todo list for my Gschem netlister. I'm not really sure it's
worth the effort to add it to the simulator.

--
Kind regards,

Justin Fisher.

[marcel hendrix]

On 2018-12-06 20:19, Justin Fisher wrote:

Hi Marcel.

Does LTspice do this in the simulator? This is not an uncommon feature
in
integrated schematic editor/simulators, PSPICE, Cadence, Mentor etc,
but
it's just a schematic thing converted by the netlister. A bus that
looked
like bus<1:0> netlists to something like bus_1, bus_0...

It's on my todo list for my Gschem netlister. I'm not really sure it's
worth the effort to add it to the simulator.

It's a schematic editor thing, because LTspice does not have multi-part
devices, and I couldn't get it to work with subcircuits. In XSPICE,
we do have those (e.g any number of DAC_bridge or ADC_bridge one-bitters
in a single model with [..] selection on the pins.) In NGSPICE it
would therefore be a killer feature.

I have attached an example ( .asc. .cir and .png ).

SIMetrix appears to also handle vector inputs, but I don't remember
how it goes there. The schematic entry automatically inserts the
bridges,
yet another really nice feature that greatly unclutters the schematic.

BTW, I thought you had abandoned your netlister :-) I have added my
own netlister to gschem, but it doesn't handle busses and bridges
yet, and it uses an unfamiliar programming language.

-marcel

[Justin Fisher]

No - not abandoned, I still use it and I update it whenever I have time.

It's written in C with heavy use of environment variables which makes it
useful for project specific things.

--
Kind regards,

Justin Fisher.

[Bohdan Tkhir]

Seems like that, but not only in schematic editor, but in netlist syntax too.

[Giles Atkinson]

I had already started a different way to handle busses when I noticed this post. I had thought of defining a new XSPICE node type for "digital bus value" and a bridge/mux element to connect individual digital nodes. Analogue nodes might be handled the same way, but look messier.

However, the idea here may be implemented by netlist rewriting and seems more powerful. Perhaps the two approaches are somewhat complementary and there is room for both.

I have a prototype, where this netlist:

Try bus substitution

.param two=2 three=3 four=4

.model dut d_and

.subckt sub x y  n=three
Xbussub x y inner n=2
Rdut x[1] y[1] 3
.ends

.subckt inner x y n=four
Adut [ x[1:n] ] y dut
.ends

Rdut b[0] b[1] 3
xtest a b sub
xtest2 a b inner n=4
.end

becomes this:

ngspice 27 -> listing e
        try bus substitution

     1 : try bus substitution
     7 : .model dut d_and
    17 : rdut b_0  b_1  3
    15 : a.xtest.xbussub.adut [ a_1 a_2  ] b dut
    11 : r.xtest.rdut a_1  b_1  3
    15 : a.xtest2.adut [ a_1 a_2 a_3 a_4  ] b dut
    19 : .end
     3 : .model auto_adc adc_bridge(in_low=    1.650000000000000e+00     in_high=    1.650000000000000e+00    )
     4 : auto_adc2 [ a_1 ] [ a_1 ] auto_adc
     5 : .end

Before I take it further, it would be useful to get comments and perhaps some independent testing. If anyone is interested to try it, I can push the code to a Sourceforge branch and perhaps build binaries.

Some comments and description:

I used [], not <>, because there seems less possibility of conflict with other parts of netlist parsing. As far as I know, [] is used only by A devices, and indexed node names go straight through other parsing. Indeed, node[n] needs to be written as node_n only because a vector whose name is node[n] is not accessible.

The feature is likely to be incompatible with some netlist features at first, so must be configurable, and probably initially off by default.

Bus nodes must be written without any spaces: "node[low:high]" not "node [ low : high ]". Similarly, the [] for XSPICE vector nodes must have at least one adjacent space to avoid confusion.

Bus nodes for subcircuits appear without subscripts in both subcircuit definitions and invocations (Xxxx lines). They are indexed only in the elements inside the subcircuit.

What Marcel described above seems to be a different, closely related, feature: device expansion rather then node expansion. They should work together. A node may be doubly-indexed with the first index for device expansion and the second for bus.

* A register is a stack of flip-flops.

.subckt dreg in out clock reset width=8
aff[0:width-1] in[][0:width-1] clock null reset out[][0:width-1] ff
.ends

.model ff d_dff

* A fixed bus delay as a stack of registers.

.subckt dbus_delay in out clock reset width=8 depth=1
.if (depth = 1)
        xreg1 in out clock reset dreg
.elseif (depth = 2)
        xreg1 in out_1 clock reset dreg
        xreg1 out_1 out clock reset dreg
.else
        xreg1 in out_1 clock reset dreg
        xreg[1:depth-2] out[1:depth-2] out[2:depth-1] clock reset dreg
        xreg1 out_{depth-1} out clock reset dreg
.endif
 .ends

* Delay a 16-bit bus for three clocks

xdelay bus slow_bus clock reset dbus_delay width=16 depth=3

The .if processing to connect a stack to the external nodes of an enclosing sub-circuit is ugly and there should perhaps be some special syntax to make it automatic:

.subckt dbus_delay in[0:iout] out[iout:depth] clock reset width=8 depth=1
xreg[1:depth] iout[0:depth-1] iout[1:depth] clock reset dreg
.ends

Here the indexing of nodes in .subckt indicates that an instance of an internal node is to be replaced by the external node when an index matches.

Device expansion for subcircuits looks possible but may be tricky to code. Parameter values are only available after subcircuit expansion is complete so for each Xsub[low:high], a slab of netlist must be copied and rewritten. And they may be nested, as above.

[marcel hendrix]

As soon as devices like Vs[1:4] are allowed, there will be requests to individually set and get the parameters of Vs[i] . It will also influence printing and plotting.

Can this be done with a standard preprocessor pass through the netlist? I've used cpp from the LCC distribution for similar purposes in the past. The advantage would be that the feature does not destabilize the standard distribution.

[Giles Atkinson]

Individual nodes can be accessed in the netlist as node[3] or bus[width-1]. It is almost inescapable that they appear in "display" output with modified vector names. But commands like (e)print, (gnu,i,)plot, wrdata and write should also understand the bus node notation. And if device expansion is added, that may be extended to "alter" and "alterparam". I believe they all have similar parsing, so a single subroutine may be enough. It may be limited to purely numeric forms, "bus[2:5]", but it may also be possible to recover the correct form of parameter name from a dotted node syntax. The original .param bindings used are long gone when we plot results!

A pre-processor is certainly an alternative method, but I suspect that syntax that cpp can understand would likely be ugly and maybe ambiguous. A model name and bracketed parameter list may be mis-parsed as a CPP macro. I would suggest the ancient m4, or a perl or python script. But any such method would add yet another store of named numbers and another expression evaluator to the .params, vectors/variables, and controlled source expressions that ngspice users may battle with. (Is there a fourth or fifth kind?) And to handle device expansion, it probably needs to exactly duplicate the current subcircuit behaviour.

I think I share your concern that a feature like this may break the current complex netlist parsing. For now it sits lightly on the code. Only three locations are modified by the current prototype and I believe that when it is disabled, processing is exactly as before.

[stefan]

xschem as a schematic editor allows all kind of bus notation and you can create subcircuit models with bus i/o ports (see image). It also has the usual bus tap notation to handle bus bit slicing. Instances also can be vectorized, for example R1[3:0] is a set of 4 resistors that may connect directly to a bus net DIN[3:0]. When creating a spice netlist for simulation all buses (and vectored instances) are unrolled into their single bits (like DIN[3:0] --> DIN[3], DIN[2], DIN[1], DIN[0]) and the generated netlist is compatible with legacy spice simulators.

The [ and ] characters can be replaced with < and > if this creates conflicts with the XSPICE subsystem

[marcel hendrix]

and you can create subcircuit models with bus i/o ports (see image)

Can the bus notation also be used inside a subcircuit? This makes printing internal node voltages and branch currents a challenge. Defining functions inside a subcircuit are another attention issue (e.g. one can mix vector and unrolled notation).

[Giles Atkinson]

Yes, it was clear in the XSCHEM manual that node expansion duplicates a function already in XSCHEM, And I guess the ability to nest subcircuits graphically may mean that device expansion may also look like a duplicate. But I am curious if the parameterisation of bus and node expansion described here offers any additional benefit to the XSCHEM user.

And for XSCHEM, the recently added feature of Verilog co-simulation may also be interesting, as it seems most of the needed parts already exist.

[Alfredo Tomasini]

I opened this discussion in the ngspice forum, Giles pointed out that I should add it to this forum.
It may be of general interest, in spite it is know problem on ngspice side.

Stefan provided a work around from xschem side, via netlist_options.sym setting

from

us_replacement_char=[]
lvs_netlist=false
spiceprefix=true
hiersep=.

to

us_replacement_char=<>
lvs_netlist=false
spiceprefix=true
hiersep=.

However I think it will be a better to fix this in the simulator side. It becomes a compatibility issues with existing netlist generated from other tools (commercial and non-commercial).
From my experiment it seems that the simulator already run properly with instance names and node names having [] notation.
The issue it refuses to save the parameters in the raw file with .save because to the presence of [] twice (this was speculative on my side suggested by common sense, Stefan confirmed in a separate email).

example : .save @m.x[0].m6[vdsat].

does not save anything in the raw file, in spite this information is available in the .log as OP.

In interactive mode print cannot access @m.x[0].m6[vdsat] or @m.x[0].m6[vdsat] or
print "@m.x[0].m6[vdsat]".

This from my point of view is even more serious problem because it means that within the .control
section it is not possible to check if a transistor is in saturation or linear region by
verifying
@m.x[0].m6[vdsat] against @m.x[0].m6[vds]
with the MEAS statement.

I am aware that <> and [] are considered special characters for xspice - page 48 of ngspice-43 manual - but ngspice seems to be happy to use them ...

The case:

in the attached schematic I am using array of instances to concatenate 3 block x[0:2].
xschem tools does an excellent job to generate the proper netlist

x1 vcasc inp inn ib0 op[0] on[0] vdd gnd balance_simple
x[0] vcasc op[0] on[0] ib1 op[1] on[1] vdd gnd balance_simple
x[1] vcasc op[1] on[1] ib1 op[2] on[2] vdd gnd balance_simple
x[2] vcasc op[2] on[2] ib1 outp outn vdd gnd balance_simple

However, if I ask ngspice to save the vdsat of one of the transistor in the x[0], for instance

.save @m.x[0].M3[vdsat]

ngspice does not save it, so no back annotation.

(probably because [] are present in the node name. For instance see page 48 of ngspice-43 manual )

However ngspice run the simulation fine with [] as part of the nodename, in fact the op in the log
file shows the desired value

BSIM4v5: Berkeley Short Channel IGFET Model-4
device m.x[0].m1 m.x[0].m3 m.xa.m8
vdsat 0.0452087 0.0452087 0.0472694

and it is correct !

If I use cadence style <x:y> for the array of instances in xschem. Well xschem does not do the
expansion these instances and nets.
But ngspice can save the new parameter in the raw file, this</x:y>

.save @m.x<0>.M3[vdsat]

works. But xschem does not know how to use this.
I did this experiment by changing the netlist manually from x[] to x<> with the corresponding .save