>>=20 >>=20 >>=20 >>=20 >=20 >=20 John Doty Noqsi Aerospace, Ltd. jpd AT noqsi DOT com --Apple-Mail=_A7AD5E4F-F4C2-4B10-ABB4-8DDC94087CF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 16, 2020, at 2:09 PM, Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

I = will look at spice-noqsi further but seems like we are coming at the
problem from opposite directions. I am saying put the SOCs in = the
schematic and remove them when doing non simulation = output. The only way
I can see to do this without all the = backends having to contain the same
SOC removal logic is = to put it in gnetlist. To my way of thinking this
also = allows for clean printout.

Having separate = test-fixture and layout versions puts you back into the
parallel design issue.

Not = really. The test fixture is a separate page that contains only test = components. There=E2=80=99s no parallel development for the pages that = represent the circuit you=E2=80=99re going to lay out.

Does spice-noqsi support the xspice = components, digital and hybrid?

Yes. You = just have to write suitable prototypes.

Admittedly the possible error checking things = were sort of add-ons. The
core idea is to handle SOCs = transparently with minimal surrounding
infrastructure. I = don't see a reason to have makefiles etc if all you
want = to do is have a transistor inverter between a couple of logic gates.

You = don=E2=80=99t need makefiles. I don=E2=80=99t always use them. But when = things get complicated, it's handier to have the commands in a makefile = rather than trying to remember them.

So= I think the main difference between our approaches (other than = you've
actually already coded yours) is starting point. = Having multiple options
allows the user to pick the = approach that works best for them.

Glenn

John Doty wrote:

On Oct 15, 2020, at 11:31 PM, Glenn (glimrick AT epilitimus DOT com
<mailto:glimrick AT epilitimus DOT com>) [via geda-user AT delorie DOT com
<mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com
<mailto:geda-user AT delorie DOT com>> wrote:

I did look at spice-noqsi but it didn't look = to me like it solved the
problem.

The spice-prototype attribute in = spice-noqsi can do much of what you want.

A = component omitted from simulation has:

spice-prototype=3D* comment on reason for omission.

A two terminal component to be short-circuited = in simulation has:

spice-prototype=3DR? #1 = #2 0

There=E2=80=99s great benefit in = separating simulation and layout
environments,
see https://github.com/noqsi/gnet-spice-noqsi/wiki/Broadband-amplif= ier-board.
Simulation-only components may appear in = =E2=80=9Ctest fixture=E2=80=9D schematics.
Flow of = revisions from master (layout) to tinkering (simulation) may
be controlled by a Makefile. Using SPICE to expand hierarchy = for
simulation while flattening hierarchy for layout = allows for
simulation-only components, where the = spice-prototype rules
simulation, while a source file with = no components (but possibly
connections) rules layout.

For me, the missing piece is attributes on net = segments. These could
be used for series parasitics in = SPICE (using a suitable
spice-prototype) as well as = communicating current-carrying capacity,
impedance, and = topological constraints to layout. Right now,
attributes = can be attached to nets with graphical symbols, but
topological information is lost.

I= intended spice-noqsi to augment the toolkit approach, so it = doesn=E2=80=99t
cover things that your configuration = files, makefiles, sources, and
SPICE itself can = accomplish.

John Doty = Noqsi Aerospace, Ltd.

jpd AT noqsi DOT com <mailto:jpd AT noqsi DOT com>

John Doty = Noqsi = Aerospace, Ltd.

jpd AT noqsi DOT com

= --Apple-Mail=_A7AD5E4F-F4C2-4B10-ABB4-8DDC94087CF5--