KiCad 6 schematic and reused sub-sheets, trying to understand the limitations

Schematic
1

Hi!

I’m trying to figure out some details and limitations of the new schematic format.

Context: I’m implementing the variants mechanism of KiBot for KiCad v6, and as the Python bindings for EEschema won’t be in v6 I have to understand the file format.

My main doubts are about what happends when a project uses a sheet more than once.

From what I see the only thing that I can change is the components annotation, all other details are shared, which seems confusing. Let me explain:

The example I used

In my example we have a main sheet called pp.kicad_sch that contains two instances of a sub-sheet called subsheet.kicad_sch. The sub-sheet contains just a resistor.

image
image3507×2480 88.9 KB

image
image3507×2480 78.6 KB

image
image3507×2480 78.9 KB

The first instance is:

  (sheet (at 101.6 50.8) (size 25.4 12.7) (fields_autoplaced)
    (stroke (width 0.1524) (type solid) (color 0 0 0 0))
    (fill (color 0 0 0 0.0000))
    (uuid f2044410-03ac-4994-9652-9e5f480320f0)
    (property "Sheet name" "Sheet_1" (id 0) (at 101.6 50.0884 0)
      (effects (font (size 1.27 1.27)) (justify left bottom))
    )
    (property "Sheet file" "subsheet.kicad_sch" (id 1) (at 101.6 64.0846 0)
      (effects (font (size 1.27 1.27)) (justify left top))
    )
  )

With UUID f2044410-03ac-4994-9652-9e5f480320f0

The second instance of the sub-sheet looks like this:

  (sheet (at 101.6 76.2) (size 25.4 12.7) (fields_autoplaced)
    (stroke (width 0.1524) (type solid) (color 0 0 0 0))
    (fill (color 0 0 0 0.0000))
    (uuid 6bfab902-8625-4b2e-8c24-5092d47d0de8)
    (property "Sheet name" "Sheet_2" (id 0) (at 101.6 75.4884 0)
      (effects (font (size 1.27 1.27)) (justify left bottom))
    )
    (property "Sheet file" "subsheet.kicad_sch" (id 1) (at 101.6 89.4846 0)
      (effects (font (size 1.27 1.27)) (justify left top))
    )
  )

Its UUID is 6bfab902-8625-4b2e-8c24-5092d47d0de8

KiCad 6 improves the sheet numbering by defining the numbers in the main sheet like this:

  (sheet_instances
    (path "/" (page "1"))
    (path "/f2044410-03ac-4994-9652-9e5f480320f0" (page "2"))
    (path "/6bfab902-8625-4b2e-8c24-5092d47d0de8" (page "3"))
  )

This is clear and solves the old problem about page numbers. The first instance is page 2 and the second is page 3. Good.

The symbol instances are declared like this:

  (symbol_instances
    (path "/f2044410-03ac-4994-9652-9e5f480320f0/c3f25bab-d21c-43b9-bb4f-57d9b5e2645a"
      (reference "R1") (unit 1) (value "220") (footprint "Resistor_SMD:R_0603_1608Metric")
    )
    (path "/6bfab902-8625-4b2e-8c24-5092d47d0de8/c3f25bab-d21c-43b9-bb4f-57d9b5e2645a"
      (reference "R2") (unit 1) (value "220") (footprint "Resistor_SMD:R_0603_1608Metric")
    )
  )

Ok, the UUID c3f25bab-d21c-43b9-bb4f-57d9b5e2645a is the resistor symbol that I have in sub-sheet.kicad_sch. Looking there I have:

  (symbol (lib_id "Device:R") (at 116.84 55.88 0)
    (in_bom yes) (on_board yes) (fields_autoplaced)
    (uuid c3f25bab-d21c-43b9-bb4f-57d9b5e2645a)
    (property "Reference" "R1" (id 0) (at 118.618 54.9715 0)
      (effects (font (size 1.27 1.27)) (justify left))
    )
    (property "Value" "220" (id 1) (at 118.618 57.7466 0)
      (effects (font (size 1.27 1.27)) (justify left))
    )
    (property "Footprint" "Resistor_SMD:R_0603_1608Metric" (id 2) (at 115.062 55.88 90)
      (effects (font (size 1.27 1.27)) hide)
    )
    (property "Datasheet" "~" (id 3) (at 116.84 55.88 0)
      (effects (font (size 1.27 1.27)) hide)
    )
    (property "mnf#" "4567" (id 4) (at 116.84 55.88 0)
      (effects (font (size 1.27 1.27)) hide)
    )
    (pin "1" (uuid d7abc30b-0879-4741-86ef-a26cf4381a4c))
    (pin "2" (uuid c7f74e02-22a2-44c3-ba93-2cb4738b7c33))
  )

