kicad-developers team mailing list archive

[Tjeerd Pinkert <t.j.pinkert@xxxxxxxxxxxxxxxxxx>]

My text:
---
license: CC BY-SA 4.0
Copyright (add name when editing/extending):
Tjeerd J. Pinkert, 2020
     contact: <t.j.pinkert <AT> alumnus.utwente.nl>
---

Dear Quabache, Eeli, list

It took me a while to answer, reading below might explain why.

Ouabache Designworks <z3qmtr45@xxxxxxxxx> wrote:
-----
> Kicad implemented hierarchy in a way that was different than how it
> was usually done by the rest of the industry.  The fix is to see how
> everyone does it and do it the same way.

I would not agree with that on forehand. Industry is not always thinking
for an as broad scope as can be potentially covered by Kicad and
industry can have other drivers than pure customer interest, e.g. market
policy / vendor lock in, that might influence the way software is designed.

Thinking about the electronics design one can designate several stages
of refinement as far as I see it.

1. (Abstract) Component: a drawing of the key function of an electronics
    part. This drawing includes the electrical ports of the component as
    wire ends.
2 Ports: a definition of each port for use by the schematics capture
    program. The program could otherwise not "find" the ports.

These two are typically combined in a basic component in the library.
The ports typically extending the drawing (having both a graphical and
organisational component).

3. Schematic: Graphical representation of components and their
    interconnections that form a larger electrical unit.

The schematic is the basic representation of an electrical circuit. This
can e.g. be an op-amp circuit. The schematic does not necessarily say
anything about the properties of the circuit, but it gives a hint in the
direction in which the equations of the circuit behaviour might develop.
The list of connections is generated from the schematic, this list will
have only the connections, but no component values.

4. Parametrisation: The (implicit or explicit) assignment of
    mathematical models for each component and the component values.

After this step a complete model for simulation should be available
since all equations are (implicitly or explicitly) known. Note that this
is normally the scope of a circuit simulator's schematic capture tool.
The ability to include explicit circuit models could call for close
integration with e.g. ng-spice since a double efford would be a pitty. I
think the current approach of "magic attributes" to components could
become a more integrated domain? (E.g. store the transistor model
together with it's values as a complete parametrisation item).

5. Specification: The assignment of specific parts to the components
    that electrically match (or can match) the mathematical description
    given in the parametrisation.

This step can still be rather abstract, e.g. in the design of chips this
can be a predefined transistor or resistor type from a library, or the
application of assigned parameters to a parametrisable transistor model,
e.g. length and width of a MOSFET to a mosfet design. On the other hand
it can be the selection of a transistor from types offered by a vendor
resulting in a (partial) MF / MPN combination.

6. Mechanisation: The assignment of the mechanical form factor of the
    selected part. Of importance here are the shape of the electrical
    connections, the overall shape of the component or package of the
    component. So basically shape, potentially also connection position.

This form factor is the basis for the selection of footprints for the
PCB design. It can also be the basis for a mechanical support (e.g. when
selecting the form factor of coils for a 100 kW transmitter), or maybe
both, when selecting a transformer that needs electrical connections but
also mechanical supports.

Usage of steps 4 to 6 can have several orders of application, which a
good tool should all support. Some ways that I can think of are:
* assignment of value (4) and mechanical form factor (6) for a resistor.
  The model (4) is implicit (R=U/I), no parasitics. Part specification
  (5) takes place when a buying decision is made based on (4) and (6) in
  the BOM.
* specification of a transistor part (5). The parametrisation (4)
  (simulation model and model parameters) is based on the selected
  component. A mechanical form factor (6) is chosen based on dissipation
  calculated from simulation.
* assignment of the mechanical form factor (6) of a resistor. The value
  and specific part are defined based on experimental results (e.g. in
  prototyping a microwave circuit where the suitability of certain parts
  is being compared).

For a PCB design only step 6 is needed directly after step 3. These
properties are sort of parallel, but not always, since for a PCB the
mechanisation chosen might allow several parametrisations and/or
concretisations even multiple concretisations with the same parametrisation.

From step 6 on on, one should be in the PCB layout tool when a PCB is
involved. Or in the drawing tools for mask design when doing chip
design. For PCB design the steps following would be:

7. Footprint assignment: A footprint is assigned to each component based
    on the mechanical form factor and the production process. E.g. SMD
    for wave soldering or SMD for reflow soldering, or THT pads suitable
    for hand soldering or wave soldering of components.

Footprints could be ordered in solder/mounting technology categories.
One can envision e.g. two categories of footprints for an 0603
component, one for wave and one for reflow soldering processes. It could
be an asset to switch footprint category "on-demand" although this would
typically require a redesign of the PCB. To assign footprints from a
certain category to a schematic would be favourable however.

8. Pin definition: Areas of the footprint are designated to separate
    electrical circuits.
9. Pin-to-Port mapping: The assignment of component ports to pins ports
    assignment.

This information is typically kept in the library of components in
commercial tools. As it is seen, this might or might not be the "right"
place.

10. Layout: wiring the footprints according to the netlist.

This step involves keeping the layout in compliance with the PCB
manufacturing possibilities, which I skip here, since it is not part of
the schematic capturing tooling anymore.

In the next part I will refer to these steps as (x), where x is the step
number.

> 1) Projects and Libraries merge into a single entity . The project
> that you design and upload to github.com is download by your users as
> a library. So your project and library file formats must dovetail so
> that one design repo satisfies both at the same time. The libraries
> that you downloaded were once someone else's  project

