KiCad Spice, Anyone Tried It?

From some of the Altium "help" on hierarchical schematics:

Multi-Channel Naming

The concept of being able to capture once and then repeat - multi-channel design - is delivered by building on the software's unified data model (UDM). Repeated components are named using a systematic naming scheme, which is configured in the Multi-Channel tab of the Options for Project dialog, as shown below.

The dialog includes an upper section used to control the naming of the Rooms, and a lower section used to control the naming of the components within those Rooms. At the Room level, there are 2 flat naming styles and 3 hierarchical naming styles, typically you would only need to choose a hierarchical naming style if the design has channels within channels. Otherwise, a flat Room naming style is shorter and easier to understand.

For the component naming, the $Component$ChannelAlpha or the $Component_$ChannelIndex option will give the shortest, and most easily interpreted component designation. It is also possible to construct your own designator naming scheme, using the available keywords.

Now my board has Rooms? Five naming styles? Nightmare.

This sort of thing is for people who would rather play with tools instead of doing the boring job of getting things done and working.

My "most easily interpreted component designation" is R112.

That's reasonable, to be expected, /and can't be otherwise/, except in trivial cases.

Simple example: inside a flip-flop component it is called "Q", but where the component is used it is called "standby".

The same happens in software, the parameter name inside the function vs the argument name supplied to the invocation of the function. int double(int x) { return 2*x; } invoked as int baz=123; int squirdle = double(baz);

Of course.

Well, in HP manuals...

Resistor R114 on assembly A3 is denoted A3R114 in the parts list and the silkscreen on A3 only shows R114.

If the schematic has to be split over a (small) number of pages, then each entry/exit explicitly denoted where the connection goes to and comes from. That doesn't happen on modern schematics that I've seen.

Clearly it is undesirable, as with software, to have deeply nested hierarchies.

I'll assume that by "channel" you might mean "replicated subcomponent".

What happens where the subcomponents/channels are identical and both contain an R114?

So a low-pass filter R59-C59 might become R131-C7?

Unambiguous, but aesthetically unpleasing to me.

That is only sufficient on a small scale.

You have chosen a different form of complexity.

Irrelevant.

The points are equally valid for designs cast in concrete.

Irrelevant.

Your misapprehensions on this topic are legion and repetitive.

I did, for decades.

I also designed and implemented server-side software for decades.

Do you implement such software?

(I believe you have said you leave that to others.)

With the exception of "doing mechanical things", I've had to do all that with software. It was always a pain.

You repeatedly make the same mistake through lack of comprehension. In each case I have given simple illustrations of that in the next paragraph, e.g....

I have done, for several decades, but I am now happily retired.

I also spent some decades on the dark side (software), and so am intimately acquainted with their similarities and differences.

Ditto software.

Nowadays most systems/products are a combination of hardware and software. Choosing the appropriate boundary between the two is often critical, and distressingly few people can do it effectively.

We're a manufacturing company. Engineering is expensive overhead. We need to optimize purchasing, assembly, inspection, and test. So we do it that way that works best for them. They want the parts to be easily located, in physical order.

How about 24 channels of lvdt/synchro/resolver input/output on one board?

Simplicity.

I was looking at the Altium stuff on hierarchical schematics. Now I understand. It's not a schematic entry program, it's a compiler. It wasn't designed by engineers, but by programmers. No wonder so many weird abstract concepts were never mentioned in engineering school.

That's version 18.1!

I wrote two compilers and three pre-emptive RTOSs and maybe a hundred embedded programs, but I find hardware design to be more fun, so I delegate as much as I can, code and FPGAs. I just tell the typists what to do. I'd rather draw than type.

My kids are pretty good with Python for test software. I ask, can you do a 5th order polynomial to calibrate that DAC? They say, sure.

Mistake? I design stuff, it works almost always first try, and we sell it.

I'm still happily designing products, and things keep changing. Technology may out-run me some day, but it's still making toys so far.

It's great fun to design a product where you can do stuff analog or digital, in hardware or FPGA or uP code. Brainstorming with the FPGA and c people helps a lot.

I do have a hard time pinning the c people down to times. Can you run that IRQ at 200 KHz for me?

Most definitely :)

Part of that is due to C (worse C++), part of that is due to the processors. Caches and interrupts make accurate prediction impossible and you are left with measure and hope you've captured the worst case. Ugh.

But there is one and only one exception. (We need more, but until then...)

