Large Quantity Signal Routing

[itsko]

I am struggling to determine an acceptable method to bus large quantities of similar signals. I was advised to flatten, but even here, I ran into issues … but maybe they’re not issues?

Concept

I am using hierarchal blocks to bus RGB LEDs within 7-segment digits within a matrix of digits.

Originally, I:

• Bussed and aliased the RGB LED {rgb_0}
  • Added unique titles one level up (top, mid, bottom, etc).
• Bussed and aliased the unique RGB LED busses {digit_0} within the 7-segment digit
  • Added unique titles one level up (digit_1_1, digit_1_2, …).
• Bussed all of the digits within the digit matrix {digits_0}.
  • Passed the {digits_0} to the LED Driver one level up.

All aliases were created at the Root level of the Schematic Hierarchy for simplicity. (Does this cause any concern for issues?)

I learned that I could not nest a bus within a bus and was advised to flatten. So I did, depicted further below. I:

• Titled the signals of {rgb_0}.
  • Atomically passed the signals of {rgb_0} one level up.
• Titled, bussed, and aliased the unique RGB LED signals {digit_0} within the 7-segment digit.
  • Passed the {digit_0} bus one level up.
• Titled the unique {digit_0} busses (digit_1_1, digit_1_2, …)
  • Atomically passed the unique {digit_0} busses to the LED Driver on the same sheet.

Figures

RGB LED:

7-segment (plus dot pixel):

Matrix of Digits:

Digit Driver:

[Digit Driver Out] to [RGB LED In] Routing:

[RGB LED Out] to [Digit Driver In] Routing:

Bus Alias: {digit_0}:

Issues

Net Is Graphically Connected To Bus, But Is Not A Member

I don’t know what to make of the numerous errors here:

Net <netName> is graphically connected to bus <busName> but is not a member of that bus.

Is this similar to Nets With Multiple Labels and can be handwaived as a warning:

[mf_ibfeew]

error “Net is graphically connected to bus but is not a member of that bus.”

This should be taken serious, as this is normally a connection error. With this error the objected net is not connected to the bus-wire (and therefore not connected to other places of that bus).

While “Nets With Multiple Labels”-warning depends on the user-workflow.
Some users (me included) work with multiple names on the same net, so these users can/should ignore this warning.
Some users work with more discipline and place only one label per net - for these users the “multiple label”-warning is also useful.

With the big deep bus-structure I can’t help. I have also not seen many examples with such deep busses on the forum, so I guess you have to build up this knowledge yourself.
The good thing: after that you are the forum expert for structured busses.

[itsko]

Okay, that’s great to know … but this is in no way a deep bus structure.

In the depicted example, 32x (8x4) busses with unique titles, each containing 48x (8x6) unique nets are expanded to connect with each other.

Despite the large numbers, I feel that at this level of simplicity, I am unsure what the issue is with these busses. If I cannot do what I am presently doing after flattening, what good are busses?

[mf_ibfeew]

32x (8x4) busses with unique titles, each containing 48x (8x6) unique nets

this should work (in principle).

could you attach the project?
Or a cutdown-version with only 1 of these busses? But it should contain the complete subsheet-hierarchy which you have build.
From the pictures alone I’m overwhelmed and can’t help.

[itsko]

itsko_example.zip (549.8 KB)

[mf_ibfeew]

At a first glance I think that the connection is correct, and that the ERC-warning is either a false-positive or a bug. Checking and thinking in another ones schematic needs always some time.
Maybe I look tomoroow again and try to create a example which is suitable for gitlab.

For the connectivity-check I have used the highlight function.
The better way is to use the pcb-editor in parallel to the schematic and compare if the wanted led-pads or connected together.
If your schematic+board completes this test then you can carry on. I think in principle the drawing should work.

Last (unwanted) advice: if I start to draw such a big schematic I start with few bus members (1…4, in your case 6 for top-led would be reasonable) and with only few sub-schematics (say 2 digits). With this I check if the principle drawing is working. After that I draw the missing digits 3…48 with much more confidence (but usually also with intermediate steps), and if then a unexpected drc-error occurs I’m sure it’s not the drawing-principle.

[itsko]

On that last bit :

I know, I know — but it WAS simple to start when I nested a bus within a bus digits{digit_0{rbg_0}}.