A first question would be: what comprises a project? In Kicad that is
the total of schematic, a copy of the parts used from the user libraries
and the PCB layout. So in a holistic view all should be uploaded (can
already be done) but the possibility of transforming a schematic (and
associated stuff) into a new component is absent.

I think in this case the "separation" would lie between step 3 and 4.
Hierarchical pins can be defined in the schematic. The schematic has
then become a component in the sense of step (2) (ports defined). What
is missing is a way to link the schematic to the component (1), and ways
to preserve useful information from (4) to (10).

I think you are partially right that the difference between a schematic
and library file would thus need to dissolve. The bare components
(without schematic lying behind them) would be included in the file and
the schematics are included in the file, each referencing to lower
schematics in the hierarchy? Although the modular approach as I proposed
it, would leave the option open to link schematics from external
projects too. Then each project can be managed on it's own up to a
certain level of completeness as needed.

On implementation this would call for a file format that can store such
hierarchies and ways to check the integrity of the component pin to
schematic hierarchical label references.

I would envision linking at the schematic level, but keeping the ability
to select which steps from 4 to 10 should also be inherited, when the
schematic is being placed as component. It would make sense to store
that information on a per placement basis in the schematic.

In case a hypothetical chip layout tool would be added a silicon layout
could be included next to a PCB layout for a discrete implementation of
the circuit. Linking and inheritance could then take place in a similar way.

> 2) Add bottoms up design. Kicad needs a "Make Symbol" menu pick to
> create a symbol from the schematic.

That would be a nice feature for the GUI. The schematic would then be
included in the library file to which it would be added as a component,
or, in the modular design approach, could stay in it's own directory,
whether or not under version control.

The modular version could then call for an "export" knob, which includes
all of the file contents for a design in the modular way, into one large
exported file that can e.g. be posted online. On the other hand
components based on shared schematics, could have the possibility of
splitting out, flattening (as in removing the hierarchies) into a bare
schematic, while keeping in place the information from (4,5,6).

As the inverse of that have the capability to create a component or
hierarchical sheet from a selected part of the schematic, potentially
including information from (4) - (10) that is already existing, as a
basis for modification to create a nice and consistent component at each
level.

I don't see a reason why, when properly implemented, both the "holistic"
and "modular" methods could not coexist to leave the choise to the user.

> 3) Store the current hierarchical symbols created by top down kicad
> design in the same file format as bottoms up symbols.
>
> Do those three things and start using attributes and your problems
> will be solved.

Using attributes, now it gets interesting!

In my view several parametrisations (4), specifications (5) and
mechanisations (6), including zero, can exist for a schematic. Sets of
one or more of these form the basis for further steps in the process
such as simulation, PCB or chip layout and mechanical design (a set can
include several of a single type, mechanisation might be an exception).
I think it would thus make sense to be able to store several of (4, 5,
6) at the schematic level and have the capability of creating and
storing several sets at the schematic level. I think this could also be
the level of abstraction at which a coupling to the generator of the
Bill of Materials could be set? Several sets of (5) could then be used
to populate the BOM for various versions of the product.

Also per set of (4,5,6) we could create a PCB, e.g. one for THT
implementation and another for SMD implementation. So the linking to the
PCB files should then be applied per set (4,5,6). It would be a question
of multiple (6)s in the set make sense, since for PCB creation one would
always need to choose one, but maybe some form factors could match one
footprint... Being restrictive here might limit users, although (a
configurable) warning system might be usefull.

