kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 17/04/2018 à 04:41, Jon Evans a écrit :
> I have confirmed that there are no technical challenges with the migration plan proposed by Orson.
> I made some quick test code that automatically performs the migration silently (i.e. by choosing a
> label randomly from the available ones to keep)
> Before I go too far down this path (i.e. making a nice GUI for the migration that lets the user
> control it, etc), does anyone have any other concerns with this?
> JP, maybe you either created this feature or remember its creation, do you have any input?

There is a long time since I wrote it, but I am thinking this feature is just a side effect of the
fact the netlist handles bus connection between hierarchical sheets:

When the bus XX[0..8] is connected to the pin sheet ZZ[0..8], the connection is made between 2 bus
with different names.
This is very similar to your sample.

A similar case is connecting 2 different labels by the same wire: this is a common case with
hierarchical sheets and/or global label like hidden power input pins (that are a type of global label)

> 
> Thanks,
> Jon
> 
> On Mon, Apr 16, 2018 at 9:48 AM, Jon Evans <jon@xxxxxxxxxxxxx <mailto:jon@xxxxxxxxxxxxx>> wrote:
> 
>     I think the logic you describe wouldn't be too bad to implement.
>     I already have logic that collects all of the labels attached to a bus subgraph (an set of
>     visually-connected bus wires)
>     I could just split the bus name from the vector numbers, figure out what the size of the output
>     vector should be, and propose a new name to the user.
>     I guess it would need a dialog box because the user should get to choose what name comes out
>     (there might not always be an obvious "winner", for example if each of the three buses in the
>     example had the same width)
> 
>     If everyone else is on board with this approach, I'll make a test implementation to share.
> 
>     -Jon
> 
>     On Mon, Apr 16, 2018 at 9:39 AM, Maciej Sumiński <maciej.suminski@xxxxxxx
>     <mailto:maciej.suminski@xxxxxxx>> wrote:
> 
>         I agree this a slightly confusing feature, which requires reading the
>         user manual to discover. I vote for removal, but we need a clever
>         migration plan to do so.
> 
>         I am not sure how easy would it be to implement it, but how about the
>         following automatic fix:
>         - determine the superset of connected buses (PCA[0..15] in the user
>         manual example)
>         - determine the other bus names (ADR[0..7] and BUS[5..10])
>         - rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)
> 
>         I believe such method keeps the connectivity data intact. Obviously it
>         would have to be approved by the user, no silent changes.
> 
>         Cheers,
>         Orson
> 
>         On 04/16/2018 05:05 AM, Jon Evans wrote:
>         > I thought about various ways that we could actually make this feature work,
>         > but the more I thought about it, the more I thought that we would be
>         > bending over backwards to support something that shouldn't exist in the
>         > first place (in my opinion).
>         >
>         > Does anyone have a justification for this feature existing?  I'm not trying
>         > to sound negative here, but if there is no benefit to it, and eliminating
>         > it makes the rest of the behavior simpler to code and more logical and
>         > consistent, we should choose that path.
>         > If an ERC is not enough of a migration, we could also give a more specific
>         > one-time nag dialog telling the user in detail what they are going to have
>         > to do to fix their buses.
>         >
>         >
>         > -Jon
>         >
>         > On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand <seth.hillbrand@xxxxxxxxx
>         <mailto:seth.hillbrand@xxxxxxxxx>>
>         > wrote:
>         >
>         >> Hi Jon-
>         >>
>         >> The major issue I think we would need to address is migration.  I don't
>         >> think that only an ERC warning is sufficient in this case.  Users will
>         >> rightfully expect that their old schematics will generate valid netlists
>         >> when opened in a newer KiCad.
>         >>
>         >> One option here would be to translate the implicit net connections into
>         >> explicit ones when bus junctions are encountered.   Unfortunately, I think
>         >> that this feature is lightly used, so we might not get much user feedback
>         >> until they encounter problems and then the problems will be very bad
>         >>
>         >> An alternative might be to increase the functionality of the bus
>         >> junction.  Spitballing here but we might add a "mapping table" dialog that
>         >> allowed the user to specify the winning name and mapping order.  That
>         >> should address your points 2-3 although point 4 might be the issue.  I
>         >> think we could have a default mapping that follows the expected convention
>         >> but allow users to change it by double-clicking on the junction and editing
>         >> the mapping table.  Then previous users could keep their functionality
>         >> while still allowing the arbitrary member arrays you are building.
>         >>
>         >> Thoughts?
>         >> -S
>         >>
>         >>
>         >> 2018-04-15 16:40 GMT-07:00 Jon Evans <jon@xxxxxxxxxxxxx <mailto:jon@xxxxxxxxxxxxx>>:
>         >>
>         >>> Hi all,
>         >>>
>         >>> I am proposing to remove some behavior from KiCad as part of my bus
>         >>> connections changes.  I know we generally don't remove features in new
>         >>> releases without good reason, but I think this is an exceptional case.
>         >>>
>         >>> The user manual describes a way in which you can connect multiple
>         >>> different buses together with junctions.  If you aren't already familiar
>         >>> with this behavior, please check out the manual:
>         >>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
>         <http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse>
>         >>> s-labels-power-ports
>         >>>
>         >>> The section in question is called "Global connections between buses" and
>         >>> comes with the following image and describes how these bus wires with
>         >>> different labels are connected together:
>         >>>
>         >>> Allowing this kind of behavior is problematic for a number of reasons:
>         >>>
>         >>> 1. It means that net wires and bus wires behave differently, since net
>         >>> wires can't have more than one label.  This is potentially confusing for
>         >>> users.
>         >>>
>         >>> 2. It means that junctions need a lot of special logic in order to
>         >>> resolve which "branch" of a bus is called what name (for example, what if
>         >>> one of those three branches in the above image didn't have a label? What
>         >>> would its nets be called?)
>         >>>
>         >>> 3. Maybe most importantly, it breaks the label->netlist paradigm, since
>         >>> an electrical net will only have one label in the eventual netlist, and
>         >>> there is no way to determine which label should "win"
>         >>>
>         >>> 4. I don't think there's a way to map this behavior onto the new bus
>         >>> system I have built that allows arbitrary bus members (instead of just a
>         >>> sequential vector) in a way that would make any sense to the user.
>         >>>
>         >>> My proposed changes in this area are as follows:
>         >>>
>         >>> 1. Remove this section from the user manual.
>         >>>
>         >>> 2. In my new connectivity algorithm, treat all connected bus wire
>         >>> segments as being part of the same bus (meaning they all will have the same
>         >>> "name")
>         >>>
>         >>> 3. Add an ERC warning about having more than one label attached to a bus
>         >>> (the warning would appear in the case of the example picture above)
>         >>>
>         >>> 4. Add a note to the user manual stating that this warning is new for 6.0
>         >>>
>         >>> The only downside that I can see in this approach is that any users who
>         >>> relied on this feature will suddenly get new ERC warnings.  But I think
>         >>> that this is an "anti-feature" in that it creates confusion instead of
>         >>> adding value, so we should nudge anyone who uses it towards a different
>         >>> approach.
>         >>>
>         >>> Anyone see any issues with this plan?
>         >>>
>         >>> Thanks,
>         >>> -Jon


-- 
Jean-Pierre CHARRAS