A properly managed project

[ppTRN]

Hi everyone,
I've been using KiCad for a good part of a year now, but only for relatively simple 2 or 4 layer board that did not contain any particular high speed signal, just USB at most.
Now I am facing a more complex challenge, the design of a System on board with an NXP cpu. I will for the first time have to route complex tracks managing skews, impedence and differential pairs.
Not that big of a deal form a theoretical point of view, but I feel like that in order to start this project as good as possible I should know more precisely some KiCad tools that I did not really considered up until now.

1. Hyerarchical schematic sheets: Never used them, should be easy to manage bu how are they connected between them? Labels? Global labels?
2. Net Classes: should I pose more attention to this? Should I define different net classes in my schemati in order to have a tidy design that will help me route the pcb? How important is this?
3. Skew tuning: never done it;
4. Differential pair: last time I did it I did it "by hand" for a very short usb IC to connector connection. I am sure there is another way;

And the most important point:

5. Suggestions from your own personal experience;

I am sure that I can find tutorials on the topics above but if you have any specific resource that can short my researches please feel free to comment

[Smokey]

High speed design principles are the same no matter what tool you are using.  That's the stuff to understand first, then see how much of that the tool will help you with.  But without knowing what the "right" way is, you can't confirm the tool did a good job.

I know that's not the answer you were looking for. 

[Doctorandus_P]

• KiCad has a quite nice system for hierarchical sheets. Hierarchical sheets have their own hierarchical label type to make connections though the hierarchy. But do note that different label types connect to each other when they have the same name and are on the same page. This is by design. KiCad also has the Replicate Layout plugin which is extremely nice if you have multiple repetitions of a part of your circuit.
• Yes. Net classes are important. They are very convenient to divide your project into thin PCB tracks for signals, and thicker tracks for power distribution. A netclass controls track width, track clearance, and differential pair settings, and you can make as many as you need. Definitely worth learning.
• KiCad does have some built in tools for differential pairs and length tuning. This is length tuning, and not real delay matching, so to keep it simple, keep bundles of tracks that need delay matching on similar layers so their delay properties are the same. KiCad has some basic tools for these and I do not use them much myself, but just as other parts of KiCad, they are being improved with each KiCad version. In KiCad V8 I noticed that adding the serpentine tracks for the length matching are much easier to control then in previous KiCad versions. But my knowledge is limited because I have not really used it myself.
• See 3.
• Suggestions: Read the manuals and experiment with some simple test projects to make sure you understand how the tools work before you take on a big design. If you don't understand the capabilities and limitations of the tools, then it is easy to make mistakes, and these can become very time consuming on bigger projects. With a small test project, you just delete the whole thing and start over when you discovered you did things wrong.

[Benta]

The most basic fhing with EDA tools: they need design discipline, no matter if it's KiCad, Eagle, whatever.