This would also solve another problem that people might have, namely
keeping revisions of the electronics. Many times this evolves around
obsolete parts, where replacements are only available in a different
mechanical form factor. The ability to include multiple sets of
different (5, 6) for a component can solve this. The PCB can then be
copied from an earlier set and adjusted for the new set (which becomes
then a revision of the part list / PCB). This would enable keeping board
revisions without copying the complete project to a new folder, while
keeping the flexibility of updating the original list and keeping the
revisions in a version control system when wanted. This assumes however
that components can be replaced without altering the schematic. I think
it would be questionable to extend such capabilities to schematic
revisions. Kicad is not necessarily a version control tool.

Envisioning that the layout (10) could be part of a hierarchical sheet,
this means that when doing a layout based on a large schematic with many
components, the layout of a component should be editable at component
level, but when these are placed in the larger layout, a need could
arise to modify the standard layout to fit it into a specific board.

In this view the overriding of parametrisations (up to default layouts)
can happen at each point where a schematic is included as hierarchical
sheet / component. This is also the logical point of storing altered
annotations of the hierarchical sheet / component. Various schemes for
annotation could be thought of. Tables could provide a (layered) view on
the parametrisation. In the hierarchical filter example in the original
document, a higher order filter could remap, through annotation and
allowing the annotation to be edited, the enumeration of the components
for fill-in from a filter equation.

Now to the definition of a component. In the classical approach a
component definition in a library includes information from (1) to (9),
but typically only one entity of each layer. When Kicad would like to
offer more flexibility this concept would need rethinking. Especially
the question if information from (7) to (9) would fit in this picture
could be questioned, although I think it certainly makes sense to assign
a default footprint and pin/pad mapping in a certain category.
Nevertheless it might make sense to mass override this at the PCB design
level. Given the descriptions above, a component like a transistor can
be a generic item, the "decoration" with properties from (4,5,6) would
make it either a generic with a narrower specification, or a specific
with one or more mechanical form factors. Per mechanical form factor (7)
to (9) would be assigned in the library. To assign (10) makes sense when
a circuit based component is selected which can be given a default
layout, and can then be used as a module.

Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx> wrote:
-----
> I don't understand all of this, but some kind of parametrization of
> values of components in hierarchical sheets has been wished for in
> some bug report.

I am also only playing on thoughts how such a thing could take shape...

> I would like to see full utilization of user definable variables with
> capability of overriding, not only for hierarchical sheets, but all of
> KiCad (at least eeschema and pcbnew, i.e. schematics and layouts).

Such a thing would be possible when each value can also be a variable.
At each level of definition it should then be possible to assign a
variable with the value of a variable at a higher level. In the filter
example the T and Pi filters would have ${L1}, ${C1}, ${L2} and ${C1},
${L1}, ${C2}, and e.g. when combined one could thing of T1.L1=L1,
T1.C1=C1, T1.L2=L2, Pi1.C1=C2, Pi1.L1=L3, ... where C1...Cn and L1...Ln
can be variables again at the next schematic level.

Such a capability comes almost naturally into existence when (4) is
treated as a separate category and not part of (3). At the level of (3)
each component only gets a number, values are assigned depending on the
set. On screen one could think of a drop-down for the schematic in which
a set (4,5,6) is shown to work on/in.

> There would be a table for freely named variables which could be
> defined or overriden in each level: user, project, main level
> schematic sheet, 1st level hierarchical sheet etc.

Indeed I would see this happening quite naturally at each inclusion
level of a hierarchical schematic / component.

> For example I could define a variable named ${WRITER} with value
> "Eeli" in user level, then use it in all my projects in any place
> where text can be entered. Each file or other comparable entity like a
> hierarchical sheet instance would have a table of variable names and
> values where values could be overriden. Probably there should be a way
> to do the overriding vice versa: if the value for a variable is given
> in upper level, it will be used, otherwise the local default value is
> used. So, there could be a third column in the table: "prefer this" or
> "override this".
>
> This is quite complicated, but it would be invisible if a user doesn't
> want to use it, and it would give as much freedom and new
> possibilities as possible with one unified generalized approach. It
> can be applied to more problems than just parametrized sheets.

I think I agree fully with you. That would certainly satisfy my needs at
the schematic level. If this would / could also be reflected at the file
system level as project directory (under version control) per schematic,
I would be fully satisfied.

> Would that satisfy your needs?
>
> Eeli Kaikkonen (not a KiCad developer)

I would like to know from the developers side, would it be OK to insert
feature requests based on this discussion into the Gitlab issue list? I
think this actually should be fodder for a roadmap discussion, but it is
at this point unclear how and where that runs...

Yours,


Tjeerd Pinkert

Attachment: signature.asc
Description: OpenPGP digital signature