Global bus signal labels changed

Bug #1822964 reported by Oleg Endo on 2019-04-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jon Evans

Bug Description

I've been doing global buses across multiple sheets as shown in the attached screenshot. The bus name uses a global label, but the individual bus signals use local labels.

The behavior has always been that the local labels automatically become global labels. Since 1 or 2 days ago, something broke that behavior. Now the local labels are exported to the netlist (and to pcbnew) always with the schematic sheet prefix. This of course breaks all the existing designs.

Is that an accidental bug/regression or have I been using global buses wrong all the time?

I'm using the nightly builds on Ubuntu 18.

Oleg Endo (oleg.endo) wrote :
description: updated
Rene Poeschl (poeschlr) wrote :

Recently a major update to the bus handling has been added. (Buses are now much more powerful)
This is very likely a result of that. Could you share a minimal project that showcases your behavior?

Could you share your project or a minimal example of what worked in the past but does no longer work?

Changed in kicad:
milestone: none → 6.0.0-rc1
Jon Evans (craftyjon) wrote :

Hi Oleg,

Like Rene says, there have been some major changes to the way netlisting works recently (in order to enable some key new features), and it will likely take some time to settle down and work out any bugs.

If you are able to share your design with me it would simplify debugging this greatly. You can find my email in my profile.


Changed in kicad:
assignee: nobody → Jon Evans (craftyjon)
importance: Undecided → Medium
Oleg Endo (oleg.endo) wrote :

Sorry, I can't share my designs. However, the issue can be reproduced rather easily. See the attached test project. The resistors on both sheets are supposed to be connected together, but now they aren't anymore because the net names of the bus signals are not treated as global anymore. The fact that the bus itself is global is not passed on to the bus signals.

Perhaps this is just a bug in the new connectivity thingy after all? I've seen it doing weird things in other places, too already...

Jon Evans (craftyjon) on 2019-04-03
Changed in kicad:
status: New → Triaged
Jon Evans (craftyjon) on 2019-04-04
Changed in kicad:
status: Triaged → In Progress
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision d5990100e18fc2f409cd72477116951eb69c91eb

Changed in kicad:
status: In Progress → Fix Committed
Oleg Endo (oleg.endo) wrote :

Thanks for the quick response to this.

I've just tried the latest nightly build and the issue got better but it seems there are some leftovers.

The global bus signals on the first root schematic sheet (no prefix) are exported as "/D8" (for example), while the same bus signals on non-root schematic (with some sheet prefix) are exported as "D8". So for pcbnew those are different nets and they will be disconnected.

Oleg Endo (oleg.endo) wrote :

I've noticed that the problem does not occur in the test case I have provided. I've tried to reproduce it in isolation, but without success.

This is what I'm observing in a larger design:

