Mail Archives: geda-user/2020/10/16/16:41:01
--Apple-Mail=_A7AD5E4F-F4C2-4B10-ABB4-8DDC94087CF5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
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:
>=20
> 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.
>=20
> 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.
>=20
> Does spice-noqsi support the xspice components, digital and hybrid?
Yes. You just have to write suitable prototypes.
>=20
> 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.
>=20
> 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.
>=20
> Glenn
>=20
> John Doty wrote:
>>=20
>>=20
>>> 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:
>>>=20
>>> I did look at spice-noqsi but it didn't look to me like it solved =
the
>>> problem.
>>=20
>> The spice-prototype attribute in spice-noqsi can do much of what you =
want.
>>=20
>> A component omitted from simulation has:
>>=20
>> spice-prototype=3D* comment on reason for omission.
>>=20
>> A two terminal component to be short-circuited in simulation has:
>>=20
>> spice-prototype=3DR? #1 #2 0
>>=20
>> There=E2=80=99s great benefit in separating simulation and layout
>> environments,
>> see =
https://github.com/noqsi/gnet-spice-noqsi/wiki/Broadband-amplifier-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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> John Doty Noqsi Aerospace, Ltd.
>>=20
>> jpd AT noqsi DOT com <mailto:jpd AT noqsi DOT com>
>>=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
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Oct 16, 2020, at 2:09 PM, Glenn (<a =
href=3D"mailto:glimrick AT epilitimus DOT com" =
class=3D"">glimrick AT epilitimus DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">geda-user AT delorie DOT com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">I =
will look at spice-noqsi further but seems like we are coming at the<br =
class=3D"">problem from opposite directions. I am saying put the SOCs in =
the<br class=3D"">schematic and remove them when doing non simulation =
output. The only way<br class=3D"">I can see to do this without all the =
backends having to contain the same<br class=3D"">SOC removal logic is =
to put it in gnetlist. To my way of thinking this<br class=3D"">also =
allows for clean printout.<br class=3D""><br class=3D"">Having separate =
test-fixture and layout versions puts you back into the<br =
class=3D"">parallel design issue.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>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.</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D"">Does spice-noqsi support the xspice =
components, digital and hybrid?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>Yes. You =
just have to write suitable prototypes.</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D"">Admittedly the possible error checking things =
were sort of add-ons. The<br class=3D"">core idea is to handle SOCs =
transparently with minimal surrounding<br class=3D"">infrastructure. I =
don't see a reason to have makefiles etc if all you<br class=3D"">want =
to do is have a transistor inverter between a couple of logic gates.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>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.</div><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""><br class=3D"">So=
I think the main difference between our approaches (other than =
you've<br class=3D"">actually already coded yours) is starting point. =
Having multiple options<br class=3D"">allows the user to pick the =
approach that works best for them.<br class=3D""><br class=3D"">Glenn<br =
class=3D""><br class=3D"">John Doty wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D""><br class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">On Oct 15, 2020, at 11:31 PM, Glenn (<a =
href=3D"mailto:glimrick AT epilitimus DOT com" =
class=3D"">glimrick AT epilitimus DOT com</a><br class=3D""><<a =
href=3D"mailto:glimrick AT epilitimus DOT com" =
class=3D"">mailto:glimrick AT epilitimus DOT com</a>>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">geda-user AT delorie DOT com</a><br class=3D""><<a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">mailto:geda-user AT delorie DOT com</a>>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">geda-user AT delorie DOT com</a><br class=3D""><<a =
href=3D"mailto:geda-user AT delorie DOT com" =
class=3D"">mailto:geda-user AT delorie DOT com</a>>> wrote:<br =
class=3D""><br class=3D"">I did look at spice-noqsi but it didn't look =
to me like it solved the<br class=3D"">problem.<br =
class=3D""></blockquote><br class=3D"">The spice-prototype attribute in =
spice-noqsi can do much of what you want.<br class=3D""><br class=3D"">A =
component omitted from simulation has:<br class=3D""><br =
class=3D"">spice-prototype=3D* comment on reason for omission.<br =
class=3D""><br class=3D"">A two terminal component to be short-circuited =
in simulation has:<br class=3D""><br class=3D"">spice-prototype=3DR? #1 =
#2 0<br class=3D""><br class=3D"">There=E2=80=99s great benefit in =
separating simulation and layout<br class=3D"">environments,<br =
class=3D"">see <a =
href=3D"https://github.com/noqsi/gnet-spice-noqsi/wiki/Broadband-amplifier=
-board" =
class=3D"">https://github.com/noqsi/gnet-spice-noqsi/wiki/Broadband-amplif=
ier-board</a>.<br class=3D"">Simulation-only components may appear in =
=E2=80=9Ctest fixture=E2=80=9D schematics.<br class=3D"">Flow of =
revisions from master (layout) to tinkering (simulation) may<br =
class=3D"">be controlled by a Makefile. Using SPICE to expand hierarchy =
for<br class=3D"">simulation while flattening hierarchy for layout =
allows for<br class=3D"">simulation-only components, where the =
spice-prototype rules<br class=3D"">simulation, while a source file with =
no components (but possibly<br class=3D"">connections) rules layout.<br =
class=3D""><br class=3D"">For me, the missing piece is attributes on net =
segments. These could<br class=3D"">be used for series parasitics in =
SPICE (using a suitable<br class=3D"">spice-prototype) as well as =
communicating current-carrying capacity,<br class=3D"">impedance, and =
topological constraints to layout. Right now,<br class=3D"">attributes =
can be attached to nets with graphical symbols, but<br =
class=3D"">topological information is lost.<br class=3D""><br class=3D"">I=
intended spice-noqsi to augment the toolkit approach, so it =
doesn=E2=80=99t<br class=3D"">cover things that your configuration =
files, makefiles, sources, and<br class=3D"">SPICE itself can =
accomplish.<br class=3D""><br class=3D"">John Doty =
Noqsi Aerospace, Ltd.<br =
class=3D""><br class=3D""><a href=3D"mailto:jpd AT noqsi DOT com" =
class=3D"">jpd AT noqsi DOT com</a> <<a href=3D"mailto:jpd AT noqsi DOT com" =
class=3D"">mailto:jpd AT noqsi DOT com</a>><br class=3D""><br class=3D""><br =
class=3D""><br class=3D""><br class=3D""></blockquote><br class=3D""><br =
class=3D""></div></div></blockquote></div><br class=3D""><div class=3D"">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-ligatures: normal; =
font-variant-caps: normal; font-variant-east-asian: normal; =
font-variant-position: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-indent: 0px; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;"><div =
style=3D"word-wrap: break-word;" class=3D""><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-ligatures: normal; =
font-variant-caps: normal; font-variant-east-asian: normal; =
font-variant-position: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-indent: 0px; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;"><p =
style=3D"margin: 0px;" class=3D""><font face=3D"Helvetica" size=3D"3" =
style=3D"font-style: normal; font-variant-caps: normal; font-weight: =
normal; font-size: 12px; line-height: normal; font-family: Helvetica;" =
class=3D"">John Doty<span class=3D"Apple-converted-space"> =
<span =
class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0px;" class=3D""><a =
href=3D"mailto:jpd AT noqsi DOT com" class=3D"">jpd AT noqsi DOT com</a></p><br =
class=3D"Apple-interchange-newline"></span></div></span><br =
class=3D"Apple-interchange-newline">
</div>
<br class=3D""></body></html>=
--Apple-Mail=_A7AD5E4F-F4C2-4B10-ABB4-8DDC94087CF5--
- Raw text -