You sound a bit like "who needs a schematic, let me just get the PCB done!" (sorry if I'm wrong).
The basis for a design is getting your libraries right, then getting your schematic right.
THEN you can start thinking about your PCB.
Boring and tedious, I know. But it'll save you tons of time later when optimising and debugging. It's time well spent.
The main forum is forum.kicad.info, where the developers also contribute.
Good Luck.

[WillTurner]

  I have a few heuristics regarding (only) hierarchical sheets, local and global labels that might be useful. Note however, that I am working on my own, not as a part of a team, and so have been free to develop my own approach and style.
  All schematic symbols and connections reside on a sheet, the "home" sheet if nothing else. So placing sub-sheets on the "home" sheet and then below creates a hierarchy somewhat like a file tree. I rarely use any tools to navigate the tree now, apart from double clicking on a sheet to go down, and the icon  in the top bar that takes us up one level.
  Usually the first step in adding a sub-circuit to the schematic is to create or copy a sheet. On the first edit of a sheet, you have the opportunity to select a filename for the schematic, and a title. These are important. Choose a filename wisely, especially if copying sheets. Go back to a terminal and look at the existing filenames. Have a naming convention, and a version number tagged onto the filename. Copying existing sheets can create havoc if symbols are duplicated. It is worth going back and forth between an old sheet, and its copy until you are confident that they are completely separate entities.
  I rarely use global symbols, the main one being a top-level ground.
  Everything else gets passed as a list.
  On each sub-sheet, I make all circuit connections using local labels. My convention is to use a two part name, say "jones_+Vs". If I copied this sheet, in the copy I would then edit each of these labels to correspond with the new sheet name, for example "dallas_+Vs". Keep the first part as simple as possible without too much punctuation. Then you can select the field by double clicking. Punctuation is problematic here - it is more difficult to select.
  Within each sub-sheet create a list of hierarchical labels each connected to a local label. The local label as the name implies, is used locally. The hierarchical label is passed up the hierarchy by going up one level to the sheet icon, selecting the tool that pulls up labels, and repeatedly pulling up labels until there are none left.
  So on a sub-sheet, the list of hierarchical to local labels is the "interface" to the sub-circuit. It is often useful to arrange the list in a compact, ordered way. You can then copy the whole block - the "interface", and use it higher up in the hierarchy.
  Often the interface is copied (with the same names) all the way up and down the hierarchy of sheets. So for example, when bringing up the interface, it might be copied, go up one level, pasted, then the hierarchical labels deleted leaving a nicely organized list of local symbols to connect to when bring up the lower level symbols.
  One last tip - create a bold title block for each sub-sheet, and I also create a text block of notes. The sheet title is a visible indicator of which sheet you are currently working on. Remember the sheet has a title field? Copy the title block name into the title field.
  Expect workflow changes as your project uses more abstractions. Tasks I did as a KiCad beginner are often completed in a different order now.
  One of the really nice things about working with KiCad is working outside of the GUI. I don't edit schematics much by hand, but I no longer use the footprint editor except for rudimentary tasks, using a simple text editor instead.
  Good luck, develop your own style and have fun.   

Edits: Firstly for grammar.
Secondly, to add :
  Your design will start off simply, and progress as you become familiar with the tools. Always use the DRC tools to ensure that you can get to a state with no errors, a "manufacturable" comfort zone so to speak. If you encounter some kind of unfathomable error, don't forget that you can move back and forth between schematic and layout representations.

[xvr]

Just one note for hierarchical sheets: If you need many copies of some block - put it on hierarchical sheet once. You don't need to physically copy sheet files, KiCAD can reuse the same file for multiple instances of hierarchical sheet.
You need to duplicate physical sheet file only if you plan to create some derived circuit and this copy will be edited independently.

[bson]

I'd strongly recommend hierarchical sheets, hierarchical labels (on the sheet schematic) and hierarchical pins (inside the sheet box on the parent sheet). Combine this with buses, which now have labels to identify their signals.  For example, "{ D[0..7], A[0..3], ~{RD}, ~{WR} }" as a simple example.  You can mouse onto the bus and hit 'c' to get a popup of bus signals, pick one and start drawing its wire; KiCAD populates the bus connector and label for the signal and you just draw the wire to where it goes.  Buses can go to hierarchical labels and pins to enter/exit child sheets.  This is a GREAT feature if you have a bunch of buses, really streamlines things and reduces potential errors like label tpyos.  If you use a bus designation like the example previously for a hierarchical label, if you draw bus from it KiCAD derives a bus manifest from it automagically.

[nctnico]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

[tggzzz]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

The same could be said for not splitting a software program into separate functions/procedures. Nobody says that, for good reasons

Do whatever is necessary to make a schematic readable and understandable by someone else.

Even if nobody else will ever look at the schematic, apply the idiom "the past is a foreign country; they do thing differently there" to yourself.

https://idiomorigins.org/origin/past-is-a-foreign-country

[nctnico]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

The same could be said for not splitting a software program into separate functions/procedures. Nobody says that, for good reasons

Sorry, but that analogy completely fails. Your are not understanding the problem. A proper software analogy would be to write a library and have a header file with defines which converts every library function name into a different name for no good reason. So your program calls 'remove_white_space' and the library magically executes the 'delete_ws' function. Bonus points for having several different delete_ws functions. Good luck trying to debug that mess.

I'm all for dividing a schematic into several schematics with logical functions grouped together but renaming nets by / because of using hierarchical blocks usually makes the situation worse instead of better.

[tggzzz]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

The same could be said for not splitting a software program into separate functions/procedures. Nobody says that, for good reasons

Sorry, but that analogy completely fails. Your are not understanding the problem. A proper software analogy would be to write a library and have a header file with defines which converts every library function name into a different name for no good reason. So your program calls 'remove_white_space' and the library magically executes the 'delete_ws' function. Good luck trying to debug that mess.

No, it doesn't fail.

"Signal names not matching within the schematic blocks" is equivalent to complaining that a function's formal parameter names are different to the actual parameter names used where the function is invoked.

Libraries are a red-herring. I can't be bothered to try to understand your "delete_ws" contention.

[nctnico]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

The same could be said for not splitting a software program into separate functions/procedures. Nobody says that, for good reasons

Sorry, but that analogy completely fails. Your are not understanding the problem. A proper software analogy would be to write a library and have a header file with defines which converts every library function name into a different name for no good reason. So your program calls 'remove_white_space' and the library magically executes the 'delete_ws' function. Good luck trying to debug that mess.

No, it doesn't fail.

"Signal names not matching within the schematic blocks" is equivalent to complaining that a function's formal parameter names are different to the actual parameter names used where the function is invoked.

Again, you are not understanding the problem! If you are never dealing with complex schematics, you likely never came across the issue and hence are oblivious to the problems it can cause.

In a software analogy the problem is not in naming the function parameters but having different names for the same entity. So you have one function with several different names. Or the same struct with several different names. Or the same class with different names. Just as it gets hard in software to trace what is what, a schematic in which you have identical nets under different names IS hard to understand. Hierarchical schematics may look like function names / parameters but they are not equal at all as the hierarchical information in a schematic gets lost along the way.

The bottom line is: do yourself and co-workers a favour and don't use hierarchical schematics unless you need to duplicate the same functional block multiple times.

[tggzzz]

Unless you need to copy the same schematic block several times, there is no real need to use hierarchical blocks. Typically using a hierarchical structure with a top-level makes a schematic worse instead of better because the signal names don't match within the schematic blocks. This makes it very hard to debug & understand a schematic during verification (hardware testing) and embedded firmware development. It simply doesn't help when the same signal has 3 different names in the same schematic and on the PCB it will be 1 single trace anyway.

The same could be said for not splitting a software program into separate functions/procedures. Nobody says that, for good reasons

Sorry, but that analogy completely fails. Your are not understanding the problem. A proper software analogy would be to write a library and have a header file with defines which converts every library function name into a different name for no good reason. So your program calls 'remove_white_space' and the library magically executes the 'delete_ws' function. Good luck trying to debug that mess.

No, it doesn't fail.

"Signal names not matching within the schematic blocks" is equivalent to complaining that a function's formal parameter names are different to the actual parameter names used where the function is invoked.

Again, you are not understanding the problem! If you are never dealing with complex schematics, you likely never came across the issue and hence are oblivious to the problems it can cause.

In a software analogy the problem is not in naming the function parameters but having different names for the same entity. So you have one function with several different names. Or the same struct with several different names. Or the same class with different names. Just as it gets hard in software to trace what is what, a schematic in which you have identical nets under different names IS hard to understand.

The bottom line is: do yourself and co-workers a favour and don't use hierarchical schematics unless you need to duplicate the same functional block multiple times.

Oh, I have both used and created many many hierarchical schematics over the decades.

Non-hierarchical schematics are a pain in the backside, except in the boring case case where the system is so small that it fits on one A0 sheet.

The only thing worse than a multi-sheet non-hierarchical schematic is one where the components aren't connected with wires, merely with named nets.

BTW, your experience with software systems is bizarre. The kind of strangeness you describe ought to be trapped out in a design review. Or are you conditioned by C++'s faux pas?