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
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 3, 20202020-06-03
Reply by ●June 3, 20202020-06-03
On Wed, 3 Jun 2020 15:32:50 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> 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 > >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. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 3, 20202020-06-03
On 03/06/20 21:01, 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: >>>>>>>>> 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. >>>>>> >>>>>> Yes, but what if you are presented with someone else's >>>>>> schematic like that, and you need to find /all/ the >>>>>> components connected to R114. >>>>> >>>>> I click a pin and the project explorer shows me the net name and all >>>>> the connections. I click one of them and it jumps there. >>>>> >>>>> A heirarichal schematic is worse! >>>> >>>> Fine for the author. What about a customer (or other) that >>>> doesn't have access to your schematic program? >>> >>> We rarely allow customers to see schematics. A trusted one, or one who >>> pays, can have the PADS files and a PDF of the entire schematic. Many >>> other pcb programs will open PADS files. The viewers are free from >>> Mentor. >> >> OK. That's one common case, but many situations aren't like that. >> >> >>> It's essentially impossible for a customer to maintain our products; >>> each needs a rack full of gear to test and cal. >> >> OK. That's one common case, but many situations aren't like that. >> >> >>> 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 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);> >> >> It doesn't help finding a component on the PCB, but that >> information isn't in the schematic anyway. > > R114 is on my schematic and on my PCB. The reference designator (50 > mils high, 6 wide lines) fits next to the resistor on the top silk.Of course.> What does a refdes look like on a heirarichal-schematic PCB?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.> 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?>>>>>> Finding your way around your own schematics is comparatively >>>>>> easy and reliable. >>>>> >>>>> I've drawn thousands of schematics. I can't remember them all. With >>>>> decent discipline and good tools, I don't have to. >>>>> >>>>> I can open and work on a PADS schematic or PCB that we did 25 years >>>>> ago. >>>> >>>> Fine, apart from the above caveat. >>>> What about in another 25 years? >>>> >>>> I'll bet PDFs and dead trees will still be readable then. >>>> >>> >>> We don't keep paper copies of schematics or layouts. I agree that >>> PDFs, and the ability to read from USB hard drives, will be around for >>> the life of the equipment. >> >> I /might/ keep paper copies, for legal reasons.
Reply by ●June 3, 20202020-06-03
On 03/06/20 21:11, John Larkin wrote:> 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.So a low-pass filter R59-C59 might become R131-C7? Unambiguous, but aesthetically unpleasing to me.>>> 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.That is only sufficient on a small scale.> It is possible to more than one block point to the same schematic but > it doesn't have to, each can >> have its own so it just like your multipage schematic >> >> and if you print it you get all the pages even if some of them are the same except for designators > > 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.
Reply by ●June 3, 20202020-06-03
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: > >> On 03/06/20 16:51, jlarkin@highlandsniptechnology.com wrote: >>> On Wed, 3 Jun 2020 15:21:21 +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. >>>>> >>>>> The parts can have multiple units, but schematics can't have multiple pages. >>>>> That seems oddly inconsistent. >>>> >>>> Another viewpoint is to consider the analogous situation in >>>> large-scale software systems. >>>> >>>> For one person developing a small piece of code, nothing much >>>> is needed. >>>> >>>> But in a large system that requires modification over the years, >>>> it has been found necessary to develop techniques that have >>>> the same characteristics as hierarchical hardware schematics. >>>> >>>> Example 1: all the various UML structural component diagrams. >>>> >>>> Example 2: the currently fashionable "inversion of control" >>>> techniques. If you sit down and think about what they are >>>> attempting to rectify, and how they are doing it, then you >>>> see they are connecting stand-alone components and sub-components >>>> in a hierarchy. >> >> I don't think you are aware of what's in medium and >> large scale software. > > I am aware that a big program will have thousands of bugs in its > lifetime, and may be remotely updated every month or so.Irrelevant. The points are equally valid for designs cast in concrete.>>> A PCB is very different from code. Multiple copies have to be >>> assembled my manufacturing, >> >> The similarities outweigh the differences. > > We don't prototype and expect rev A to be built by production, to > released drawings, and we expect it to work and be shipped. The first > release that we test, we expect to ship to a paying customer. > > Does anyone do software that way?Irrelevant.>> Simple examples: operating systems, servers, server >> applications. >> >> >>> from purchased or fabricated parts. >> >> The similarities outweigh the differences. >> >> Simple examples: libraries, servers. >> >> >>> Each board needs to be inspected and tested. >> >> The similarities outweigh the differences. >> >> Simple examples: one application installed in different >> servers optionally in different companies. >> >> >>> If changes must be made, they >>> will be applied, per an ECO, to every board, by manufacturing. >> >> The similarities outweigh the differences. >> >> Simple examples: each application installed in each server. >> >> >>> Field changes are physical and expensive. >> >> 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.)>> Arguably it is more difficult to correctly change software. > > ??? Hardware change requires releasing an ECO, getting physical access > to the product, and doing mechanical things, then testing and > calibrating.With the exception of "doing mechanical things", I've had to do all that with software. It was always a pain.>>> A computer program doesn't need many identical copies of a subroutine. >>> A circuit board often does, but they usually wind up be not quite >>> exactly identical. They are certainly physically distinct, even if >>> they look alike on paper. >> >> The similarities outweigh the differences. > > Oh please. Repeating a thing N times doesn't make it true.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....>> Simple examples: objects, classes, and class hierarchies, >> definitions of things such as "a person" or "the time". >> >> >>> Computer programs don't need ground or power planes. >> >> Agreed, but so what! >> >> >>> They should have >>> test points and BIST, but they seldom do. >> >> No difference :( >> >> >>> Very different. >> >> Nope. > > Do you design electronics? Schematics, pcb layouts, parts on boards?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.> Few posters to s.e.d. actually do. Fewer are very good at it.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.
Reply by ●June 3, 20202020-06-03
On Thu, 4 Jun 2020 00:11:24 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 03/06/20 21:11, John Larkin wrote: >> 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. > >So a low-pass filter R59-C59 might become R131-C7? > >Unambiguous, but aesthetically unpleasing to me.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.> > >>>> 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. > >That is only sufficient on a small scale.How about 24 channels of lvdt/synchro/resolver input/output on one board?> > >> It is possible to more than one block point to the same schematic but >> it doesn't have to, each can >>> have its own so it just like your multipage schematic >>> >>> and if you print it you get all the pages even if some of them are the same except for designators >> >> 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.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. https://www.altium.com/documentation/altium-designer/multi-sheet-and-multi-channel-design-ad?version=18.1 That's version 18.1! -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 3, 20202020-06-03
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: >> >>> On 03/06/20 16:51, jlarkin@highlandsniptechnology.com wrote: >>>> On Wed, 3 Jun 2020 15:21:21 +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. >>>>>> >>>>>> The parts can have multiple units, but schematics can't have multiple pages. >>>>>> That seems oddly inconsistent. >>>>> >>>>> Another viewpoint is to consider the analogous situation in >>>>> large-scale software systems. >>>>> >>>>> For one person developing a small piece of code, nothing much >>>>> is needed. >>>>> >>>>> But in a large system that requires modification over the years, >>>>> it has been found necessary to develop techniques that have >>>>> the same characteristics as hierarchical hardware schematics. >>>>> >>>>> Example 1: all the various UML structural component diagrams. >>>>> >>>>> Example 2: the currently fashionable "inversion of control" >>>>> techniques. If you sit down and think about what they are >>>>> attempting to rectify, and how they are doing it, then you >>>>> see they are connecting stand-alone components and sub-components >>>>> in a hierarchy. >>> >>> I don't think you are aware of what's in medium and >>> large scale software. >> >> I am aware that a big program will have thousands of bugs in its >> lifetime, and may be remotely updated every month or so. > >Irrelevant. > >The points are equally valid for designs cast in concrete. > > >>>> A PCB is very different from code. Multiple copies have to be >>>> assembled my manufacturing, >>> >>> The similarities outweigh the differences. >> >> We don't prototype and expect rev A to be built by production, to >> released drawings, and we expect it to work and be shipped. The first >> release that we test, we expect to ship to a paying customer. >> >> Does anyone do software that way? > >Irrelevant. > > >>> Simple examples: operating systems, servers, server >>> applications. >>> >>> >>>> from purchased or fabricated parts. >>> >>> The similarities outweigh the differences. >>> >>> Simple examples: libraries, servers. >>> >>> >>>> Each board needs to be inspected and tested. >>> >>> The similarities outweigh the differences. >>> >>> Simple examples: one application installed in different >>> servers optionally in different companies. >>> >>> >>>> If changes must be made, they >>>> will be applied, per an ECO, to every board, by manufacturing. >>> >>> The similarities outweigh the differences. >>> >>> Simple examples: each application installed in each server. >>> >>> >>>> Field changes are physical and expensive. >>> >>> 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, 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.> > > >>> Arguably it is more difficult to correctly change software. >> >> ??? Hardware change requires releasing an ECO, getting physical access >> to the product, and doing mechanical things, then testing and >> calibrating. > >With the exception of "doing mechanical things", I've had >to do all that with software. It was always a pain.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.> > >>>> A computer program doesn't need many identical copies of a subroutine. >>>> A circuit board often does, but they usually wind up be not quite >>>> exactly identical. They are certainly physically distinct, even if >>>> they look alike on paper. >>> >>> The similarities outweigh the differences. >> >> Oh please. Repeating a thing N times doesn't make it true. > >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....Mistake? I design stuff, it works almost always first try, and we sell it.> > >>> Simple examples: objects, classes, and class hierarchies, >>> definitions of things such as "a person" or "the time". >>> >>> >>>> Computer programs don't need ground or power planes. >>> >>> Agreed, but so what! >>> >>> >>>> They should have >>>> test points and BIST, but they seldom do. >>> >>> No difference :( >>> >>> >>>> Very different. >>> >>> Nope. >> >> Do you design electronics? Schematics, pcb layouts, parts on boards? > >I have done, for several decades, but I am now happily retired.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.> >I also spent some decades on the dark side (software), >and so am intimately acquainted with their similarities >and differences. > > >> Few posters to s.e.d. actually do. Fewer are very good at it. > >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.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? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 3, 20202020-06-03
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: >>> >>>> On 03/06/20 16:51, jlarkin@highlandsniptechnology.com wrote: >>>>> On Wed, 3 Jun 2020 15:21:21 +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. >>>>>>> >>>>>>> The parts can have multiple units, but schematics can't have multiple pages. >>>>>>> That seems oddly inconsistent. >>>>>> >>>>>> Another viewpoint is to consider the analogous situation in >>>>>> large-scale software systems. >>>>>> >>>>>> For one person developing a small piece of code, nothing much >>>>>> is needed. >>>>>> >>>>>> But in a large system that requires modification over the years, >>>>>> it has been found necessary to develop techniques that have >>>>>> the same characteristics as hierarchical hardware schematics. >>>>>> >>>>>> Example 1: all the various UML structural component diagrams. >>>>>> >>>>>> Example 2: the currently fashionable "inversion of control" >>>>>> techniques. If you sit down and think about what they are >>>>>> attempting to rectify, and how they are doing it, then you >>>>>> see they are connecting stand-alone components and sub-components >>>>>> in a hierarchy. >>>> >>>> I don't think you are aware of what's in medium and >>>> large scale software. >>> >>> I am aware that a big program will have thousands of bugs in its >>> lifetime, and may be remotely updated every month or so. >> >> Irrelevant. >> >> The points are equally valid for designs cast in concrete. >> >> >>>>> A PCB is very different from code. Multiple copies have to be >>>>> assembled my manufacturing, >>>> >>>> The similarities outweigh the differences. >>> >>> We don't prototype and expect rev A to be built by production, to >>> released drawings, and we expect it to work and be shipped. The first >>> release that we test, we expect to ship to a paying customer. >>> >>> Does anyone do software that way? >> >> Irrelevant. >> >> >>>> Simple examples: operating systems, servers, server >>>> applications. >>>> >>>> >>>>> from purchased or fabricated parts. >>>> >>>> The similarities outweigh the differences. >>>> >>>> Simple examples: libraries, servers. >>>> >>>> >>>>> Each board needs to be inspected and tested. >>>> >>>> The similarities outweigh the differences. >>>> >>>> Simple examples: one application installed in different >>>> servers optionally in different companies. >>>> >>>> >>>>> If changes must be made, they >>>>> will be applied, per an ECO, to every board, by manufacturing. >>>> >>>> The similarities outweigh the differences. >>>> >>>> Simple examples: each application installed in each server. >>>> >>>> >>>>> Field changes are physical and expensive. >>>> >>>> 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, 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. > > > >> >> >> >>>> Arguably it is more difficult to correctly change software. >>> >>> ??? Hardware change requires releasing an ECO, getting physical access >>> to the product, and doing mechanical things, then testing and >>> calibrating. >> >> With the exception of "doing mechanical things", I've had >> to do all that with software. It was always a pain. > > 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. > > > > >> >> >>>>> A computer program doesn't need many identical copies of a subroutine. >>>>> A circuit board often does, but they usually wind up be not quite >>>>> exactly identical. They are certainly physically distinct, even if >>>>> they look alike on paper. >>>> >>>> The similarities outweigh the differences. >>> >>> Oh please. Repeating a thing N times doesn't make it true. >> >> 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.... > > Mistake? I design stuff, it works almost always first try, and we sell > it. > > > > >> >> >>>> Simple examples: objects, classes, and class hierarchies, >>>> definitions of things such as "a person" or "the time". >>>> >>>> >>>>> Computer programs don't need ground or power planes. >>>> >>>> Agreed, but so what! >>>> >>>> >>>>> They should have >>>>> test points and BIST, but they seldom do. >>>> >>>> No difference :( >>>> >>>> >>>>> Very different. >>>> >>>> Nope. >>> >>> Do you design electronics? Schematics, pcb layouts, parts on boards? >> >> I have done, for several decades, but I am now happily retired. > > 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. > > >> >> I also spent some decades on the dark side (software), >> and so am intimately acquainted with their similarities >> and differences. >> >> >>> Few posters to s.e.d. actually do. Fewer are very good at it. >> >> 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. > > 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.Most definitely :)> I do have a hard time pinning the c people down to times. Can you run > that IRQ at 200 KHz for me?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).
Reply by ●June 3, 20202020-06-03
On Wednesday, June 3, 2020 at 4:22:07 PM UTC-4, John Larkin wrote:> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > > >On 03/06/20 16:51, jlarkin@highlandsniptechnology.com wrote: > >> On Wed, 3 Jun 2020 15:21:21 +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. > >>>> > >>>> The parts can have multiple units, but schematics can't have multiple pages. > >>>> That seems oddly inconsistent. > >>> > >>> Another viewpoint is to consider the analogous situation in > >>> large-scale software systems. > >>> > >>> For one person developing a small piece of code, nothing much > >>> is needed. > >>> > >>> But in a large system that requires modification over the years, > >>> it has been found necessary to develop techniques that have > >>> the same characteristics as hierarchical hardware schematics. > >>> > >>> Example 1: all the various UML structural component diagrams. > >>> > >>> Example 2: the currently fashionable "inversion of control" > >>> techniques. If you sit down and think about what they are > >>> attempting to rectify, and how they are doing it, then you > >>> see they are connecting stand-alone components and sub-components > >>> in a hierarchy. > > > >I don't think you are aware of what's in medium and > >large scale software. > > I am aware that a big program will have thousands of bugs in its > lifetime, and may be remotely updated every month or so. > > > > > > >> A PCB is very different from code. Multiple copies have to be > >> assembled my manufacturing, > > > >The similarities outweigh the differences. > > We don't prototype and expect rev A to be built by production, to > released drawings, and we expect it to work and be shipped. The first > release that we test, we expect to ship to a paying customer. > > Does anyone do software that way? > > > > > > > >Simple examples: operating systems, servers, server > >applications. > > > > > >> from purchased or fabricated parts. > > > >The similarities outweigh the differences. > > > >Simple examples: libraries, servers. > > > > > >> Each board needs to be inspected and tested. > > > >The similarities outweigh the differences. > > > >Simple examples: one application installed in different > >servers optionally in different companies. > > > > > >> If changes must be made, they > >> will be applied, per an ECO, to every board, by manufacturing. > > > >The similarities outweigh the differences. > > > >Simple examples: each application installed in each server. > > > > > >> Field changes are physical and expensive. > > > >The similarities outweigh the differences. > > The similarities of that statement, six times, are tedious. > > Do you design electronics? > > > > >Arguably it is more difficult to correctly change software. > > ??? Hardware change requires releasing an ECO, getting physical access > to the product, and doing mechanical things, then testing and > calibrating. > > > > > > >> A computer program doesn't need many identical copies of a subroutine. > >> A circuit board often does, but they usually wind up be not quite > >> exactly identical. They are certainly physically distinct, even if > >> they look alike on paper. > > > >The similarities outweigh the differences. > > Oh please. Repeating a thing N times doesn't make it true. > > > > >Simple examples: objects, classes, and class hierarchies, > >definitions of things such as "a person" or "the time". > > > > > >> Computer programs don't need ground or power planes. > > > >Agreed, but so what! > > > > > >> They should have > >> test points and BIST, but they seldom do. > > > >No difference :( > > > > > >> Very different. > > > >Nope. > > Do you design electronics? Schematics, pcb layouts, parts on boards? > > Few posters to s.e.d. actually do. Fewer are very good at it. > > > > > > -- > > John Larkin Highland Technology, Inc > picosecond timing precision measurement > > jlarkin att highlandtechnology dott com > http://www.highlandtechnology.com> > Does anyone do software that way?Yes they do, or they are taught that way. The perspective of 'sw is easy to change if we don't get it right' is at least 30 year old school. Software gets 'wrong' for a lot of reasons-too many to enumerate here. For example, 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 the hardware 'wrong'? Sw is not designed in a vacuum and when system requiremetns change, all bets are off...> A computer program doesn't need many identical copies of a subroutine.It certainly can and many safety critical system do. Some redundancy techniques 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
Reply by ●June 3, 20202020-06-03
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: > >>>>>>>> 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. > >>>>> > >>>>> Yes, but what if you are presented with someone else's > >>>>> schematic like that, and you need to find /all/ the > >>>>> components connected to R114. > >>>> > >>>> I click a pin and the project explorer shows me the net name and all > >>>> the connections. I click one of them and it jumps there. > >>>> > >>>> A heirarichal schematic is worse! > >>> > >>> Fine for the author. What about a customer (or other) that > >>> doesn't have access to your schematic program? > >> > >> We rarely allow customers to see schematics. A trusted one, or one who > >> pays, can have the PADS files and a PDF of the entire schematic. Many > >> other pcb programs will open PADS files. The viewers are free from > >> Mentor. > > > >OK. That's one common case, but many situations aren't like that. > > > > > >> It's essentially impossible for a customer to maintain our products; > >> each needs a rack full of gear to test and cal. > > > >OK. That's one common case, but many situations aren't like that. > > > > > >> 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 heirarichal schematics that I've seen, signals go into instances > of boxes, and change net name inside each box. No thanks. > > > > >It doesn't help finding a component on the PCB, but that > >information isn't in the schematic anyway. > > R114 is on my schematic and on my PCB. The reference designator (50 > mils high, 6 wide lines) fits next to the resistor on the top silk. > What does a refdes look like on a heirarichal-schematic PCB?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.> 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.So what? <snip> -- Bill Sloman, Sydney