Components on the same sheet connected to the same global bus signal will end up with different net names. Some of them will have no sheet prefix (e.g. "D8") while others will have the sheet prefix ("e.g. "/sheet/D8").

At first it looked like it had something to do with the root schematic sheet but it doesn't seem to be the case.

Changed in kicad:
status: Fix Committed → New
Jon Evans (craftyjon) wrote :

Can you please check again after bd487d2 -- I don't think this is related to your issue, but it will help rule some things out.

If you are still seeing the problem, please let me know if you figure out how to reduce your design that shows the issue to a test case that can be shared with me. Maybe you can describe the exact setup that causes the problem, or show me some cropped screenshots that show the bus / net definitions that are problematic but don't reveal your design too much?

Oleg Endo (oleg.endo) wrote :

Just checked the latest nightly build (d88df89). The issue is still there.

The designs are rather huge ... I can try to chop them but it looks like it's going to take hours...

The bus definitions are as shown in the screenshot above.

In another design the same issue exists but without a bus. Instead it happens with local power net that is an alias for a global power net. Well, at least to me from the outside it looks like it's the same issue. At first I thought I can reproduce it quickly in this test case, but after closing eeschema and updating the PCB again it went away.

Then I've noticed, in the other design updating the PCB from the schematic repeatedly causes always some (but not all) net names to toggle back and forth. It requires at least eeschema to be closed before updating the PCB (which will now always re-open eeschema .... ugh). Sometimes it happens only after closing both eeschema and pcbnew... not sure of those issues are related.

Jon Evans (craftyjon) wrote :

The last issue you mentioned is hopefully fixed by commit 94ba1bc

Oleg Endo (oleg.endo) wrote :

I was able to reduce the design and create a reproducer. Please see the attachment. Open the design, then update the PCB from the schematic -> some resistors will get dis/re-connected which is wrong.

Jon Evans (craftyjon) on 2019-04-09
Changed in kicad:
status: New → In Progress
Jon Evans (craftyjon) wrote :

I believe this is fixed in 49d8c29

Your test project now behaves the way I expect it to (since all the buses are global, they are all connected together). Importing into the PCB does cause some new connections to be added, since it looks like the state of the PCB at the beginning has some of the resistors connected to non-local buses.

Can you please check after tonight and advise if there are still any issues?

Changed in kicad:
status: In Progress → Fix Committed
Oleg Endo (oleg.endo) wrote :

I'm not on the latest 203019d.
The disconnection issue due to wrong global netname prefix seems to be gone.
However, now it mixes up netnames in the design (see attached screenshot) ... not sure what's with that ...

Oleg Endo (oleg.endo) wrote :

I can reproduce the issue of wrong netname juggling with the test case that I have provided in #11.

Oleg Endo (oleg.endo) wrote :

Problem is still there on nightly (2bcf38d)

Changed in kicad:
status: Fix Committed → In Progress

I cannot reproduce this issue with you test files kicad_bus2.

Oleg Endo (oleg.endo) wrote :

I have just re-downloaded the, opened it, hit "update PCB from schematic" in pcbnew and I get this log (which is obviously totally broken):

Reconnect R73 pin 2 from DL0 to D0.
Reconnect R69 pin 1 from D12 to DL6.
Reconnect R32 pin 2 from D15 to DL13.
Reconnect R72 pin 1 from D15 to DL13.
Reconnect R79 pin 2 from DL6 to D6.
Reconnect R9 pin 1 from /DL0 to D0.
Reconnect R71 pin 1 from D14 to DL7.
Reconnect R78 pin 2 from DL5 to D5.
Reconnect R80 pin 2 from DL7 to D7.
Reconnect R65 pin 1 from D8 to DL1.
Reconnect R66 pin 1 from D9 to DL15.
Reconnect R70 pin 1 from D13 to DL8.
Reconnect R76 pin 2 from DL3 to D3.
Reconnect R10 pin 2 from D1 to DL1.
Reconnect R67 pin 1 from D10 to DL14.
Reconnect R75 pin 2 from DL2 to D2.
Reconnect R68 pin 1 from D11 to DL9.
Reconnect R10 pin 1 from /DL1 to DL1.
Reconnect R26 pin 2 from D9 to DL15.
Reconnect R33 pin 2 from /D8 to DL1.
Reconnect R31 pin 2 from D14 to DL7.
Reconnect R34 pin 2 from /D9 to DL15.
Reconnect R35 pin 2 from /D10 to DL14.
Reconnect R30 pin 2 from D13 to DL8.
Reconnect R36 pin 2 from /D11 to DL9.
Reconnect R37 pin 2 from /D12 to DL6.
Reconnect R29 pin 2 from D12 to DL6.
Reconnect R38 pin 2 from /D13 to DL8.
Reconnect R39 pin 2 from /D14 to DL7.
Reconnect R28 pin 2 from D11 to DL9.
Reconnect R40 pin 2 from /D15 to DL13.
Reconnect R27 pin 2 from D10 to DL14.
Reconnect R42 pin 2 from /D1 to DL1.
Reconnect R43 pin 2 from /D2 to D2.
Reconnect R19 pin 1 from /DL2 to D2.
Reconnect R44 pin 2 from /D3 to D3.
Reconnect R45 pin 2 from /D4 to DL4.
Reconnect R25 pin 2 from D8 to DL1.
Reconnect R46 pin 2 from /D5 to D5.
Reconnect R47 pin 2 from /D6 to D6.
Reconnect R24 pin 1 from /DL7 to D7.
Reconnect R48 pin 2 from /D7 to D7.
Reconnect R23 pin 1 from /DL6 to D6.
Reconnect R50 pin 2 from D1 to DL1.
Reconnect R22 pin 1 from /DL5 to D5.
Reconnect R53 pin 2 from D4 to DL4.
Reconnect R21 pin 1 from /DL4 to DL4.
Reconnect R21 pin 2 from D4 to DL4.
Reconnect R20 pin 1 from /DL3 to D3.

Total warnings: 0, errors: 0.
Netlist update successful!

Application: kicad
Version: 5.1.0-unknown-2bcf38d~82~ubuntu18.04.1, release build
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-47-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.3.0 with C++ ABI 1011

Build settings:

Sorry, but the schematic is strange and must be fixed:
In sheet bleh, @ 566, 487 mm, I am seeing the bus D[15..0] connected to members DL0 to DL15.

Please, first fix your schematic, it fixes most of errors.
(currently, ERC shows 66 errors)

However, with this incorrect connection, a error like:
"Reconnect R71 pin 1 from D14 to DL7."
should certainly not happen.

Oleg Endo (oleg.endo) wrote :

Right, that D[15..0] connected to DL0 .. DL15 is a mistake, also in the original design. It went unnoticed for years because it always worked.

OK, so deleting this whole section still results in totally wrong connections:

Reconnect R72 pin 1 from D15 to D7.
Reconnect R76 pin 2 from DL3 to D8.
Reconnect R80 pin 2 from DL7 to D12.
Reconnect R75 pin 2 from DL2 to D15.
Reconnect R74 pin 2 from DL1 to D10.
Reconnect R71 pin 1 from D14 to D6.
Reconnect R70 pin 1 from D13 to D5.

And the ERC errors only complain about unconnected stuff, which should not matter at all in this case.

Jon Evans (craftyjon) wrote :

I think this is fixed by
Please re-open if you see further issues

Changed in kicad:
status: In Progress → Fix Committed
Oleg Endo (oleg.endo) wrote :

Looks OK now. Thanks a lot!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers