kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

You wouldn't necessarily need to create a graphical representation for the
import, just a representation that will work with the connectivity graph.
Because the connectivity graph is currently tied to the graphical/physical
layout of items (specifically, it looks at how item connection points
overlap with each other and with wire/bus segments), you would likely want
to inject the SKIDL netlist into the middle of connectivity calculation
rather than at the beginning.  That is, build the connection and graph
objects through some special method before the main connectivity update is
run, so that the SKIDL sheets already have valid connectivity and will work
with the rest of the design through hierarchical ports.  There might be
some details here related to global labels that I'm glossing over.

What is the point of ERC if it can't check the whole design, though?

You can't run ERC on the output netlist alone, that would only catch some
kinds of errors.  The ERC system (at least the one in Eeschema) needs to
inspect the input as well.

You could probably side-step the hardest part of generating schematics
(wire routing) but just stubbing out each pin with a wire segment and label
(and using the labels to establish connectivity)

-Jon

On Fri, May 3, 2019 at 6:56 PM Russell Oliver <roliver8143@xxxxxxxxx> wrote:

> I have no doubt about the difficulty of plumbing something like this
> feature into KiCad. Most things are easier said than done.
>
> A few thoughts in response
>
> 1. My initial thought was to skip generating a graphical schematic,
> and to simply join in essence two or more netlists while avoiding name
> conflicts. It seems convoluted to start with essentially a
> connectivity graph, only to create a graphical representation for it
> be be evaluated to create a connectivity graph. It begs the questions
> then, should/could there be a text based representation of the
> connectivity graph created by eeschema with the information needed to
> perform ERC?
>
>  No ERC would be performed between the eeshema Netlist and the Skidl
> netlist. This would be left as a design task. The only ERC check would
> be on the hierarchical pins which would be predefined by the user as
> the interface to the SKIDL generated netlist. Users could be warned
> that ERC information doesn't exist for some components.
>
> 2. Thinking about it further the task of generating a graphical
> schematic shouldn't be too difficult using the SKIDL library. I
> suspect Dave would be disappointed in me for being addicted to
> schematics. A simple grid based layout with plenty of room between
> symbols and using straight line between pins to create connections
> would be possible. This would easiest once Eeschema has python support
> and the new file format.
>
> 2. Editing SKIDL scripts as subsheets I envisage would either be
> through a user defined text editor, or a basic one implemented into
> KiCad. Once the edit has been done, the file would be evaluated
> through the python runtime with the Skidl library (or for a more
> generic solution a user specified command line, with the output
> captured back as a netlist or schematic).
>
> 3. Editing of the resulting components through the edit symbol fields
> dialog I think would be possible but only as a one way operation once
> the generated netlist/schematic has been added. In that sense it would
> be up to the user to maintain that information in the script so that
> it is generated each time.
>
> Kind Regards
> Russell
>
> On Fri, 3 May 2019 at 23:06, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> >
> >
> > On 5/2/19 9:34 PM, Jon Evans wrote:
> > > Neat idea, Russell!
> > >
> > > In theory, this is possible.  In practice, there are many challenges to
> > > overcome.
> > >
> > > The internal representation of the schematic does not resemble the
> > > netlist that is given to PcbNew.
> > > So, a PcbNew netlist (whether generated by SKIDL or anything else)
> would
> > > have to be "imported" to
> > > the schematic in order to create a "Subsheet from Netlist" as you
> describe.
> > > This import process would need to parse the netlist and generate the
> > > internal connectivity state
> > > to allow the schematic connectivity code to work with that subsheet the
> > > same way it works with
> > > regular graphical subsheets.
> > >
> > > That part is technically possible, but the surrounding code to make
> this
> > > a nice experience would
> > > also be a significant task.  How would you edit or update the
> underlying
> > > SKIDL code generating the
> > > subsheet?  How would you display ERC errors that involve both a
> > > graphical schematic and a subsheet
> > > created from a SKIDL netlist?  Would you be able to make changes to the
> > > components on the subsheet
> > > generated from a SKIDL netlist (for example, to edit properties) using
> > > the Edit Symbol Fields
> > > dialog and other things that interact with objects across the whole
> > > schematic hierarchy? If so,
> > > would you be able to back those changes out to valid SKIDL code?
> > >
> > > I don't mean to discourage you or others from pursuing things like
> this,
> > > I just want to caution
> > > that there would be many, many details to talk through and figure out
> > > before a feature of this
> > > complexity could be added to KiCad.
> > >
> > > A route that may be easier to implement, and less intrusive, would be
> to
> > > wait for the coming
> > > Eeschema file format update and Python API, and add support for
> > > generating schematic sheets to
> > > SKIDL itself.  Of course, the complexity there would lie in the
> > > algorithm for laying out the
> > > items described in SKIDL in a graphical fashion.  But, it doesn't have
> > > to be pretty as long as
> > > it is electrically consistent.  You could then include the generated
> > > sheet as a subsheet in the
> > > normal fashion, and update it using Python (since SKIDL is implemented
> > > as a Python library, it may
> > > be possible to have fairly tight integration between SKIDL and KiCad
> > > once the Python API is more
> > > stable and it is possible to interact with the schematic using Python).
> >
> > This is probably the best course of action.  Once the schematic and
> > symbol library code is swigged out to Python, integrating functionality
> > as a third party Python script should be possible since all of the low
> > level objects will be exposed to Python scripting in much the same way
> > as the low level board objects are exposed in the board and footprint
> > editors.
> >
> > >
> > > Best,
> > > Jon
> > >
> > > On Thu, May 2, 2019 at 9:16 PM Russell Oliver <roliver8143@xxxxxxxxx
> > > <mailto:roliver8143@xxxxxxxxx>> wrote:
> > >
> > >     Hi All,
> > >
> > >     First off congratulations to everyone involved with KiCon for
> making
> > >     it a success and the great progress that is happening with Kicad at
> > >     the moment.
> > >
> > >     I've been following Dave Vandenbout's work on SKIDL [1] a while but
> > >     his talk [2] at the conference on SKIDL really showed the power
> that
> > >     programmatic circuit design could bring to electronic design
> > >     especially with a simulation/optimization loop.
> > >
> > >     To that end I wondered weather it would be possible to include the
> > >     netlist output from a SKIDL script into a traditional schematic,
> > >     allowing for the best use of both worlds?
> > >
> > >     Given that we currently have subsheets that can be reused multiple
> > >     times, could it be possible through the inclusion of a netlist
> reader
> > >     into Eeschema to read either a netlist file directly or the result
> of
> > >     executing a SKIDL script and incorporate that back into the larger
> > >     netlist?
> > >
> > >     I can imagine a type of hierarchical sheet where the user can
> specify
> > >     the nets to be shown as sheet pins, which would be connected to the
> > >     matching nets from the netlist file.
> > >
> > >     My question to those with more knowledge of the current netlist
> > >     generation algorithm is how possible this would be?
> > >
> > >     [1] https://github.com/xesscorp/skidl
> > >     [2] https://www.youtube.com/watch?v=WErQYI2A36M
> > >
> > >     Regards
> > >     Russell Oliver
> > >
> > >     _______________________________________________
> > >     Mailing list: https://launchpad.net/~kicad-developers
> > >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > >     Unsubscribe : https://launchpad.net/~kicad-developers
> > >     More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>