KiCad Spice, Anyone Tried It?

On Thursday, June 4, 2020 at 6:01:18 AM UTC+10, John Larkin wrote:
> On Wed, 3 Jun 2020 17:54:34 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
> 
> >On 03/06/20 17:33, jlarkin@highlandsniptechnology.com wrote:
> >> On Wed, 3 Jun 2020 17:10:12 +0100, Tom Gardner
> >> <spamjunk@blueyonder.co.uk> wrote:
> >> 
> >>> On 03/06/20 16:41, jlarkin@highlandsniptechnology.com wrote:
> >>>> On Wed, 3 Jun 2020 14:14:03 +0100, Tom Gardner
> >>>> <spamjunk@blueyonder.co.uk> wrote:
> >>>>
> >>>>> On 03/06/20 13:18, jlarkin@highlandsniptechnology.com wrote:
> >>>>>> On Wed, 3 Jun 2020 10:36:07 +0100, Tom Gardner
> >>>>>> <spamjunk@blueyonder.co.uk> wrote:
> >>>>>>
> >>>>>>> On 03/06/20 08:34, Ricketty C wrote:

<snip>

> >> How does a heirarichal schematic make it easier to find connections on
> >> the schematic, or a physical part on a board?
> >
> >You can trace connections with your eye (or finger!) on the
> >schematic.
> 
> The hierarichal schematics that I've seen, signals go into instances
> of boxes, and change net name inside each box. No thanks.

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.

<snip>

-- 
Bill Sloman, Sydney

On Wednesday, June 3, 2020 at 6:32:55 PM UTC-4, Lasse Langwadt Christensen wrote:
> onsdag den 3. juni 2020 kl. 23.51.57 UTC+2 skrev John Larkin:
> > On Wed, 3 Jun 2020 13:56:02 -0700 (PDT), Lasse Langwadt Christensen
> > <langwadt@fonz.dk> wrote:
> > 
> > >onsdag den 3. juni 2020 kl. 22.11.44 UTC+2 skrev John Larkin:
> > >> On Wed, 3 Jun 2020 10:21:50 -0700 (PDT), Lasse Langwadt Christensen
> > >> <langwadt@fonz.dk> wrote:
> > >> 
> > >> >onsdag den 3. juni 2020 kl. 14.18.53 UTC+2 skrev jla...@highlandsniptechnology.com:
> > >> >> On Wed, 3 Jun 2020 10:36:07 +0100, Tom Gardner
> > >> >> <spamjunk@blueyonder.co.uk> wrote:
> > >> >> 
> > >> >> >On 03/06/20 08:34, Ricketty C wrote:
> > >> >> >> I guess I spoke too soon about KiCad being easy to pick up... well it isn't
> > >> >> >> about picking up really.  It's about issues of multiple pages.  They don'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 more lower
> > >> >> >> sheets.
> > >> >> >
> > >> >> >As someone that hasn't used KiCad yet, but expects to soon, my
> > >> >> >comment is "excellent" :)
> > >> >> >
> > >> >> >I have three peeves about many schematics that I see:
> > >> >> >   - principal signal flow in any random direction
> > >> >> >   - if a wire leaves one schematic, it isn't clear which
> > >> >> >     other schematic(s) is reappears on
> > >> >> >   - signal/bus wires that are named but not visually connected
> > >> >> >
> > >> >> >The latter really pisses me off, since on a PDF I have to
> > >> >> >use ctrl-f to understand connectivity, and the schematic cannot
> > >> >> >be usefully printed out.
> > >> >> >
> > >> >> >No, it isn't merely modern diagrams that do that, you also
> > >> >> >find it in old Tek schematics.
> > >> >> >
> > >> >> 
> > >> >> I hate hierarchicals and busses and any abstraction that hides what's
> > >> >> actually on the board. I do everything flat... currently a 31-page
> > >> >> schematic with five basically identical output channels, each on its
> > >> >> own sheet. I know exactly where R114 is.
> > >> >
> > >> >since it is R1xx on page 1
> > >> 
> > >> After a PCB layout is done, we resequence the reference designators in
> > >> the physical pattern that manufacturing and testing like, sort of
> > >> raster scan from lower-left, and we back-annotate the schematic.
> > >
> > >it's all matter of preference, leave it like the schematic editor does it 
> > >and you knnow what page it is and those components a around section of components have designators close together
> > >
> > >> 
> > >> >
> > >> >> 
> > >> >> I do start a schematic with sheet 1 being the block diagram and sheet
> > >> >> list/table of contents. Sheets have both numbers and names in the PADS
> > >> >> pulldown menu.
> > >> >
> > >> >so whats the difference? I have a page 1 with a number of blocks and how 
> > >> >they are connected each of those blocks is a schematic.
> > >> 
> > >> My block diagram is architectural and functional. If I did a sheet 1
> > >> as a hierarchical structure that actually created all the connections,
> > >> it would be an unreadable nightmare.
> > >> 
> > >
> > >how do you connect between pages then, global labels?
> > 
> > Yes, we call them off-page connections, or just off-pages. Sometimes
> > they connect on the same page.
> > 
> 
> you can do exactly the same in kicads hierarchical schematic, so if you want 
> to there can be very little difference, basically only difference is that 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 talk about connecting the pages with global nets which apparently are like power 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.  Having to fit everything on a single page is a PITA even when you can select arbitrary page sizes because then the pages get so big they are hard to navigate.  

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