This is an instance of the library symbol Device:R (also included in subsheet.kicad_sch)

The confusing part

Looking at the symbol instance I can see the following attributes:

  • Reference
  • Value
  • Footprint
  • Unit

First doubt

I can’t find a mechanism in the UI to change Value and/or Footprint for one instance without affecting the other. Only the Reference can be modified.
This looks like a severe limitation in the UI, or a waste in the file format. Can somebody explain me this?

Second doubt

The Reference, Value and Footprint are in fact properties. Why are they handled in such a different way in the instance? Isn’t much more generic to just add property attributes to symbol_instances.path? In this way we could change other details. If Value and/or Footprint are part of the instance (or will be in the future) then other properties will need to be there, starting with the Datasheet and any user field that describes the manufacturer part number.

Third doubt

Having the Unit as part of the instance looks quite dangerous. Different units could have very different representation and/or pin-out. I don’t see we can change this attribute for each instance.
On the other side: why things like in_bom and on_board aren’t part of the instance? This looks quite plausible.

I’m not claiming the format is wrongly designed, just looking to remove my doubts.

2

Here’s a real subsheet to illustrate the effect of the attributes you listed, instead of looking at the format in isolation:

fff

Take the 74LS02. The reference is U20. That would have to be editable for other instances if there are more than 4 subsheets used. The unit C, would also have to be editable for other instances, otherwise you would only be able to use one gate per package. The value is 74LS02. If you were able to change that it would be misleadingly look like a different IC on the schematic. And the footprint goes with the IC.

Does that help?

1 Like
3

A little bit, thanks, but not enough. It explains why unit is there, but generates more doubts.

Take as example the R, Why changing the value will generate any problem? In fact this is quite common, you have a sub-sheet that is a complex filter that you use over and over in your design, but not always with the same values. And also: changing the 74L02 to 74L04 will be confusing, of course, but this doesn’t have anything to do with multiple instances, doing it in a single sheet will be also confusing :wink: But now think about this: one instance uses 74L02, but another uses 74S02.

I tried a 7402 as you suggest and the result was even worst. I was able to assign U1A to both instances, and even worst assign U1A to one and U1E to the other!!! The unit E is the power section!! KiCad isn’t helping here at all. And you can easilly get a confusing drawing. Ok, I guess the ERC will catch these inconsistencies. But it doesn’t help me to understand why value and footprint are in the instance, or why datasheet isn’t or why we don’t just have properties there.

Thanks again for your effort.

4

This has been remarked on in another thread. Unfortunately manual editing is still necessary.

I would say that the hierarchical sheet concept is not fully evolved. There are many situations where could work better. Parameters as you have pointed out is one aspect. So the format is also a work-in-progress and shouldn’t be regarded as definitive. Probably by KiCad v12, it will be totally unrecognisable compared to now. But how to get there and what the UI will look like, well that remains to be seen.

Just adding that I’m not a dev, so these are just my opinions.

Edit: Just want to add that I think it’s really the code you should look at, not the data format. If you think of the schematic format as a language, then the language generally allows you to express things that are nonsense, which is true in both human and computer languages. The semantics expressed in the program constrain what is actually generated.

1 Like
5

Many years ago (30 ish) I used a program called Protel. It did much as you comment on. It would only allow one instance of say U1A or U1E. This seems good UNTIL you try to make a board. As soon as you swaped gates to improve track layout then returned to the schematic to make alterations, gates had to be first deleted from where they were, then re-installed to place in a new position on a sheet.
Back in the day it was a nightmare changing gates on the schematics to match the board.

If I was designing with gates these days I would be extremely thankful for the Kicad system… a vast improvement on yesteryear.

6

Further to my above comments:
5 was easy, just re-annotate and mirror all the gates if necessary.
6, you just hit the re-annotate “PCB back to Schematic” button… all done.

7

Naturally the reference is different in all sheet instances. In v5 other properties couldn’t be changed at all. In v6 text replacement variables can be used for this. Open the sheet instance properties, add a field and use it as a variable, like ${component_value}. I think changing the component value (e.g. resistance) is the most common use case, it can be used for “channels” where the schematic and the layout is identical but the component has different value.

This doesn’t allow changing the component, i.e. footprint or symbol name can’t be changed. I don’t remember if changing the footprint is in the wishlist, but in any case it probably would not be as simple as changing text items if we think about implementation and possible side effects which have to be taken care of.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.