kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

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