kicad-developers team mailing list archive

[James Jackson <james.a.f.jackson.2@xxxxxxxxx>]

Evan,

That's really helpful  - thank you for taking the time to put that
together. I've got a few comments and queries:

1. All in, that seems like (on the whole) incredibly sensible behaviour,
even if the implementation / UI is sometimes painful!
2. The possibility of package locking also appeared earlier on in the
thread - in my mind the ability to lock an annotation (whether by adding a
property, or some textual inference like the 'excel-like' $ prefix) would
be a strong addition in itself.
3. I really like the idea of allowing block suffixes for repeated
schematics - I'd use that in my workflow if I had the option (it would make
later steps in the chain much less painful - debugging physical boards
etc). How does it handle nested repeated blocks, i.e. Schematic A nests two
copies of schematic B which itself nests two copies of schematic C? I can
think of two ways of doing this - either simply with higher incremented
numbers for next blocks, or chained suffixes (the latter feels messy and
wrong though with exponential combinatorics - R1ABD!).
4. I don't quite understand your description of the painful step of block
packaging required before you are allowed multiple instances. I'd
appreciate a little more info on this if possible?
5. I agree with erroring out (or advising, giving an option, and
continuing) rather than sprinkling new symbols around the schematic - I'd
be pretty surprised if an 'annotate' call resulted in new symbols
appearing; that would strike me as unexpected behaviour given the name of
the function being performed. FWIW, I don't think the current KiCAD
multi-part annotation is particularly brilliant; it's really easy to get
some confusing results with repeated schematics. Also, it's my view that it
may not be possible to come up with an algorithm that handles every
possible combination or permutation thrown at it (nested, peer, split,
repeated, etc etc). In this situation, I strongly feel it should either do
something sensible or advise the user as to what it's not doing.

Really useful food for thought - my brain's still churning through the
possibilities, and this is all good stuff to reflect on.

Thanks,
James.


On Fri, May 8, 2020 at 10:12 PM 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
>>
>