kicad-developers team mailing list archive

[Evan Shultz <evan.shultz@xxxxxxxxx>]

Replying to the enumerated items asked of me, even though it's not the most
recent email.

James,

3. You have two options.

But first, I forgot one other point about the ref des pattern feature. You
can also put in a static character. So I could make my ref des pattern
'<symbol prefix>1<incremented number starting at 1 with two digits>' to
start with R101 and C101, no R1 or C1. Does that make sense? If I then
start another design at R201 and C201, it gives me an easy way to annotate
two schematics for two boards that go into the same product, using the
first number as a way to identify which board a given part is on.
(Naturally, in this example only 99 instances of a symbol prefix could be
used before things got messy.) Probably there are other uses but that's
what I've done.

The ref des pattern suffix is overridden lower in the hierarchy. So if I
select the suffix to be A on one block, all the parts in that block and
child blocks get an A at the end. But if that block has two child blocks
with the suffix set to B, only the parts directly inside that block end
with A and the parts inside the child blocks get B. To get multiple
suffixes like you showed would require are least three levels of hierarchy
using different properties. And recall that the property name can be
anything you want, so it is possible but it seems more trouble for factory
and repair folks down the line than it's worth. Or maybe I'm missing a good
use case? A single leading number (which can be one property) and a single
suffix letter (a second property) gives you 9 big chunks of circuitry with
26 smaller chunks for each of those 9, and even with big hierarchical
schematics I've not run out of options that way. Surely it's possible,
though.

Now back to our regularly-schedule program...

The first way is simple where you plonk down whatever blocks you want and
package the whole design. DEHDL will assign whatever ref des it wants, and
then add in any ref des pattern you select. So a capacitor might be C5A on
the first block, C74B on the second block, C131C on the third, etc. This is
fine in some situations, but it's more awkward for manufacturing and
service, I've found, because you can't say 'C5 in the input circuit' and
refer to any instance of the circuit.

If you want to have blocks with some commonality of ref des between them,
you need to do the packaging song and dance for just the block which I'll
explain below.

4. The 'packaging' step generates the ref des and all information for a
block and any child blocks. You must open the design at the level you want
to package (closing the schematic, picking the block, and re-opening again
where levels 'above' the block are not present in the schematic). You then
mark the open block to be 'reused' and then package the schematic like
usual. Once that's finished you're able to open the schematic at the top
level, select the blocks to be reused, and then package the whole thing. It
gets ugly because you need to do the block-level packaging step for each
block that you want to instantiate more than once and you want any special
treatment of the ref des, like R1A, R1B, R1C, etc. And if you make a change
inside that block that affects the ref des, like adding or removing a
component, you must package just that block again and then re-package the
entire schematic. Recall that if there are static characters in the ref des
pattern you need to edit those manually for each sub-block you're packaging
individually, so if you forget that you don't find out that everything is
blown up until you've packaged the entire design at the top level and you
wasted so much time you need to go outside and scream at Cadence until
you're hoarse. Then revert to the last good commit in the repo and do it
all over again the right way. It can take quite some time to get the hang
of it. And even then it sometimes doesn't work out like you want. Trust me,
it can be painful. But it's usually worst right at the beginning and then
the design matures and it's less painful as you get closer to production.
Still painful, but less so.

That may still not be clear. I didn't find any videos on YouTube about it.
https://www.ema-eda.com/sites/ema/files/resources/files/design-reuse-subdesigns-modules.pdf
shows
an example hierarchy on pages 5-7 but it's a very old version and I don't
think the information is very helpful if you don't already know the
software. Please ask more questions. Or, even better for KiCad and her
users, I propose to image the desired outcome and then figure out a better
way to make it happen.

Because what you asked, I think, for #3 and #4 encompasses both of those
answers things are spread around. Hope that makes sense.

