X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 4 Jan 2019 15:51:16 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] [tEDAx] drc block: spec and ref implementation finished In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-331152394-1546613476=:21900" Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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--