Mail Archives: geda-user/2019/01/04/09:52:34
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-331152394-1546613476=:21900
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Fri, 4 Jan 2019, John Doty wrote:
>A few comments from a SPICE simulation/IC design perspective.
>Having separate value and device attributes for SPICE is a good idea.
>
>The rest of your SPICE concept seems not to address the difficulties. Mere=
ly
>having a component value is not enough in many cases. See the prototypes a=
t
>the end of=C2=A0https://github.com/noqsi/gnet-spice-noqsi/wiki/Reference. =
These
>only cover the most common cases: this needs to be user-extensible.
Thank you!
What I plan long term is having a separate block for each device instance=
=20
for spice, with as many lines as needed, potentially hosting a whole spice=
=20
model if needed, and only referencing that block from the netlist.=20
Probably the spicedev line would change into a reference with the argument=
=20
being the block ID for the block that holds all spice-related lines.
We have a very good cooperation with xschem, and xschem has good support=20
for both tEDAx netlist and spice, so we have a place to experiment with=20
these, thinking in full workflows rather than isolated software islands.=20
I expect there will be a lot happening on this the next few years.
However, at the moment there is no simulator that would import a tEDAx=20
netlist. I think I won't go and extend the format specification until we=20
find a sim where developers are interested to test the format and help in=
=20
refining the specification.
>Your pin sequence/slot concept seems to follow the gschem/gnetlist approac=
h.
>This has historically caused a lot of trouble, a rare fundamental design
>error in geda-gaf.
There are some common points, like pinidx is similar to pinseq, but I also=
=20
see major differences to the gschem/gnetlist model.
First of all, the tEDAx netlist format does not tell how the slot info=20
should be stored on schematics side, so it doesn't have to be done the=20
same way gschem/gnetlist does it.
All tEDAx netlist does is specify a grouping of pins. It does not do it=20
from the slot's perspective (AFAIK that's what gschem does), but from the=
=20
pin's perspective.
We already have support for slotting export in xschem, so we will start=20
expermenting with both pcb-rnd and spice this year. If we see major=20
problems with the current concept, we will issue a v2 block with a=20
different setup. If you know specific use cases the current tEDAx slotting=
=20
setup would fail, please let me know, so we can include those in our=20
tests.
>It looks like you?re planning to support hierarchy in the future. This wou=
ld
>be very handy for simulation, and it is essential in flows that feed SPICE
>netlists to layout tools.
Yup, long term. But this really requires a spice sim project to join the=20
effort, this part is on hold until that. We have some spice-related=20
projects going on and I think in a few years coralEDA will have a strong=20
SPICE support. Especially for the "same schematics used for sim and pcb=20
layout, with explicitly free spice models". I plan to then contact spice=20
projects to see if they are interested. Until that, the SPICE part in=20
tEDAx netlist will probably remain a stub.
Best regards,
Igor2
--0-331152394-1546613476=:21900--
- Raw text -