The XMOS processors are multicore (up to 32, transparently extendable across multichips) 100MHz processors, so 4000MIPS/chip. There is no cache and no interrupts, so timing is predictable: the IDE guarantees the min/max timings between here and there. Effectively the principal functions of an RTOS are implemented in hardware.

Traditionally multiprocessor programming has been, um, difficult, but the XMOS ecosystem is excellent.

The hardware i/o is FPGA-like: SERDES, strobed, asynchronous etc. It is trivial to specify that output occurs on a specific clock cycle (asynchronous clock to the CPU clock) and captures the clock cycle on which input arrives.

Uniquely, the software is integrated with the hardware so that i/o is exactly the same as inter-core communications. The software and hardware presume parallelism, where all other systems have it as a bolt-on afterthought (possible exception: Ada).

So you get a solid *hard* realtime system which doesn't have late surprises and which is /fun/.

The company has been around for 15 years, and the concepts were first implemented in the 80s (Transputer, Occam) based on 70s theory (Hoare's CSP).

t isn't

don't

l. So to

lower

e pages.

Yes they do, or they are taught that way. The perspective of 'sw is easy t o change if we don't get it right' is at least 30 year old school. Softwar e gets 'wrong' for a lot of reasons-too many to enumerate here. For exampl e, one that I ran into....iTunes was a very stable product when running on a single core. Multi core came along and now there are concurrency issues that would hang the app. Was the sw 'wrong'? was the OS 'wrong'? or was th e hardware 'wrong'? Sw is not designed in a vacuum and when system require metns change, all bets are off...

It certainly can and many safety critical system do. Some redundancy techn iques use replication. Other techniques use N-version replication. It all depends on the application and the fault-tolerance approach. Also consider application libraries. Every time one invokes a math function in C and refers to math.h, one is using a 'subroutine' multiple times. It is a form of replication (functionally speaking) J

That depends of how you construct your designators. There's nothing to stop you encoding the name of the page as well as the part number into the character string you put onto the silk screen (if there's enough room on the board).

If you've got lots of tiny surface mount resistors on a board, you may end having to print an enlarged image of the board to make enough room to display human readable designators. We did back in 1988.

So what?

That's not a necessary feature of a hierachical scheme - in fact it strikes me as the sort of thing that would happen if the design was split over several engineers, and nobody had bothered to enforce a consistent and coherent naming convention.

I've had to sit in on software design reviews, and they did seem to spend an inordinate amount of time making sure that the naming conventions were coherent and sensible, and being followed meticulously.

ptechnology.com:

well it isn't

They don't

rchical. So to

r more lower

at's

its

in

it

components have designators close together

heet

PADS

d how

s,

ant

the first page is the top and it needs a block for each additional page

Yes, that is why it is hierarchical and not flat. The sources I read all t alk about connecting the pages with global nets which apparently are like p ower and grounds. Not cool really. In a flat design all nets are global. Even in a hierarchical design I would want multiple pages per block. Havi ng to fit everything on a single page is a PITA even when you can select ar bitrary page sizes because then the pages get so big they are hard to navig ate.

A tool should support work habits, not force them. The choice should be up to the user and the tool should be flexible.

footprint

here pin 1 should be, jlcpcb uses the way the part is in the tape

contents of the XYRS file that the tool spits out? I would expect that to indicate the orientation on the PCB. Are you saying the jlcpcb program ind icates how much to turn the part rather than where it should be? I'm just not following this.

nitions of what 0 degrees rotation means

What are the differences? You mention something about position on the tape . That seems like TMI to be factored into PCB data when being laid out. T he machine operator can set the orientation on the tape as well as the posi tion of the PWB letting the machine understand what it needs to do to achie ve the orientation of the part relative to the PWB.

The only thing the PWB designer can do is say where the part should end up.

I recall seeing a spec sheet recently that was available on tape with two d ifferent orientations. WTF??? Yes, let the machine operator handle it.

ut I do know it fails from time to time.

one

IPC has a standard for that. ICs and other device that fit some clear defi nition I don't recall at the moment, pin 1 is upper left quadrant. Simple parts pin 1 is left. Why would anyone want to do something in a non-standa rd way? JLPCB is a company. Why would they want to be in the standards se tting business rather than following them???

sn't

n't

So to

wer

Not sure how KiCad hierarchical pages help with that. All the recommendati ons I saw indicated use of "global" signals that are just like naming a net for every page. A great way to create unintended shorts.

My method is a combination of ideas learned at multiple companies. For on page non-wired connections (Connection By Name, CBN) I add an arrow pointin g toward the other end of the jump. If there are multiple jumps on a singl e net, point them all to a single common point with pointers back to each o ne. At some point it's better to just draw the damn wires, sometimes. Too many random wires are a PITA as well.