It got complicated when my assumed functionalities weren’t present … for which I am still at fault. But the benefits of nested bus hierarchies significantly compliment nested schematic hierarchies.

So then I learned about not using hierarchal labels as local labels (by not importing the pin on the next level up) … despite the improved appearance. But that wasn’t fully it.
So then I learned about bus aliases. But that wasn’t fully it.
So then I learned about the lack of nested bus functionality. But that wasn’t fully it.

And having switched to local labels and filing bug reports for the bus alias menu and flattening my schematic some … it turned out to be anything but straightforward and I still haven’t fully gotten it XD

[paulvdh]

That is a lot of LEDs.

Am I correct in assuming it has 32 7-segment displays, and each segment of each display is a single RGB led?

That would be: 32*(7+1)32 = 1536 connections for just the LED’s.

Your segment numbering is … unusual. Normally the segments are labeled A though G (and probably H for the dot).

A schematic with so much repetition is a good candidate for SKiDL. SKiDL is a python library to generate a netlist for KiCad’s PCB editor. It’s a sort of VHDL equivalent for schematics. I’m not sure if it’s still kept up to date. Last time I checked was a few KiCad versions ago…

I am also confused a bit with the amount of nested levels.
I see the big 7-segment display, and it has sub sheets for each single LED.
Is there a purpose for this? (Maybe putting several LED’s in series?)

[paulvdh]

I have been toying a bit with your schematic.
I get completely confused by all your labels, so I thought up another way.

You have a single label from the LED driver, for example “R0”, and then you distribute that to a whole lot of other labels. I have turned that around. I removed all the complicated label names (the’re still there yet for temporary reference) and then I just make a lot of duplicates of the “Red0” label, and paste it wherever it’s needed.

This way you don’t need all those complicated label names, but you just re-use a few labels a lot and that is easy duplicate and place (or copy & paste if you like).

I also redrew some other things.
The “left - right” and “top bottom” also is *&^%$#@! to my brain, so I labeled the segments A through H (common practice for 7-segment displays) “A” is always the top, and then you label the segments clockwise.

This is how I made the Hierarchical sheet for a single digit:

I also prepared some simple blocks for you to duplicate and place:

And I changed some other small things.
As with all other Open Sourced stuff. No guarantee that it is fit for work or will work at all.
But everything is simple rows, and easy to check.

countCube_small_2023-08-07.zip (221.9 KB)

I was thinking of adding another hierarchy layer.
The Idea is to make a sheet with either a row or a column of the whole 7-segment display, and then re-use that sheet 4 times (if it is a row) or 8 times (if it is a column). But I am not sure if this helps a lot. Now it is simply copy & paste on a single sheet and that is pretty quick to do.

Oh, one other thing.
If you zip up a project, you do not have to zip up the backup directory too. That saves about half the size of the zip archive (or more if there are multiple backups in the backup directory).

[itsko]

@paulvdh

I see the big 7-segment display, and it has sub sheets for each single LED.
Is there a purpose for this? (Maybe putting several LED’s in series?)

It allowed me to:

• Shrink the RGB symbol to fit the digit (without changing to Portrait).
• Display a more intuitive pinout … without making the actual device pinout inaccessible.
• Expose that pretty much every action in KiCad expands the entire Schematic Hierarchy…

without any harmful effects.

@paulvdh

A schematic with so much repetition is a good candidate for SKiDL.

I will look into this. If I understand correctly, I can continue on in KiCad and use SKiDL when it comes time to focus on layout?

@paulvdh

I’m not sure if it’s still kept up to date. Last time I checked was a few KiCad versions ago…

Oof. (You tease.) My fingers are crossed.

@paulvdh

all those complicated label names […] The “left - right” and “top bottom” also is *&^%$#@! to my brain, so I labeled the segments A through H (common practice for 7-segment displays)

The A-G (+DP) format is standard … but requires prior knowledge or cross-referencing to a legend.

Direct definitions removes masked jargon for accessibility to any reader at the cheap cost of some added characters. I would say that it is no more complicated. I could also just prepend each segment label with the corresponding A-G (+DP or H) for a best of both worlds.

@paulvdh