5. Agreed. Automatically making more physical packages is one solution but
I'd be annoyed if it was the only solution. Allowing grouping of gates at
any level of the schematic is  possible and reasonable. I believe the
tricky part is not making an either/or declaration and giving up but
considering all the use cases and supporting at least the common and
desirable ones. If the schematic is best understood (besides capturing the
netlist it's there for other people to see and understand!) as deeply
hierarchical then I don't want to compromise the schematic just because a
limitation of the ECAD tool means I need to pay more money and consume more
board space for unused gates. Easy to say for a knucklehead like me without
the skills to implement the feature in KiCad, ain't it?

Evan


On Sat, May 9, 2020 at 12:44 PM Alexander Shuklin <jasuramme@xxxxxxxxx>
wrote:

> Hi James,
> few months ago I implemented "update schematic from pcb" feature, and
> I think it's a little bit similar to feature you want to make. I'm not
> very often work with KiCad source, but if you don't have better person
> to ask, feel free to ask me.
> First of all - there's major change in schematics code, but I believe
> api remains the same.
> First advice - don't get lost between SCH_COMPONENT and SCH_REFERENCE.
> Basically if you want to work with some schematic modules, you want to
> use SCH_REFERENCE class. It holds data about where (in what sheets)
> component was used and all data about it (majority is in the
> corresponding SCH_COMPONENT class. You can get it with
> SCH_REFERENCE.GetComp() ). Imagine that you have 3 hierarchical sheets
> which share same resistor. With that particular resistor you will have
> only 1 SCH_COMPONENT instance and 3 SCH_REFERENCES instances.
> There's quite handy api to mange all these. I'll cite some piece of
> code from "update sch from pcb" (eeschema/tools/backannotate.cpp)
>
> SCH_SHEET_LIST sheets( g_RootSheet ); // You'll get all sheets in root
> schematic
> sheets.GetComponents( m_refs, false ); // You'll get plain list of all
> SCH_REFERENCEs
> sheets.GetMultiUnitComponents( m_multiUnitsRefs ); // You'll get all
> list of the multi-part units
>
> Basically, you will need to parse these containers to manage all
> errors you can get during block annotation.
>
> With git I usually follow git master head and keep my patch in one
> commit (if I don't have reason to do opposite) In that case it's very
> easy to follow master updates. But I like git :)
>
> Brian,
> sorry that I missed your mail, I believe for refreshing schematics you
> can look in eeschema/dialogs/dialog_update_from_pcb.cpp : 126 line
>
> Sorry if I say something trivial or I explain in some strange way, I
> hope my mail save your time at least a little bit.
>
> On Sat, 9 May 2020 at 00:13, Evan Shultz <evan.shultz@xxxxxxxxx> wrote:
> >
> > Since other ECAD tools are specifically mentioned and I use a new tool
> I'll add my 2 cents. I'm a Cadence Design Entry HDL user (oh God, it's so
> awful...) working with always hierarchical schematics often having >100
> pages.
> >
> > DEHDL works on a principle where you add symbols and then they're
> 'packaged' (annotated) later. That part is like KiCad. Each symbol has a
> property where the ref des is the property value. The property can be set
> to locked or not (this is determined by having a leading dollar sign or
> not). If the user manually types in a ref des, it automatically locks and
> the ref des cannot be changed during annotation. The user can also manually
> lock a property after annotation.
> >
> > A cool feature is the 'ref des pattern' which is applied during
> 'packaging'. Packaging happens from the top down, and as the packager moves
> deeper and deeper into the schematic it pushes down into from the top. If I
> have a hier block with any random property, let's say BLOCK_SUFFIX, I can
> then use the value of that property in the 'ref des pattern'. For example,
> if I have 8 instances of the same block I can give them a BLOCK_SUFFIX
> property with a value A through H. Then the ref des pattern can be '<symbol
> prefix><incremented number starting at 1><BLOCK_SUFFIX>' where <symbol
> prefix> is 'R' for resistor, 'C' for capacitor, etc. and controlled by the
> library symbol. So I will get a R1A in the first block. And the
> corresponding part in the second block is R1B, continuing on through R1H.
> For parts at the top level of the schematic not in a block, or parts in a
> block without a BLOCK_SUFFIX property, the value is automatically set to an
> empty string. And any sub-blocks will also get the same BLOCK_SUFFIX from
> their parent block. I could also make a pattern like  '<symbol
> prefix><DESIGN_SECTION><incremented number starting at 1><BLOCK_SUFFIX>'
> where DESIGN_SECTION is a property on blocks broken up by function in the
> product so '1' for digital circuitry, '2' for analog, etc. This means the
> first resistor in the digital part would be R11, and the first resistor in
> the analog circuitry is R21A going through R21H. And if I put I/O
> connectors at the top level of the schematic, I get J1 and not J11. There
> are many, many uses and that is one thing I think fits nicely with the core
> idea proposed that I'd love to see in KiCad.
> >
> > One painful step is that any block which is to have multiple instances
> and be packaged like I've shown above must be packaged on it's own. Not in
> the scope of the entire design, but with the block itself as the top level
> of the schematic. Then later that block (and any child blocks) can be
> packaged with the entire schematic. There are a number of hoops to jump
> through and potential gotchas if the you want the BLOCK_SUFFIX behavior
> described above to work.
> >
> > If a user in DEHDL places too many gates to fit into one physical
> package and then have locked the ref des, there is an error during
> packaging and packaging stops. It knows if have the power pins of an opamp
> set to be U73, and I place another set of power pins also set to be U73,
> that cannot work. But if a user places a bunch of symbols the packager will
> try to condense them into as few physical packages as possible (there are
> several settings but that's the default behavior). I personally would like
> to be aware of what's going on during this step of annotation and not see
> KiCad create 43 physical parts on it's own simply because of how I decided
> to construct the schematic without having any options.
> >
> > Regarding multi-unit symbols spread around a schematic, in DEHDL one can
> place a symbol in a block but not have that symbol packaged with other
> symbols in another block, whether the blocks are peers or parent/child. For
> example, if I have one dual opamp gate in one block and another in another
> block, I will get two physical packages. DEHDL can't handle that situation.
> It's a little sad. The workaround would be to add ports and place the
> common part at a high level in a schematic. Imagine a dual instrumentation
> amp circuit with a block containing a pair of inst amp blocks. The single
> gain setting resistor would need ports if a single dual pot or dual
> digitally-controlled resistor IC or other single component is to control
> the gain of both inst amp circuits. Make sense?
> >
> > DEHDL can add parts to a BOM without them having a schematic
> representation, but it's a horrible process that I've tried several times
> and given up on. It feels like the kind of thing that an Intel or Motorola
> paid $1B to have implemented and it's tied to one user's specific way of
> working and their library structure. I can see value in the idea, but not
> the execution.
> >
> > Lastly, when pushing schematic changes to a board in Allegro the parts
> go into a queue and can be placed in many ways. They can be placed
> manually, one-by-one, but there is an autop-placement feature that gives
> many options. One is to place at a selected point by schematic page so I
> can plop down piles of footprints that represent each schematic sheet. And
> then I can do the layout once and replicate it for multiple corresponding
> piles. I really like having more control over placing footprints than
> Pcbnew gives, but alas. I'm not sure this was already part of the
> discussion above, so sorry if it's a tangent.
> >
> > I'd be happy to answer questions or provide screenshots if that helps to
> explain things. Let me know.
> >
> > Cheers!
> >
> > On Thu, May 7, 2020 at 3:54 PM James Jackson <
> james.a.f.jackson.2@xxxxxxxxx> wrote:
> >>
> >> Thanks Jon - I don't have access to Altium so that's really helpful.
> >>
> >> I was wondering about the possibility of locking components; I
> sometimes want to do this with, for example, key ICs - MCUs, DACs, etc. One
> could add this as a Symbol Property, which wouldn't need any changes to
> file formats. Whether it got a custom checkbox in the Symbol Properties
> dialog, or would just be there as another option that a user may add (which
> would make it a 'power user' feature as it wouldn't be obvious unless one
> knew to add it) would need to be considered - UI clutter vs. access to
> features for all.
> >>
> >> With the multi-part consideration, where on the schematic does it dump
> the new components? It wouldn't be too difficult to implement an algorithm
> which finds a space in which all the sub-components required could fit,
> with some gross assumptions on layout. Or can Altium add a component to the
> BOM without it being on the schematic?
> >>
> >> I'm also mindful that some algorithms can't solve everything (although
> this strikes me as a non-trivial problem, rather than an impossible
> problem...) - and bailing out and telling the user why is also always a
> option, in the spirit of 'do no harm'.
> >>
> >> Yours,
> >> James.
> >>
> >> On Thu, May 7, 2020 at 9:59 PM Jon Evans <jon@xxxxxxxxxxxxx> wrote:
> >>>
> >>> Altium doesn't have "annotate selected"
> >>> It does let you lock the annotation on components at will, so you can
> lock some, reset everything (which ignores locked) and then re-annotate.
> >>> If you change the annotation of one part of a multi-part component, it
> will result in two components being forwarded to the PCB like Janvi
> proposes.
> >>> And also likewise, the ERC will warn about this if configured
> appropriately.
> >>>
> >>> As to how it handles the complex hierarchy situations JP mentioned,
> I'm not certain to be honest, because Altium's hierarchy model is a bit
> different from KiCad's (in some ways simpler) and I haven't checked to see
> if the same situations are possible.
> >>>
> >>> -Jon
> >>>
> >>> On Thu, May 7, 2020 at 4:48 PM James Jackson <
> james.a.f.jackson.2@xxxxxxxxx> wrote:
> >>>>
> >>>> That's an interesting take on it. I can foresee the catastrophic
> addition of loads of other components though, if there's an error in the
> schematic somewhere and a rogue missing / one-over unit gets cascaded down
> sheets.
> >>>>
> >>>> What do other EDA tools do with annotation? Do they have this
> feature? Do they handle these conditions?
> >>>>
> >>>> On Thu, May 7, 2020 at 8:18 PM janvi@xxxxxxxxx <janvi@xxxxxxxxx>
> wrote:
> >>>>>
> >>>>> > - What about multi-units components: for instance what about
> renaming 2 of 5 units when one unit is the unit handling the power pins?
> >>>>> > this is the best way to break a design.
> >>>>>
> >>>>> This should add another component to the BOM and schematic DRC should
> >>>>> report unused gates for both of the reference designators
> >>>>>
> >>>>> > Good luck with block annotation.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>