← Back to team overview

kicad-developers team mailing list archive

Re: Improving Eagle Import netlist matching

 

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?
>>>>>>     >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

References