This is how I made the Hierarchical sheet for a single digit:
[Helpful image]
I also prepared some simple blocks for you to duplicate and place:
[Helpful image]

This is quite nice. I’ll probably keep my descriptive pin names and R#B#G# and Line# to them as you have suggested … because I have to … because the bus is not permissible for whatever reason.

But that makes the answer: Just don’t use busses.

Why is KiCad offering busses, a productivity feature, for which the consistent advice on these forums has been to simply remove more and more them (now completely).

I want to be able to umbrella unique parent titles over arrayed templates of grouped signals, and then further group those (with a prepended parent label and so on) before moving them about the schematic as I please, not form flatten in direct opposition to what schematic hierarchy ostensibly makes possible because I shouldn’t group signals.

In what we’re discussing, we’re simply using the hierarchal labels as signal to bus transitions, and the hierarchal block as the bus … but no longer existing is the ability to umbrella a unique parent label associating the signals of a specific hierarchal block without manually labelling each individual signal … and even then, I think we’ve learned here not to multiname the nets.

I can agree that your method is visually descriptive if I flatten the driver into the same block as the arrays. But why is use of bus a wrong method rather than an alternative one? Shouldn’t they both be functional, independent of whether one or the other is better?

(I’m going to redraw the schematic again, but I feel like KiCad here is imposing a particular method as correct despite it not being intuitive as the one and only correct method.)

[paulvdh]

Yeah, that folding out of all the sheets is a bit of an annoyance. I consider it a bug that will get fixed some day. It’s probably not encountered much because it’s rare to use a hierarchy so extensively.

@itsko

• Shrink the RGB symbol to fit the digit (without changing to Portrait).

I would just redraw or edit the LED symbol, similar as I did with the LED driver IC. I have a huge dislike for schematic symbols that have pins in the same location as the IC. You have to look at it three times to be sure you don’t connect a LED upside down. Grouping pins by function is much more common and logical.

@itsko

I will look into SKiDL. If I understand correctly, I can continue on in KiCad and use SKiDL when it comes time to focus on layout?

No. SKiDL is an alternative for the schematic part only. It creates the netlist, and then you do the rest in the PCB editor as usual.

@itsko

I can agree that your method is visually descriptive if I flatten the driver into the same block as the arrays. But why is use of bus a wrong method rather than an alternative one? Shouldn’t they both be functional, independent of whether one or the other is better?

I’m not saying that the way I did it is the way it should be done. It is just the way that seemed logical to me. Somehow you have to strike a balance between what humans find intuitive, and the functions the tools provide. I prefer a visual approach, where you can see where signals are going. Your nested buses may have worked nicely if it was supported, but after the method failed it turned into something … I find confusing (It’s a gap in my brain, I have this more often). I also do not have much experience with vector buses in KiCad. I usually draw quite small PCB’s. “Your method” also probably seems logical to you because, well you invented it, and you’ve been looking at your own schematic a long time. I do wonder what @mf_ibfeew thinks of my alternative version. There may be other “better” ways too.

Also, until recently a vector bus just did not exist yet in Kicad. Basically everything was connected with labels and the blue buses were only a visual thing with no content whatsoever. I It’s quite possible that nested vector buses become a thing in some future KiCad version, but I’m not a KiCad developer and am just guessing.

---

On a sidenote, KiCad has a plugin called “Replicate Layout”, and this is a quite big feature for repetitive projects, but it does require effective use of hierarchical sheets. The method of working is:

1. Create the right sort of hierarchical schematic.
2. Layout the PCB for one sheet in the hierarchy.
3. Place one “reference footprint” from each of the other hierarchical sheets.
4. Run the plugin.

The plugin then replicates the layout of your reference sheet to all the locations of all those other reference footprints. In your particular case the amount of work it can do for you is unfortunately quite limited, because you have only one IC that multiplexes all the LED’s. But you can use the replicate layout plugin to put all the LED’s in the right locations relative to each other. I do not know if it works with such a deep nested hierarchy.

Projects as big and complex as this are a bad way to experiment with KiCad. You do not know how to do things in advance, and each mistake you make or want to do differently later, requires a lot of repetitive work to fix.

