← Back to team overview

kicad-developers team mailing list archive

Re: Improving Eagle Import netlist matching

 

Attached are patches which implement the logic below and a test eagle
project to demonstrate the problem.

This patch set though includes a revert of Orsons patch to use only global
labels.
At this point before v5, I'm fine with just using global labels, but I
think this patch set works well


Kind Regards
Russell



On Sun, Feb 18, 2018 at 1:58 PM Russell Oliver <roliver8143@xxxxxxxxx>
wrote:

> Yes there should be a way to match them up.
>
> The logic for it is as follows, for the complex case:
>
> An eagle project with 2 nets (A and B) that are used for zones and
> stitching vias and each appears only on separate sheets, Y and Z
> respectively.
>
> During the import two subsheets are created.
>
> After import in kicad currently each net would be given the local net of
> /Y/A and /Z/B
>
> Pads on footprints are updated after the netlist and then propagate to
> tracks and standard vias.
>
> This leaves the zones and stitching vias on the orphaned nets, A and B.
> Therefore they are then set to the net with the matching local net with the
> suffix "/A" and "/B".
>
> The original logic detected a net that appears on two eagle sheet and used
> global labels, which would result in a global kicad net.
>
> For the case where only one eagle sheet exists a local label can and is
> used, resulting in a net local the root sheet. e.g. "/C". Therefore the
> suffix matching will also work.
>
> What I will require is an easy way to get the list of nets currently in
> the schematic inside of pcbnew . Which when I looked  before didn't really
> exist, except for the pcb update code that uses the KiMail system. At the
> very least a string array of unique net names would be enough.
>
>
> Kind Regards
> Russell
>
>
>
>
>
>
> On 18 Feb 2018 11:38, "Wayne Stambaugh" <stambaughw@xxxxxxxxx> wrote:
>
>> I'm not too sure about our global label solution.  The results are
>> rather heinous.  Take a look at the Ardunino ATMega 2560 board[1] that I
>> demoed at FOSDEM imported using the new label semantics.  I don't think
>> users are going to be OK with this.  Is there no way we can use normal
>> labels properly in hierarchical Eagle schematics?
>>
>> [1]:
>> https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-ref-design.zip
>>
>> On 02/17/2018 05:54 AM, Maciej Suminski wrote:
>> > Hi Russell,
>> >
>> > No worries, the change was easy. I was mostly interested in your view
>> > about the change, and you confirm the main concern is the appearance of
>> > imported schematics.
>> >
>> > I am not sure if netlist updater is able to link a symbol and its
>> > corresponding footprint when sheetpath is not complete, but if that is
>> > the case then your other idea could be a better solution here.
>> >
>> > Best regards,
>> > Orson
>> >
>> > On 02/17/2018 12:18 AM, Russell Oliver wrote:
>> >> Hi all,
>> >>
>> >> Sorry I didn't get to it sooner. Been busy at a new job.
>> >>
>> >> I was going to say that globals will work fine except for the visual
>> >> aspect. Though I think just replacing the global net on the pcb with
>> the
>> >> net from the schematic with the matching end label ( ignoring any sheet
>> >> path)  should work too, since it will be unique anyway if importing
>> from an
>> >> eagle schematic.
>> >>
>> >> Kind Regards
>> >> Russell
>> >>
>> >>
>> >> On 17 Feb 2018 10:06, "Maciej Suminski" <maciej.suminski@xxxxxxx>
>> wrote:
>> >>
>> >> Alright, I switched the importer to use global net labels. Perhaps
>> >> schematics are not always the prettiest ones, but at least they are
>> >> equivalent to the original project.
>> >>
>> >> Cheers,
>> >> Orson
>> >>
>> >> On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
>> >>> If using global nets resolves the issue and doesn't cause any other
>> >>> issues, it has my vote as well.
>> >>>
>> >>> On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
>> >>>> I vote for switching to global nets. I may handle this, just want to
>> be
>> >>>> sure Russell has not started already working on it, so there is no
>> work
>> >>>> duplication.
>> >>>>
>> >>>> Regards,
>> >>>> Orson
>> >>>>
>> >>>> On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
>> >>>>> Gentlemen,
>> >>>>>
>> >>>>> What is the status of this bug fix?  I know there was some
>> discussion
>> >>>>> about this patch.  Do we have path forward on this yet?  I would
>> like to
>> >>>>> get this into rc1 if possible.
>> >>>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> Wayne
>> >>>>> On 02/14/2018 08:17 AM, Russell Oliver wrote:
>> >>>>>> Please find the attached patch for this issue.
>> >>>>>>
>> >>>>>> On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński <
>> >> maciej.suminski@xxxxxxx
>> >>>>>> <mailto:maciej.suminski@xxxxxxx>> wrote:
>> >>>>>>
>> >>>>>>     Hi Russell,
>> >>>>>>
>> >>>>>>     On 02/11/2018 05:41 AM, Russell Oliver wrote:
>> >>>>>>     > Hi All,
>> >>>>>>     >
>> >>>>>>     > I've discovered the cause of a problem when importing Eagle
>> >>>>>>     Projects and
>> >>>>>>     > getting the schematic and boards synced.
>> >>>>>>     >
>> >>>>>>     > Currently when importing an Eagle schematic, labels for nets
>> that
>> >>>>>>     are only
>> >>>>>>     > found one Eagle sheet are imported as local KiCad labels.
>> This
>> >>>>>>     preserves
>> >>>>>>     > the visual design of the schematic some what. For eagle
>> >> schematics
>> >>>>>>     with
>> >>>>>>     > more than 1 sheet, where hierarchical sheets are created in
>> >> Kicad,
>> >>>>>>     global
>> >>>>>>     > labels are created to tie the nets together across the
>> sheets the
>> >>>>>>     same as
>> >>>>>>     > Eagle due to its lack of scopes for net names.
>> >>>>>>     >
>> >>>>>>     > The problem is that the imported PCB will have net names
>> that are
>> >>>>>>     global
>> >>>>>>     > e.g "VBUS" while the imported schematic may end up with local
>> >>>>>>     netname for
>> >>>>>>     > the root sheet e.g "/VBUS". This will cause errors for boards
>> >> with
>> >>>>>>     zones
>> >>>>>>     > and named vias with the original/global netname e.g."VBUS"
>> >>>>>>     >
>> >>>>>>     > My proposal to fix this is to create another pass in the
>> netlist
>> >>>>>>     generation
>> >>>>>>     > code that would remove the forward slash '/' for unique local
>> >> nets
>> >>>>>>     in the
>> >>>>>>     > root sheet provided it does not clash with an existing net
>> name.
>> >>>>>>
>> >>>>>>     Good catch. I would rather not modify the netlist generator
>> code,
>> >> but
>> >>>>>>     add another pass in the board importer. I suggest the
>> following:
>> >>>>>>     - Move netlist generation from kicad/import_project.cpp to
>> >>>>>>     SCH_EDIT_FRAME::ImportFile().
>> >>>>>>     - Move netlist import from kicad/import_project.cpp to
>> >>>>>>     PCB_EDIT_FRAME::ImportFile().
>> >>>>>>     - After importing a board and its netlist, go through the list
>> of
>> >> zones
>> >>>>>>     and try to assign '/' + zone->GetNetname(). If such netlist
>> >> exists, then
>> >>>>>>     it means the assigned net is a local one and needs renaming.
>> The
>> >> only
>> >>>>>>     problem here is a potential conflict if there exist both
>> 'netname'
>> >>>>>>     (local label) and '/netname' (global label). I guess such case
>> >> deserves
>> >>>>>>     a huge warning, so the user needs to verify the import result.
>> >>>>>>
>> >>>>>>     I suppose the last special case should be simply reported by
>> the
>> >> ERC
>> >>>>>>     even without importing a project, as it creates a connection
>> >> between two
>> >>>>>>     seemingly not related nets.
>> >>>>>>
>> >>>>>>     Thoughts?
>> >>>>>>
>> >>>>>>     Regards,
>> >>>>>>     Orson
>> >>>>>>
>> >>>>>>     > Kind Regards
>> >>>>>>     > Russell
>> >>>>>>     >
>> >>>>>>     >
>> >>>>>>     > P.S During debugging this issue, I discovered that a local
>> label
>> >>>>>>     and global
>> >>>>>>     > label of the same name on the same sheet are connected
>> regardless
>> >>>>>>     of any
>> >>>>>>     > wires. Which if there is a hierarchical sheet can lead to the
>> >> same
>> >>>>>>     net for
>> >>>>>>     > 2 wire segments on separate sheets connected only to local
>> >> labels,
>> >>>>>>     if the
>> >>>>>>     > identical global label is somewhere else on both sheets. Is
>> this
>> >> the
>> >>>>>>     > expected behaviour? or just a side effect?
>> >>>>>>     >
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>>
>

Attachment: ophanzonetest.zip
Description: Zip archive

Attachment: 0002-Eagle-Schematic-Import-Fix-netlist-mapping-for-zones.patch
Description: Binary data

Attachment: 0001-Revert-Eagle-importer-use-only-global-net-labels.patch
Description: Binary data


Follow ups

References