-- 

  Rick C.

  --- Get 1,000 miles of free Supercharging
  --- Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 4:02:05 AM UTC-4, Lasse Langwadt Christensen wrote:
> onsdag den 3. juni 2020 kl. 04.04.47 UTC+2 skrev Ricketty C:
> > On Tuesday, June 2, 2020 at 1:56:49 PM UTC-4, Lasse Langwadt Christensen wrote:
> > > 
> > > most part are standard footprints so just pick the part and the right footprint
> > > afaiu the rotation is different because Kicad uses the standard for where pin 1 should be, jlcpcb uses the way the part is in the tape
> > 
> > I'm not sure what you are saying with this.  Are you talking about the 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 indicates how much to turn the part rather than where it should be?  I'm just not following this. 
> > 
> 
> the files has placement and rotation, Kicad and jlcpcb has different definitions 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.  The machine operator can set the orientation on the tape as well as the position of the PWB letting the machine understand what it needs to do to achieve 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 different orientations.  WTF???  Yes, let the machine operator handle it.  


> > I've never understood why pin 1 orientation is such a complex issue.  But I do know it fails from time to time. 
> > 
> 
> for say a TQFP there's four ways you can decide to call 0 degrees, which one 
> do you pick?

IPC has a standard for that.  ICs and other device that fit some clear definition 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-standard way?  JLPCB is a company.  Why would they want to be in the standards setting business rather than following them???

-- 

  Rick C.

  --+ Get 1,000 miles of free Supercharging
  --+ Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 5:36:12 AM UTC-4, Tom Gardner wrote:
> On 03/06/20 08:34, Ricketty C wrote:
> > I guess I spoke too soon about KiCad being easy to pick up... well it isn't
> > about picking up really.  It's about issues of multiple pages.  They don'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 more lower
> > sheets.
> 
> As someone that hasn't used KiCad yet, but expects to soon, my
> comment is "excellent" :)
> 
> I have three peeves about many schematics that I see:
>    - principal signal flow in any random direction
>    - if a wire leaves one schematic, it isn't clear which
>      other schematic(s) is reappears on
>    - signal/bus wires that are named but not visually connected
> 
> The latter really pisses me off, since on a PDF I have to
> use ctrl-f to understand connectivity, and the schematic cannot
> be usefully printed out.
> 
> No, it isn't merely modern diagrams that do that, you also
> find it in old Tek schematics.

Not sure how KiCad hierarchical pages help with that.  All the recommendations 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 pointing toward the other end of the jump.  If there are multiple jumps on a single net, point them all to a single common point with pointers back to each one.  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 and why, sometimes, schematics aren't the best way to describe a design.  Large, digital designs often have a number of large chips interconnected by buses so that very little information is contained in the "picture" of the design.  A schematic can be replaced with a block diagram showing boxes for chips and lines for buses without all the detail required to make it a schematic.  The net lists would be better off as tables for each bus showing each 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 the appropriate table.  I say this, but I have not done it yet.  It just seems like many schematics don't really provide good visual information anyway.  People just throw unrelated parts on a page and other parts on another page until the design is all there.  So why bother with all the fuss of schematics?  Block diagrams and tables. 

-- 

  Rick C.

  -+- Get 1,000 miles of free Supercharging
  -+- Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 9:24:45 AM UTC-4, Bill Sloman wrote:
> On Wednesday, June 3, 2020 at 5:34:28 PM UTC+10, Ricketty C wrote:
> > I guess I spoke too soon about KiCad being easy to pick up... well it isn't about picking up really.  It's about issues of multiple pages.  They don'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 more lower sheets.  
> > 
> > The parts can have multiple units, but schematics can't have multiple pages.  That seems oddly inconsistent. 
> 
> Not really. The trouble with displays is that you can really only see one page at a time in enough detail to make it useful, so you really need a hierachy to provide a structure that you can wander around. Wandering from one 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. 

-- 

  Rick C.

  -++ Get 1,000 miles of free Supercharging
  -++ Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 7:06:56 PM UTC-4, Tom Gardner wrote:
> On 03/06/20 21:01, John Larkin wrote:
> > 
> > The heirarichal schematics that I've seen, signals go into instances
> > of boxes, and change net name inside each box. No thanks.
> 
> 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);

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 nets all over the place.  When the customer tried to review the design they had 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 they 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.  


> 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.

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


> > My channels are not always identical anyhow. I might decide to use
> > three bypass caps over 5 channels. Or put the clock terminator in one.
> > Or change a part value in one.
> 
> I'll assume that by "channel" you might mean "replicated
> subcomponent".
> 
> What happens where the subcomponents/channels are identical
> and both contain an R114?

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. 

-- 

  Rick C.

  +-- Get 1,000 miles of free Supercharging
  +-- Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 7:11:29 PM UTC-4, Tom Gardner wrote:
> On 03/06/20 21:11, John Larkin wrote:
> > 
> > After a PCB layout is done, we resequence the reference designators in
> > the physical pattern that manufacturing and testing like, sort of
> > raster scan from lower-left, and we back-annotate the schematic.
> 
> So a low-pass filter R59-C59 might become R131-C7?
> 
> Unambiguous, but aesthetically unpleasing to me.

I attempted to preserve some indication of design rather than just placement once on a board that was long and narrow so I thought the numbers would match up fairly well.  I was wrong.  Even though I had complete control it was a bit of a mess because keeping the system through changes was impossible.  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 that would be off the end of the board, lol.  So there are a couple of numbers on the wrong side of the board. 

Better to just number "semi" sequentially based on distance from a corner of 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. 


> > My block diagram is architectural and functional. If I did a sheet 1
> > as a hierarchical structure that actually created all the connections,
> > it would be an unreadable nightmare.
> 
> That is only sufficient on a small scale.

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


> > Sounds like complexity for its own sake. Many engineers like to do
> > that, as opposed to just getting the job done. They come up with
> > bizarre justifications for doing elaborate things.
> 
> You have chosen a different form of complexity.

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

-- 

  Rick C.

  +-+ Get 1,000 miles of free Supercharging
  +-+ Tesla referral code - https://ts.la/richard11209

On Wednesday, June 3, 2020 at 4:56:07 PM UTC-4, Lasse Langwadt Christensen wrote:
> onsdag den 3. juni 2020 kl. 22.11.44 UTC+2 skrev John Larkin:
> > 
> > After a PCB layout is done, we resequence the reference designators in
> > the physical pattern that manufacturing and testing like, sort of
> > raster scan from lower-left, and we back-annotate the schematic.
> 
> it's all matter of preference, leave it like the schematic editor does it 
> and you knnow what page it is and those components a around section of components have designators close together

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. 


> > Sounds like complexity for its own sake. Many engineers like to do
> > that, as opposed to just getting the job done. They come up with
> > bizarre justifications for doing elaborate things.
> > 
> 
> kettle black ;)

What else would you expect? 

-- 

  Rick C.

  ++- Get 1,000 miles of free Supercharging
  ++- Tesla referral code - https://ts.la/richard11209

On 04/06/2020 01:59, John Larkin wrote:
> 
> 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.
> 

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.

>>
>> 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.
> 
> 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?
> 

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.

On 04/06/20 00:59, John Larkin wrote:
> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
> 
>> On 03/06/20 21:21, John Larkin wrote:
>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner
>>> <spamjunk@blueyonder.co.uk> wrote:
>>>>
>>>> The similarities outweigh the differences.
>>>
>>> The similarities of that statement, six times, are tedious.
>>
>> Your misapprehensions on this topic are legion
>> and repetitive.
>>
>>
>>> Do you design electronics?
>>
>> 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.)
> 
> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred
> embedded programs, 
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.