One thing for example:
All the cathodes for a single 7-segment display could probably have been put one hierarchy level lower, and then just bring out one pin into the upper hierarchical sheets, instead of 24 for all the cathodes of all the LED’s. Realizing such things takes planning in advance (and experience). Unfortunately, experience is something you gain only after you needed it.

[MitjaN]

I didn’t look at the project schematic, so I can not really comment on specifics, but for placement of the parts there is a Place Footprints plugin. The plugin places the footprints either by their reference number, or by the hierarchical sheet. The plugin works well in tandem with the Replicate Layout plugin. You first take the Place Footprints plugin and place the “anchor” footprints. Than you lay out one sheet and then you replicate the layout with the Replicate Layout plugin.

Both plugins work with nested hierarchies so you run them first in the nested sheets and then on the parent sheets if needed.

But I suspect that plugins might have issues if the schematics part is done via Skidl and hierarchy is nested and parent sheets contain only child sheets without any footprints. In this case the plugins parse schematics files to figure out the schematics hierarchy. But I do remember that there were users who ran the plugin using Skidl. They probably used only one level deep hierarchy.

[itsko]

@paulvdh

Also, until recently a vector bus just did not exist yet in Kicad. Basically everything was connected with labels and the blue buses were only a visual thing with no content whatsoever. I It’s quite possible that nested vector buses become a thing in some future KiCad version

Nested vector busses sure, my criticism lied with even standard busses (consisting only of signals) not having functioned without issue.

@MitjaN

there is a Place Footprints plugin. The plugin places the footprints either by their reference number, or by the hierarchical sheet. The plugin works well in tandem with the Replicate Layout plugin.

All the plugins!

[itsko]

@paulvdh

This is how I made the Hierarchical sheet for a single digit:

Alright, Paul —

It’s quite lovely.

[paulvdh]

I thought so.
Glad that you like it though and thanks for the feedback.

Instead of making… 8432*2 = 2048 labels with subtle small differences you just have the “Red”, “Green”, “Blue” and “Line” labels (all with numbers, which “auto increment”) And after that it’s just Copy and paste. It’s just much more robust.

Remembering all those old labels with multiple numbering schemes in each label is very error prone.

Also, the reason why I wrote out “Red”, “Green” and “Blue” was because to avoid any confusion (both human and computer) with the A through H labeled segments. Both Blue and Green are in those first 8 letters. And even though they are local labels and on different sub sheets. I am a sucker for redundancy because it adds robustness.

And if you combine all the Cathodes (I only realized later they were all common) one sub sheet lower, you can halve the size of all those sub sheet symbols.

[mf_ibfeew]

I have slightly modified (more explanation, fewer parts) the original project and opened a gitlab issue. I think the ERC-warnings are false-positive and should not be shown.

The overhauled version from paul also looks good - much cleaner (at first glance).

Last remark for the original schematic: naming nets as +/- (top_r+/top_r-) is a bad idea. the plus/minus marking is a internal sign for differential pairs. So your nets suddenly don’t belong to normal netclasses, but to differential pair netclasses.