For off page, each jump is on the side of the page pointing toward the page with the signal. Left to lower page numbers, right to higher page numbers . Usually that is good enough, but if it isn't clear a page references are added.

I could go on all day describing the ideas I use in designing schematics an d why, sometimes, schematics aren't the best way to describe a design. Lar ge, digital designs often have a number of large chips interconnected by bu ses so that very little information is contained in the "picture" of the de sign. A schematic can be replaced with a block diagram showing boxes for c hips and lines for buses without all the detail required to make it a schem atic. The net lists would be better off as tables for each bus showing eac h of the nets as rows and columns for the chip numbers with the pin numbers as the table elements. It is literally the same thing as looking at that chip in a schematic, except that you can see ALL the chips and pin numbers in one spot. No page flipping to find the other end of that wire.

No need to muck with the graphics when a pin number mistake is found. Need a bus to go to another chip? Add a line to the diagram and a column to th e appropriate table. I say this, but I have not done it yet. It just seem s like many schematics don't really provide good visual information anyway. People just throw unrelated parts on a page and other parts on another pa ge until the design is all there. So why bother with all the fuss of schem atics? Block diagrams and tables.

sn't about picking up really. It's about issues of multiple pages. They d on't really support a flat, multi-page schematic. It must be hierarchical. So to have a two page schematic, you must have a top sheet and one or mor e lower sheets.

ages. That seems oddly inconsistent.

page at a time in enough detail to make it useful, so you really need a hi erachy to provide a structure that you can wander around. Wandering from on e page to the next in a flat structure is a situation where you can easily get yourself lost.

My hierarchy is that there are two pages to the design... figure it out, it ain't rocket science.

In the case of the FF you can expect this component to be reused many times so the pin can't be the same name as your net.

For the software, the variable may be passed in by reference or by value. In one case it is the same "wire", in the other case it is not. On a board net foo is thought to run to every chip on the board that is shown in the schematic. If the net name changes it is confusing for anyone viewing the schematics.

I worked on a job where the main designer was a software guy and renamed ne ts all over the place. When the customer tried to review the design they h ad so much trouble following the nets. Bad idea unless you have identical modules in which case the external nets will either be tied in which case t hey can share a name, or they won't be tied in which case it likely will be appropriate to use a numbered bus for the signals.

Then there will be some designs that have reuse of modules that are simply the same functions in unrelated sections. Unless it is a lot of circuitry, draw it again.

That sort of naming is only needed when designs are randomly split over man y pages and boards like in the 70's. Typically a design is really on a sin gle board and the sections of the design are truly modular and the schemati c can reflect that... sometimes.

That's not a flat design. Larkin is talking about flat designs.

Even so, it's easy to deal with the terminator issue. Molten iron usually takes care of him.

I attempted to preserve some indication of design rather than just placemen t once on a board that was long and narrow so I thought the numbers would m atch up fairly well. I was wrong. Even though I had complete control it w as a bit of a mess because keeping the system through changes was impossibl e. I used the postal method of odd numbers on top and even numbers on the bottom until changes made that impossible without jumping to 100+ numbers t hat would be off the end of the board, lol. So there are a couple of numbe rs on the wrong side of the board.

Better to just number "semi" sequentially based on distance from a corner o f the board, skipping 2 out of 10 to leave room for updates without ruining all semblance of documentation. I don't know any software that does this, but I will work on that for KiCad on this board I'm doing now.

If the connections are numerous and disjoint, then he is right. You get a top level rat's nest.

If it's not complexity to Larkin, it's not complexity. Isn't that simple e nough for everyone?

If you are good to manufacturing and give them ODB++ files things may be fine. Otherwise don't walk through their section or you may get a voltmeter probe in your back.

What else would you expect?

If someone asked me to make a 5th order polynomial for calibration, I'd say "No. Let's look at the system and see how to handle it /properly/". Any polynomial above 3rd order is likely (not guaranteed, but likely) to be wrong - over-fitted, unstable, or both.

Sure - /if/ you've got the right hardware, and proper specifications for the task. As Tom says, getting the hardware/software combination right is critical.

It is worth pointing out that all of those examples are (almost certainly) very different to general purpose software and, especially, to application servers and the applications that run within them.

Ditto your organisation and the organisations that write/maintain such codebases.

Thus it is unsurprising that you do not understand modern medium/large scale software and software practices. Especially the congruences with medium/large scale hardware.

That's not a problem per se; everybody is inexperienced at most things.