← Back to team overview

kicad-developers team mailing list archive

Re: Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

 

Hi,

Just a thought. This feature could also be very useful to import/export of FPGA physical constrain files (PCF). This would allow us to keep the pin naming in sync between the schematic and HDL. Maybe even simplify pin swapping?

Cheers,
Piotr

> On May 9, 2019, at 7:55 AM, Johannes Wågen <johannes@xxxxxxxx> wrote:
> 
> Hi
> 
> The open source FPGA tools also have this.  It might be worth to take a look at[1]. It is written in JavaScript, but it does perhaps give some indication of what such a tool could be capable of.
> 
> [1] https://github.com/nturley/netlistsvg
> 
> 
> -Johannes Wågen
> 
> Den 09.05.2019 14:32, skrev Reece R. Pollack:
>> You might want to take a look at how Xilinx ISE and similar products handle this. Their tools take in Verilog or VHDL and can produce a graphical representation of the resulting logic. It's not as readable as a hand-drawn schematic but it exists and enough people find it useful that Xilinx maintains it.
>> 
>> -Reece
>> 
>> On 5/3/19 6:38 PM, Russell Oliver 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
>>> 
>> 
>> 
>> _______________________________________________
>> 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



Follow ups

References