Edit: false positive ERC-test (#15375) · Issues · KiCad / KiCad Source Code / kicad · GitLab

Edit2: and another issue found with this project (and already fixed): bus alias dialog: active row not marked (#15374) · Issues · KiCad / KiCad Source Code / kicad · GitLab

[paulvdh]

@itsko This project of yours generates quite a stir.

• Just now mf_ibfeew created a gitlab issue for the false positive ERC warnings.
  @mf_ibfeew, notice that itsko also started a topic about the + / - labels a few weeks ago:
  Bus - Cannot Use `{+ -}`
• I created a separate thread on this forum for the slowing down issue, and it’s being worked upon: Schematic editor is very slow on large schematic - #15 by craftyjon
• Just looked into your text rotation thing a bit.
• The nested hierarchy thing… I don’t now if that will go anywhere (yet).

[devbisme]

I’m late to this party, but I just thought I’d drop a SKiDL version of the LED digit design:

from skidl import *

# We'll be using the new KiCad 7 today!
set_default_tool(KICAD7)

@subcircuit
def digits_4x8(sclk, sin, sout, vcc, gnd, vr, vg, vb, iref):
    """4x8 array of digits + controller."""

    @subcircuit
    def digit(digit_num, r, g, b, cathode):
        """8-seg LED digit connects to 8-bit R, G, B buses and a single cathode net."""

        # Create a template for the RGB LED and assign functional aliases to its pins.
        led_t = PartTmplt("a0_library/LED/0_LED", "OSRAM_LRTBGVSR", footprint="0_LED:OSRAM_LRTBGVSR")
        led_t["A1"].aliases += "G"
        led_t["A2"].aliases += "R"
        led_t["A3"].aliases += "B"

        # Instantiate an LED for each segment of the digit.
        led_top, led_mid, led_bot, led_l1, led_l2, led_r1, led_r2, led_dot = led_t * 8

        # Give each LED a reference that reflects the position of its segment.
        base_ref = f"DIG_{digit_num}_"
        led_top.ref = base_ref + "top"
        led_mid.ref = base_ref + "mid"
        led_bot.ref = base_ref + "bot"
        led_l1.ref = base_ref + "l1"
        led_l2.ref = base_ref + "l2"
        led_r1.ref = base_ref + "r1"
        led_r2.ref = base_ref + "r2"
        led_dot.ref = base_ref + "dot"

        # Create a 3-bit cathode bus to connect to cathode pins of each LED.
        cathode_bus = Bus(cathode, cathode, cathode)

        # Connect each LED to a bit of the RGB buses and the cathode.
        led_top["R, G, B, C[1:3]"] += r[0], g[0], b[0], cathode_bus
        led_l1["R, G, B, C[1:3]"]  += r[1], g[1], b[1], cathode_bus
        led_r1["R, G, B, C[1:3]"]  += r[2], g[2], b[2], cathode_bus
        led_mid["R, G, B, C[1:3]"] += r[3], g[3], b[3], cathode_bus
        led_l2["R, G, B, C[1:3]"]  += r[4], g[4], b[4], cathode_bus
        led_r2["R, G, B, C[1:3]"]  += r[5], g[5], b[5], cathode_bus
        led_bot["R, G, B, C[1:3]"] += r[6], g[6], b[6], cathode_bus
        led_dot["R, G, B, C[1:3]"] += r[7], g[7], b[7], cathode_bus

    # Instantiate the LED controller chip.
    led_drv = Part("a0_library/LED_driver/0_LED_driver", "TI_TLC6983RRFR", footprint="0_LED_driver:TI_TLC6983RRFR")

    # Collect the LED driver pins into arrays.
    line = Bus("line", led_drv["line[0:15]"])
    red = Bus("red", led_drv["R[0:15]"])
    grn = Bus("grn", led_drv["G[0:15]"])
    blu = Bus("blu", led_drv["B[0:15]"])

    # Now instantiate a 4x8 array of LED digits and connect them to the controller pins.
    for row in range(0,4):
        for col in range(0,8):

            # Label each LED reference with its row and column number.
            digit_num = f"{row+1}_{col+1}"

            # LED cathode line index: 0, 0, 1, 1, 2, 2, ... 14, 14, 15, 15.
            line_idx = (8 * row + col) // 2

            if col % 2:
                # Odd column, so use upper byte of RGB buses.
                lo, hi = 8, 15
            else:
                # Even column, so use lower byte of RGB buses.
                lo, hi = 0, 7

            # Instantiate the digit and connect it to the upper or lower RGB bits.
            digit(digit_num, red[lo:hi], grn[lo:hi], blu[lo:hi], line[line_idx])

    # Connect the rest of the LED controller pins.
    led_drv.SCLK += sclk
    led_drv.SIN += sin
    led_drv.SOUT += sout
    led_drv.VCC += vcc
    led_drv.GND += gnd
    led_drv.VR += vr
    led_drv.VG += vg
    led_drv.VB += vb
    led_drv.IREF += iref


# Finally, instantiate the entire 4x8 LED digit module!
digits_4x8(Net("sclk"), Net("sin"), Net("sout"), Net("vcc"), Net("gnd"), Net("vr"), Net("vg"), Net("vb"), Net("iref"))

# Now generate the netlist for input to PCBNEW.
ERC() # Check for errors.
generate_netlist()

Overall, though, I like the approach @paulvdh took: generate two-digits connected to the RGB buses, copy-paste those 16 times, and then change the line connection on 15 of the replicas.

[Rabbit]

SKiDL rocks!

Programming makes life easier