JL wrote an interesting post in the depths of the "better
microelectronics from coal" thread that I thought was worth pulling out
on its own.

On 2024-01-21 10:12, John Larkin wrote:>

"...what IS electronic
> design, and what's the best way to do it? <snip>
>
> Short answer, cobbling. When presented with a problem or an
> opportunity to design electronics, the most efficient way to do that
> is to grab a piece of paper and immediately sketch a circuit or an
> assembly. Sometimes one can do that instantly, without thinking, or
> sometimes one can ignore the issue for a few days and then the design
> pops up. Sometimes brainstorming and whiteboarding help. Sometimes
> fiddling with Spice helps.
>
> All that literature research and math analysis and simulation and
> breadboarding and prototyping are just slow and expensive follow-up
> chores for people who don't have 100% confidence in their instincts.
> Analysis, sometimes prudent to do, but not design.
>
> Design is subconsious and instinctive. And it's free! And to some
> extent, it can be taught, but seldom is.
>
> Most of us design things to sell, so do whatever works. We're selling
> stuff, not publishing papers.
>

Hmm. I don't think that I agree in general, because you make it sound
as though the process were just intuitively plucking one idea out of
somewhere-or-other and cranking it out.

You've often argued in favor of brainstorming, where you get a few smart
people in front of a white board and try out ideas to find the best one
and flesh it out. We've done that together, very fruitfully.

It's possible to do more or less the same thing by oneself, but it
requires the ability to tolerate uncertainty for extended periods.
(That's a skill well worth developing, which most people are really,
really bad at, IME.)

I sometimes need to do a family of designs, rather than just one.
Recently I've been working on some very fast, very cheap SPAD preamps,
intended to go in the guts of positron-emission scanners.

Designs with lots of real-world constraints are often the most fun, and
this one's specs include: 300-ps edges with 100-ps timing repeatability
from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
(You need a whole lot of channels, and PET and MRI machines are often
combined.)

I do a fair amount of analysis of circuits of that sort, to figure out
what actually limits their performance. It isn't super detailed--in
this case, just enough to figure out whether it'll be the base-emitter
time constant, the Miller effect, or the SPAD's series resistance that
will be the limiting factor.

Miller, I can deal with using circuit hacks. The BE time constant is
Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
device parameter--to get a big improvement you have to change
transistors. The SPAD can be negotiable depending on whose process
you're making them on--when each machine needs thousands of them,
vendors tend to listen.

Eventually, of course, you have to pick one and go with it, but picking
a topology usually takes me an iteration or two.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>JL wrote an interesting post in the depths of the "better
>microelectronics from coal" thread that I thought was worth pulling out
>on its own.
>
>On 2024-01-21 10:12, John Larkin wrote:>
>
>"...what IS electronic
> > design, and what's the best way to do it? <snip>
> >
> > Short answer, cobbling. When presented with a problem or an
> > opportunity to design electronics, the most efficient way to do that
> > is to grab a piece of paper and immediately sketch a circuit or an
> > assembly. Sometimes one can do that instantly, without thinking, or
> > sometimes one can ignore the issue for a few days and then the design
> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
> > fiddling with Spice helps.
> >
> > All that literature research and math analysis and simulation and
> > breadboarding and prototyping are just slow and expensive follow-up
> > chores for people who don't have 100% confidence in their instincts.
> > Analysis, sometimes prudent to do, but not design.
> >
> > Design is subconsious and instinctive. And it's free! And to some
> > extent, it can be taught, but seldom is.
> >
> > Most of us design things to sell, so do whatever works. We're selling
> > stuff, not publishing papers.
> >
>
>Hmm. I don't think that I agree in general, because you make it sound
>as though the process were just intuitively plucking one idea out of
>somewhere-or-other and cranking it out.

If an idea is new, where else would come from?

>
>You've often argued in favor of brainstorming, where you get a few smart
>people in front of a white board and try out ideas to find the best one
>and flesh it out. We've done that together, very fruitfully.
>
>It's possible to do more or less the same thing by oneself, but it
>requires the ability to tolerate uncertainty for extended periods.
>(That's a skill well worth developing, which most people are really,
>really bad at, IME.)

The uncertainty period is probably necessary, to let ones neurons
prowl the noisy solution space. The period is usually a day or two,
but can be years.

Some engineers are uncomfortable with uncertainty, and want to lock
down a design as soon as possible, preferably something sanctioned by
some authority. I like to stay confused for a while.

>
>I sometimes need to do a family of designs, rather than just one.
>Recently I've been working on some very fast, very cheap SPAD preamps,
>intended to go in the guts of positron-emission scanners.
>
>Designs with lots of real-world constraints are often the most fun, and
>this one's specs include: 300-ps edges with 100-ps timing repeatability
>from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
>(You need a whole lot of channels, and PET and MRI machines are often
>combined.)
>
>I do a fair amount of analysis of circuits of that sort, to figure out
>what actually limits their performance. It isn't super detailed--in
>this case, just enough to figure out whether it'll be the base-emitter
>time constant, the Miller effect, or the SPAD's series resistance that
>will be the limiting factor.

Certainly quantitative reality should filter the solution space. But
even that can be mostly intuitive. I was talking about that with C on
Friday, about how some people have good quantitative intuition and
some don't. She can look at soup in a round pot and know if it will
fit into a square plastic container, to about 10%. I can do that.
Neither of our spouses can.

>
>Miller, I can deal with using circuit hacks. The BE time constant is
>Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
>device parameter--to get a big improvement you have to change
>transistors. The SPAD can be negotiable depending on whose process
>you're making them on--when each machine needs thousands of them,
>vendors tend to listen.
>
>Eventually, of course, you have to pick one and go with it, but picking
>a topology usually takes me an iteration or two.

Sometimes a circuit takes me dozens, lots of sheets in the trash can.
I think it's important to give as many ideas as possible a chance.

See Barrie Gilbert's essay "Where do little circuits come from?"

"Prod and poke" and "doodling" are suggested.

>
>Cheers
>
>Phil Hobbs

On Monday, January 22, 2024 at 10:16:12 AM UTC+11, Phil Hobbs wrote:
> JL wrote an interesting post in the depths of the "better
> microelectronics from coal" thread that I thought was worth pulling out
> on its own.
>
> On 2024-01-21 10:12, John Larkin wrote:>
>
> "...what IS electronic
> > design, and what's the best way to do it? <snip>
> >
> > Short answer, cobbling. When presented with a problem or an
> > opportunity to design electronics, the most efficient way to do that
> > is to grab a piece of paper and immediately sketch a circuit or an
> > assembly.

"Efficiency" is a ratio of a theoretically known best way of doing something with what actually happens.

There's no theory that can let you work out the "best" design for any particular application, so it's not a word that meas anything useful i this context.

In my experience the first step in any design is to work out exactly what you want to happen. Then you have to think of ways of making it happen.
Sometimes there's an obvious solution - if you are answering a frequently asked question there's often a frequently adopted solution.

New components can suggest solutions that weren't previously practical.

> > Sometimes one can do that instantly, without thinking, or
> > sometimes one can ignore the issue for a few days and then the design
> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
> > fiddling with Spice helps.

Thinking about the problem always helps. Conscious thought can often kick the sub-conscious into action, and solutions can pop up from there, but you have to put in the conscious effort to get the process started.
>
> > All that literature research and math analysis and simulation and
> > breadboarding and prototyping are just slow and expensive follow-up
> > chores for people who don't have 100% confidence in their instincts.

Sane people.

For me the hall-mark of actual design is the process of discarding one approach and trying another. John Larkin never talks about that.

It's not fun, and it doesn't make you look good, but it does clarify your thinking and let you hone in on what really matters.

> > Analysis, sometimes prudent to do, but not design.

Not John Larkin's idea of design, which is idiosycratic.

> > Design is subconsious and instinctive. And it's free! And to some
> > extent, it can be taught, but seldom is.

Design can go on in the subconscious, but it isn't free. Waking up in the middle of the night and feeling the urge to sketch a circuit diagram isn't something that makes your wife happy.
> >
> > Most of us design things to sell, so do whatever works. We're selling
> > stuff, not publishing papers.

If you have got something unique to sell. writing a paper about it is useful publicity. The instrument literature exists to inform people about solutions that people have worked up to solve academically interesting problems, but most of them are commercially interesting problems as well.

> Hmm. I don't think that I agree in general, because you make it sound
> as though the process were just intuitively plucking one idea out of
> somewhere-or-other and cranking it out.

I don't think that John Larkin actually does circuit design in the way that most people understand process. A great many circuits are produced by evolution rather than intelligent design. and quite a few of them work really well. Quite a few more can work better (and be built more cheaply) if you spend some time thinking about what they are doing. I spent about half my time industry doing just that.
> You've often argued in favor of brainstorming, where you get a few smart
> people in front of a white board and try out ideas to find the best one
> and flesh it out. We've done that together, very fruitfully.
>
> It's possible to do more or less the same thing by oneself, but it
> requires the ability to tolerate uncertainty for extended periods.
> (That's a skill well worth developing, which most people are really,
> really bad at, IME.)
>
> I sometimes need to do a family of designs, rather than just one.
> Recently I've been working on some very fast, very cheap SPAD preamps,
> intended to go in the guts of positron-emission scanners.
>
> Designs with lots of real-world constraints are often the most fun, and
> this one's specs include: 300-ps edges with 100-ps timing repeatability
> from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
> (You need a whole lot of channels, and PET and MRI machines are often
> combined.)
>
> I do a fair amount of analysis of circuits of that sort, to figure out
> what actually limits their performance. It isn't super detailed--in
> this case, just enough to figure out whether it'll be the base-emitter
> time constant, the Miller effect, or the SPAD's series resistance that
> will be the limiting factor.
>
> Miller, I can deal with using circuit hacks. The BE time constant is
> Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
> device parameter--to get a big improvement you have to change
> transistors. The SPAD can be negotiable depending on whose process
> you're making them on--when each machine needs thousands of them,
> vendors tend to listen.

If you can buy a 100,000 parts you can go for an application specific device.
> Eventually, of course, you have to pick one and go with it, but picking
> a topology usually takes me an iteration or two.

My experience too.

--
Bill Sloman, Sydney

On Monday, January 22, 2024 at 11:06:28 AM UTC+11, John Larkin wrote:
> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

<snip>

> >Hmm. I don't think that I agree in general, because you make it sound
> >as though the process were just intuitively plucking one idea out of
> >somewhere-or-other and cranking it out.
>
> If an idea is new, where else would come from?

Several people seem to patent the same idea at much the same time.

On at least one occasion I knew exactly why - and could put my finger on the paper that had inspired me and the guy who had got there first - who turned out to have edited the journal that published the paper, and had had to put in quite a lot of work to get the author to get the bugs out of the paper

> >You've often argued in favor of brainstorming, where you get a few smart
> >people in front of a white board and try out ideas to find the best one
> >and flesh it out. We've done that together, very fruitfully.
> >
> >It's possible to do more or less the same thing by oneself, but it
> >requires the ability to tolerate uncertainty for extended periods.
> >(That's a skill well worth developing, which most people are really,
> >really bad at, IME.)
>
> The uncertainty period is probably necessary, to let ones neurons
> prowl the noisy solution space.

Neurons don't prowl. They accept inputs and generate outputs which they pass on to other neurons. Look up neural nets sometime.

> The period is usually a day or two, but can be years.

Years usually means that the technology has had a chance to move on. A good idea I had in 1975 had to wait until 1993 until I could get my hands on a big-enough cheap programmable device to make it work cheaply.

> Some engineers are uncomfortable with uncertainty, and want to lock
> down a design as soon as possible, preferably something sanctioned by
> some authority. I like to stay confused for a while.

Making a virtue of necessity,

<snip>

> Sometimes a circuit takes me dozens, lots of sheets in the trash can.
> I think it's important to give as many ideas as possible a chance.

There are an infinite number of ideas. You do have to be selective.

> See Barrie Gilbert's essay "Where do little circuits come from?"
>
> "Prod and poke" and "doodling" are suggested.

Whatever works for you.

--
Bill Sloman, Sydney

On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
wrote:

>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
><pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>>JL wrote an interesting post in the depths of the "better
>>microelectronics from coal" thread that I thought was worth pulling out
>>on its own.
>>
>>On 2024-01-21 10:12, John Larkin wrote:>
>>
>>"...what IS electronic
>> > design, and what's the best way to do it? <snip>
>> >
>> > Short answer, cobbling. When presented with a problem or an
>> > opportunity to design electronics, the most efficient way to do that
>> > is to grab a piece of paper and immediately sketch a circuit or an
>> > assembly. Sometimes one can do that instantly, without thinking, or
>> > sometimes one can ignore the issue for a few days and then the design
>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>> > fiddling with Spice helps.
>> >
>> > All that literature research and math analysis and simulation and
>> > breadboarding and prototyping are just slow and expensive follow-up
>> > chores for people who don't have 100% confidence in their instincts.
>> > Analysis, sometimes prudent to do, but not design.
>> >
>> > Design is subconsious and instinctive. And it's free! And to some
>> > extent, it can be taught, but seldom is.
>> >
>> > Most of us design things to sell, so do whatever works. We're selling
>> > stuff, not publishing papers.
>> >
>>
>>Hmm. I don't think that I agree in general, because you make it sound
>>as though the process were just intuitively plucking one idea out of
>>somewhere-or-other and cranking it out.
>
>If an idea is new, where else would come from?

It's the same idea that your FNG suggested in the design review
two weeks ago; the one that you shot down in flames.

RL

On Sun, 21 Jan 2024 19:38:37 -0500, legg <legg@nospam.magma.ca> wrote:

>On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
>wrote:
>
>>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
>><pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>>JL wrote an interesting post in the depths of the "better
>>>microelectronics from coal" thread that I thought was worth pulling out
>>>on its own.
>>>
>>>On 2024-01-21 10:12, John Larkin wrote:>
>>>
>>>"...what IS electronic
>>> > design, and what's the best way to do it? <snip>
>>> >
>>> > Short answer, cobbling. When presented with a problem or an
>>> > opportunity to design electronics, the most efficient way to do that
>>> > is to grab a piece of paper and immediately sketch a circuit or an
>>> > assembly. Sometimes one can do that instantly, without thinking, or
>>> > sometimes one can ignore the issue for a few days and then the design
>>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>>> > fiddling with Spice helps.
>>> >
>>> > All that literature research and math analysis and simulation and
>>> > breadboarding and prototyping are just slow and expensive follow-up
>>> > chores for people who don't have 100% confidence in their instincts.
>>> > Analysis, sometimes prudent to do, but not design.
>>> >
>>> > Design is subconsious and instinctive. And it's free! And to some
>>> > extent, it can be taught, but seldom is.
>>> >
>>> > Most of us design things to sell, so do whatever works. We're selling
>>> > stuff, not publishing papers.
>>> >
>>>
>>>Hmm. I don't think that I agree in general, because you make it sound
>>>as though the process were just intuitively plucking one idea out of
>>>somewhere-or-other and cranking it out.
>>
>>If an idea is new, where else would come from?
>
>It's the same idea that your FNG suggested in the design review
>two weeks ago; the one that you shot down in flames.
>
>RL

What's an FNG?

But yes, people are sometimes resistant to new ideas but if you don't
push too hard, they may come around in time, and maybe think it is
their idea.

It's best to not shoot down ideas unless they are really impossible.
But if played with, they might lead to something good.

On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
wrote:

>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
><pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>>JL wrote an interesting post in the depths of the "better
>>microelectronics from coal" thread that I thought was worth pulling out
>>on its own.
>>
>>On 2024-01-21 10:12, John Larkin wrote:>
>>
>>"...what IS electronic
>> > design, and what's the best way to do it? <snip>
>> >
>> > Short answer, cobbling. When presented with a problem or an
>> > opportunity to design electronics, the most efficient way to do that
>> > is to grab a piece of paper and immediately sketch a circuit or an
>> > assembly. Sometimes one can do that instantly, without thinking, or
>> > sometimes one can ignore the issue for a few days and then the design
>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>> > fiddling with Spice helps.
>> >
>> > All that literature research and math analysis and simulation and
>> > breadboarding and prototyping are just slow and expensive follow-up
>> > chores for people who don't have 100% confidence in their instincts.
>> > Analysis, sometimes prudent to do, but not design.
>> >
>> > Design is subconsious and instinctive. And it's free! And to some
>> > extent, it can be taught, but seldom is.
>> >
>> > Most of us design things to sell, so do whatever works. We're selling
>> > stuff, not publishing papers.
>> >
>>
>>Hmm. I don't think that I agree in general, because you make it sound
>>as though the process were just intuitively plucking one idea out of
>>somewhere-or-other and cranking it out.
>
>If an idea is new, where else would come from?
>
>>
>>You've often argued in favor of brainstorming, where you get a few smart
>>people in front of a white board and try out ideas to find the best one
>>and flesh it out. We've done that together, very fruitfully.
>>
>>It's possible to do more or less the same thing by oneself, but it
>>requires the ability to tolerate uncertainty for extended periods.
>>(That's a skill well worth developing, which most people are really,
>>really bad at, IME.)
>
>The uncertainty period is probably necessary, to let ones neurons
>prowl the noisy solution space. The period is usually a day or two,
>but can be years.
>
>Some engineers are uncomfortable with uncertainty, and want to lock
>down a design as soon as possible, preferably something sanctioned by
>some authority. I like to stay confused for a while.
>
>>
>>I sometimes need to do a family of designs, rather than just one.
>>Recently I've been working on some very fast, very cheap SPAD preamps,
>>intended to go in the guts of positron-emission scanners.
>>
>>Designs with lots of real-world constraints are often the most fun, and
>>this one's specs include: 300-ps edges with 100-ps timing repeatability
>>from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
>>(You need a whole lot of channels, and PET and MRI machines are often
>>combined.)
>>
>>I do a fair amount of analysis of circuits of that sort, to figure out
>>what actually limits their performance. It isn't super detailed--in
>>this case, just enough to figure out whether it'll be the base-emitter
>>time constant, the Miller effect, or the SPAD's series resistance that
>>will be the limiting factor.
>
>Certainly quantitative reality should filter the solution space. But
>even that can be mostly intuitive. I was talking about that with C on
>Friday, about how some people have good quantitative intuition and
>some don't. She can look at soup in a round pot and know if it will
>fit into a square plastic container, to about 10%. I can do that.
>Neither of our spouses can.
>
>
>>
>>Miller, I can deal with using circuit hacks. The BE time constant is
>>Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
>>device parameter--to get a big improvement you have to change
>>transistors. The SPAD can be negotiable depending on whose process
>>you're making them on--when each machine needs thousands of them,
>>vendors tend to listen.
>>
>>Eventually, of course, you have to pick one and go with it, but picking
>>a topology usually takes me an iteration or two.
>
>Sometimes a circuit takes me dozens, lots of sheets in the trash can.
>I think it's important to give as many ideas as possible a chance.
>
>See Barrie Gilbert's essay "Where do little circuits come from?"
>
>"Prod and poke" and "doodling" are suggested.
>

I agree with both of you. What Phil is doing is figuring out where to
focus the brainstorming and fiddling, and the resulting wild
alternatives can easily be assessed. It's at the very least an
orthogonal method.

My personal experience is that iterations and inspirations require
studying extensively followed by sleeping on it, so the metric isn't a
few days, it's a few nights.

The bit about the necessity of nights was pointed out by J. Hadamard
in his famous book on this issue. The book has become hard to find
and expensive, but has now been reissued:

..<https://www.amazon.com/Mathematicians-Mind-Jacques-Hadamard/dp/0691029318/ref=sr_1_1>

Joe Gwinn

On Sun, 21 Jan 2024 22:08:08 -0500, Joe Gwinn <joegwinn@comcast.net>
wrote:

>On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
>wrote:
>
>>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
>><pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>>JL wrote an interesting post in the depths of the "better
>>>microelectronics from coal" thread that I thought was worth pulling out
>>>on its own.
>>>
>>>On 2024-01-21 10:12, John Larkin wrote:>
>>>
>>>"...what IS electronic
>>> > design, and what's the best way to do it? <snip>
>>> >
>>> > Short answer, cobbling. When presented with a problem or an
>>> > opportunity to design electronics, the most efficient way to do that
>>> > is to grab a piece of paper and immediately sketch a circuit or an
>>> > assembly. Sometimes one can do that instantly, without thinking, or
>>> > sometimes one can ignore the issue for a few days and then the design
>>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>>> > fiddling with Spice helps.
>>> >
>>> > All that literature research and math analysis and simulation and
>>> > breadboarding and prototyping are just slow and expensive follow-up
>>> > chores for people who don't have 100% confidence in their instincts.
>>> > Analysis, sometimes prudent to do, but not design.
>>> >
>>> > Design is subconsious and instinctive. And it's free! And to some
>>> > extent, it can be taught, but seldom is.
>>> >
>>> > Most of us design things to sell, so do whatever works. We're selling
>>> > stuff, not publishing papers.
>>> >
>>>
>>>Hmm. I don't think that I agree in general, because you make it sound
>>>as though the process were just intuitively plucking one idea out of
>>>somewhere-or-other and cranking it out.
>>
>>If an idea is new, where else would come from?
>>
>>>
>>>You've often argued in favor of brainstorming, where you get a few smart
>>>people in front of a white board and try out ideas to find the best one
>>>and flesh it out. We've done that together, very fruitfully.
>>>
>>>It's possible to do more or less the same thing by oneself, but it
>>>requires the ability to tolerate uncertainty for extended periods.
>>>(That's a skill well worth developing, which most people are really,
>>>really bad at, IME.)
>>
>>The uncertainty period is probably necessary, to let ones neurons
>>prowl the noisy solution space. The period is usually a day or two,
>>but can be years.
>>
>>Some engineers are uncomfortable with uncertainty, and want to lock
>>down a design as soon as possible, preferably something sanctioned by
>>some authority. I like to stay confused for a while.
>>
>>>
>>>I sometimes need to do a family of designs, rather than just one.
>>>Recently I've been working on some very fast, very cheap SPAD preamps,
>>>intended to go in the guts of positron-emission scanners.
>>>
>>>Designs with lots of real-world constraints are often the most fun, and
>>>this one's specs include: 300-ps edges with 100-ps timing repeatability
>>>from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
>>>(You need a whole lot of channels, and PET and MRI machines are often
>>>combined.)
>>>
>>>I do a fair amount of analysis of circuits of that sort, to figure out
>>>what actually limits their performance. It isn't super detailed--in
>>>this case, just enough to figure out whether it'll be the base-emitter
>>>time constant, the Miller effect, or the SPAD's series resistance that
>>>will be the limiting factor.
>>
>>Certainly quantitative reality should filter the solution space. But
>>even that can be mostly intuitive. I was talking about that with C on
>>Friday, about how some people have good quantitative intuition and
>>some don't. She can look at soup in a round pot and know if it will
>>fit into a square plastic container, to about 10%. I can do that.
>>Neither of our spouses can.
>>
>>
>>>
>>>Miller, I can deal with using circuit hacks. The BE time constant is
>>>Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
>>>device parameter--to get a big improvement you have to change
>>>transistors. The SPAD can be negotiable depending on whose process
>>>you're making them on--when each machine needs thousands of them,
>>>vendors tend to listen.
>>>
>>>Eventually, of course, you have to pick one and go with it, but picking
>>>a topology usually takes me an iteration or two.
>>
>>Sometimes a circuit takes me dozens, lots of sheets in the trash can.
>>I think it's important to give as many ideas as possible a chance.
>>
>>See Barrie Gilbert's essay "Where do little circuits come from?"
>>
>>"Prod and poke" and "doodling" are suggested.
>>
>
>I agree with both of you. What Phil is doing is figuring out where to
>focus the brainstorming and fiddling, and the resulting wild
>alternatives can easily be assessed. It's at the very least an
>orthogonal method.
>
>My personal experience is that iterations and inspirations require
>studying extensively followed by sleeping on it, so the metric isn't a
>few days, it's a few nights.

Actually, it is a few showers.

>
>The bit about the necessity of nights was pointed out by J. Hadamard
>in his famous book on this issue. The book has become hard to find
>and expensive, but has now been reissued:
>
>.<https://www.amazon.com/Mathematicians-Mind-Jacques-Hadamard/dp/0691029318/ref=sr_1_1>
>
>Joe Gwinn

On Sun, 21 Jan 2024 19:43:18 -0800, John Larkin <jl@997PotHill.com>
wrote:

>On Sun, 21 Jan 2024 22:08:08 -0500, Joe Gwinn <joegwinn@comcast.net>
>wrote:
>
>>On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
>>wrote:
>>
>>>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
>>><pcdhSpamMeSenseless@electrooptical.net> wrote:
>>>
>>>>JL wrote an interesting post in the depths of the "better
>>>>microelectronics from coal" thread that I thought was worth pulling out
>>>>on its own.
>>>>
>>>>On 2024-01-21 10:12, John Larkin wrote:>
>>>>
>>>>"...what IS electronic
>>>> > design, and what's the best way to do it? <snip>
>>>> >
>>>> > Short answer, cobbling. When presented with a problem or an
>>>> > opportunity to design electronics, the most efficient way to do that
>>>> > is to grab a piece of paper and immediately sketch a circuit or an
>>>> > assembly. Sometimes one can do that instantly, without thinking, or
>>>> > sometimes one can ignore the issue for a few days and then the design
>>>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>>>> > fiddling with Spice helps.
>>>> >
>>>> > All that literature research and math analysis and simulation and
>>>> > breadboarding and prototyping are just slow and expensive follow-up
>>>> > chores for people who don't have 100% confidence in their instincts.
>>>> > Analysis, sometimes prudent to do, but not design.
>>>> >
>>>> > Design is subconsious and instinctive. And it's free! And to some
>>>> > extent, it can be taught, but seldom is.
>>>> >
>>>> > Most of us design things to sell, so do whatever works. We're selling
>>>> > stuff, not publishing papers.
>>>> >
>>>>
>>>>Hmm. I don't think that I agree in general, because you make it sound
>>>>as though the process were just intuitively plucking one idea out of
>>>>somewhere-or-other and cranking it out.
>>>
>>>If an idea is new, where else would come from?
>>>
>>>>
>>>>You've often argued in favor of brainstorming, where you get a few smart
>>>>people in front of a white board and try out ideas to find the best one
>>>>and flesh it out. We've done that together, very fruitfully.
>>>>
>>>>It's possible to do more or less the same thing by oneself, but it
>>>>requires the ability to tolerate uncertainty for extended periods.
>>>>(That's a skill well worth developing, which most people are really,
>>>>really bad at, IME.)
>>>
>>>The uncertainty period is probably necessary, to let ones neurons
>>>prowl the noisy solution space. The period is usually a day or two,
>>>but can be years.
>>>
>>>Some engineers are uncomfortable with uncertainty, and want to lock
>>>down a design as soon as possible, preferably something sanctioned by
>>>some authority. I like to stay confused for a while.
>>>
>>>>
>>>>I sometimes need to do a family of designs, rather than just one.
>>>>Recently I've been working on some very fast, very cheap SPAD preamps,
>>>>intended to go in the guts of positron-emission scanners.
>>>>
>>>>Designs with lots of real-world constraints are often the most fun, and
>>>>this one's specs include: 300-ps edges with 100-ps timing repeatability
>>>>from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
>>>>(You need a whole lot of channels, and PET and MRI machines are often
>>>>combined.)
>>>>
>>>>I do a fair amount of analysis of circuits of that sort, to figure out
>>>>what actually limits their performance. It isn't super detailed--in
>>>>this case, just enough to figure out whether it'll be the base-emitter
>>>>time constant, the Miller effect, or the SPAD's series resistance that
>>>>will be the limiting factor.
>>>
>>>Certainly quantitative reality should filter the solution space. But
>>>even that can be mostly intuitive. I was talking about that with C on
>>>Friday, about how some people have good quantitative intuition and
>>>some don't. She can look at soup in a round pot and know if it will
>>>fit into a square plastic container, to about 10%. I can do that.
>>>Neither of our spouses can.
>>>
>>>
>>>>
>>>>Miller, I can deal with using circuit hacks. The BE time constant is
>>>>Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
>>>>device parameter--to get a big improvement you have to change
>>>>transistors. The SPAD can be negotiable depending on whose process
>>>>you're making them on--when each machine needs thousands of them,
>>>>vendors tend to listen.
>>>>
>>>>Eventually, of course, you have to pick one and go with it, but picking
>>>>a topology usually takes me an iteration or two.
>>>
>>>Sometimes a circuit takes me dozens, lots of sheets in the trash can.
>>>I think it's important to give as many ideas as possible a chance.
>>>
>>>See Barrie Gilbert's essay "Where do little circuits come from?"
>>>
>>>"Prod and poke" and "doodling" are suggested.
>>>
>>
>>I agree with both of you. What Phil is doing is figuring out where to
>>focus the brainstorming and fiddling, and the resulting wild
>>alternatives can easily be assessed. It's at the very least an
>>orthogonal method.
>>
>>My personal experience is that iterations and inspirations require
>>studying extensively followed by sleeping on it, so the metric isn't a
>>few days, it's a few nights.
>
>Actually, it is a few showers.

So, you're all wet?

Actually, I also get ideas in the shower, probably because I stopped
focusing so hard.

I used to keep a waterproof dictation recorder handy, and on my
bedside table, so I wouldn't lose the ideas, but don't need the
recorder any more.

But the key is to stop trying for a while and think irrelevant things.

Joe Gwinn

>>The bit about the necessity of nights was pointed out by J. Hadamard
>>in his famous book on this issue. The book has become hard to find
>>and expensive, but has now been reissued:
>>
>>.<https://www.amazon.com/Mathematicians-Mind-Jacques-Hadamard/dp/0691029318/ref=sr_1_1>
>>
>>Joe Gwinn

On Mon, 22 Jan 2024 00:12:36 -0500, Joe Gwinn <joegwinn@comcast.net>
wrote:

>On Sun, 21 Jan 2024 19:43:18 -0800, John Larkin <jl@997PotHill.com>
>wrote:
>
>>On Sun, 21 Jan 2024 22:08:08 -0500, Joe Gwinn <joegwinn@comcast.net>
>>wrote:
>>
>>>On Sun, 21 Jan 2024 16:05:07 -0800, John Larkin <jl@997PotHill.com>
>>>wrote:
>>>
>>>>On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
>>>><pcdhSpamMeSenseless@electrooptical.net> wrote:
>>>>
>>>>>JL wrote an interesting post in the depths of the "better
>>>>>microelectronics from coal" thread that I thought was worth pulling out
>>>>>on its own.
>>>>>
>>>>>On 2024-01-21 10:12, John Larkin wrote:>
>>>>>
>>>>>"...what IS electronic
>>>>> > design, and what's the best way to do it? <snip>
>>>>> >
>>>>> > Short answer, cobbling. When presented with a problem or an
>>>>> > opportunity to design electronics, the most efficient way to do that
>>>>> > is to grab a piece of paper and immediately sketch a circuit or an
>>>>> > assembly. Sometimes one can do that instantly, without thinking, or
>>>>> > sometimes one can ignore the issue for a few days and then the design
>>>>> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>>>>> > fiddling with Spice helps.
>>>>> >
>>>>> > All that literature research and math analysis and simulation and
>>>>> > breadboarding and prototyping are just slow and expensive follow-up
>>>>> > chores for people who don't have 100% confidence in their instincts.
>>>>> > Analysis, sometimes prudent to do, but not design.
>>>>> >
>>>>> > Design is subconsious and instinctive. And it's free! And to some
>>>>> > extent, it can be taught, but seldom is.
>>>>> >
>>>>> > Most of us design things to sell, so do whatever works. We're selling
>>>>> > stuff, not publishing papers.
>>>>> >
>>>>>
>>>>>Hmm. I don't think that I agree in general, because you make it sound
>>>>>as though the process were just intuitively plucking one idea out of
>>>>>somewhere-or-other and cranking it out.
>>>>
>>>>If an idea is new, where else would come from?
>>>>
>>>>>
>>>>>You've often argued in favor of brainstorming, where you get a few smart
>>>>>people in front of a white board and try out ideas to find the best one
>>>>>and flesh it out. We've done that together, very fruitfully.
>>>>>
>>>>>It's possible to do more or less the same thing by oneself, but it
>>>>>requires the ability to tolerate uncertainty for extended periods.
>>>>>(That's a skill well worth developing, which most people are really,
>>>>>really bad at, IME.)
>>>>
>>>>The uncertainty period is probably necessary, to let ones neurons
>>>>prowl the noisy solution space. The period is usually a day or two,
>>>>but can be years.
>>>>
>>>>Some engineers are uncomfortable with uncertainty, and want to lock
>>>>down a design as soon as possible, preferably something sanctioned by
>>>>some authority. I like to stay confused for a while.
>>>>
>>>>>
>>>>>I sometimes need to do a family of designs, rather than just one.
>>>>>Recently I've been working on some very fast, very cheap SPAD preamps,
>>>>>intended to go in the guts of positron-emission scanners.
>>>>>
>>>>>Designs with lots of real-world constraints are often the most fun, and
>>>>>this one's specs include: 300-ps edges with 100-ps timing repeatability
>>>>>from unit to unit; no magnetics allowed; and a BOM cost of $1 or less.
>>>>>(You need a whole lot of channels, and PET and MRI machines are often
>>>>>combined.)
>>>>>
>>>>>I do a fair amount of analysis of circuits of that sort, to figure out
>>>>>what actually limits their performance. It isn't super detailed--in
>>>>>this case, just enough to figure out whether it'll be the base-emitter
>>>>>time constant, the Miller effect, or the SPAD's series resistance that
>>>>>will be the limiting factor.
>>>>
>>>>Certainly quantitative reality should filter the solution space. But
>>>>even that can be mostly intuitive. I was talking about that with C on
>>>>Friday, about how some people have good quantitative intuition and
>>>>some don't. She can look at soup in a round pot and know if it will
>>>>fit into a square plastic container, to about 10%. I can do that.
>>>>Neither of our spouses can.
>>>>
>>>>
>>>>>
>>>>>Miller, I can deal with using circuit hacks. The BE time constant is
>>>>>Rbb' * Cbe, which gets slightly worse at high current, but is mainly a
>>>>>device parameter--to get a big improvement you have to change
>>>>>transistors. The SPAD can be negotiable depending on whose process
>>>>>you're making them on--when each machine needs thousands of them,
>>>>>vendors tend to listen.
>>>>>
>>>>>Eventually, of course, you have to pick one and go with it, but picking
>>>>>a topology usually takes me an iteration or two.
>>>>
>>>>Sometimes a circuit takes me dozens, lots of sheets in the trash can.
>>>>I think it's important to give as many ideas as possible a chance.
>>>>
>>>>See Barrie Gilbert's essay "Where do little circuits come from?"
>>>>
>>>>"Prod and poke" and "doodling" are suggested.
>>>>
>>>
>>>I agree with both of you. What Phil is doing is figuring out where to
>>>focus the brainstorming and fiddling, and the resulting wild
>>>alternatives can easily be assessed. It's at the very least an
>>>orthogonal method.
>>>
>>>My personal experience is that iterations and inspirations require
>>>studying extensively followed by sleeping on it, so the metric isn't a
>>>few days, it's a few nights.
>>
>>Actually, it is a few showers.
>
>So, you're all wet?

That's the idea.

>
>Actually, I also get ideas in the shower, probably because I stopped
>focusing so hard.

I think sleepytime ideas get delivered in a morning shower. I don't
have ideas if I shower later in the day.

>
>I used to keep a waterproof dictation recorder handy, and on my
>bedside table, so I wouldn't lose the ideas, but don't need the
>recorder any more.

Sometimes I have ideas at around 3AM. I scribble them on a pad so I
don't forget.

>
>But the key is to stop trying for a while and think irrelevant things.
>
>Joe Gwinn
>
>
>>>The bit about the necessity of nights was pointed out by J. Hadamard
>>>in his famous book on this issue. The book has become hard to find
>>>and expensive, but has now been reissued:
>>>
>>>.<https://www.amazon.com/Mathematicians-Mind-Jacques-Hadamard/dp/0691029318/ref=sr_1_1>
>>>
>>>Joe Gwinn

On Mon, 22 Jan 2024 11:47:54 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Sunday, January 21, 2024 at 7:06:28?PM UTC-5, John Larkin wrote:
>> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>> >JL wrote an interesting post in the depths of the "better
>> >microelectronics from coal" thread that I thought was worth pulling out
>> >on its own.
>> >
>> >On 2024-01-21 10:12, John Larkin wrote:>
>> >
>> >"...what IS electronic
>> > > design, and what's the best way to do it? <snip>
>> > >
>> > > Short answer, cobbling. When presented with a problem or an
>> > > opportunity to design electronics, the most efficient way to do that
>> > > is to grab a piece of paper and immediately sketch a circuit or an
>> > > assembly. Sometimes one can do that instantly, without thinking, or
>> > > sometimes one can ignore the issue for a few days and then the design
>> > > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
>> > > fiddling with Spice helps.
>> > >
>> > > All that literature research and math analysis and simulation and
>> > > breadboarding and prototyping are just slow and expensive follow-up
>> > > chores for people who don't have 100% confidence in their instincts.
>> > > Analysis, sometimes prudent to do, but not design.
>> > >
>> > > Design is subconsious and instinctive. And it's free! And to some
>> > > extent, it can be taught, but seldom is.
>> > >
>> > > Most of us design things to sell, so do whatever works. We're selling
>> > > stuff, not publishing papers.
>> > >
>> >
>> >Hmm. I don't think that I agree in general, because you make it sound
>> >as though the process were just intuitively plucking one idea out of
>> >somewhere-or-other and cranking it out.
>> If an idea is new, where else would come from?
>
>Within 5 years, all this manual fiddling, and so-called brainstorming, will be reduced to an AI-app resident on a $ phone. It may not be optimum, but it will work.
>
>

I don't think so. Just a few words are not enough to specify and
generate a specific, reliable design.

There's not much I in AI. It's mostly a silly fad.

But brainstorming isn't so-called. Done right, it really works.

On Tuesday, January 23, 2024 at 6:47:59 AM UTC+11, Fred Bloggs wrote:
> On Sunday, January 21, 2024 at 7:06:28 PM UTC-5, John Larkin wrote:
> > On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
> > >On 2024-01-21 10:12, John Larkin wrote:>

<snip>

> > >Hmm. I don't think that I agree in general, because you make it sound
> > >as though the process were just intuitively plucking one idea out of
> > >somewhere-or-other and cranking it out.
> >
> > If an idea is new, where else would come from?

New inventions tend to show up in several different places at much the same time. New ideas spread around, and turn into patentable innovations in different people's brains. I have had original ideas that stayed original for nearly twenty years, but most of them turned out to have shown up elsewhere earlier, even if they weren't put into practice all that well, if at all.

> Within 5 years, all this manual fiddling, and so-called brainstorming, will be reduced to an AI-app resident on a $ phone. It may not be optimum, but it will work.

Probably not. The trick is finding the right point of view, and software is written around a particular point of view.

--
Bill Sloman, Sydney

On 2024-01-21, Phil Hobbs wrote:
> JL wrote an interesting post in the depths of the "better
> microelectronics from coal" thread that I thought was worth pulling out
> on its own.
>
> On 2024-01-21 10:12, John Larkin wrote:>
>
> "...what IS electronic
> > design, and what's the best way to do it? <snip>
> >
> > Short answer, cobbling. When presented with a problem or an
> > opportunity to design electronics, the most efficient way to do that
> > is to grab a piece of paper and immediately sketch a circuit or an
> > assembly. Sometimes one can do that instantly, without thinking, or
> > sometimes one can ignore the issue for a few days and then the design
> > pops up. Sometimes brainstorming and whiteboarding help. Sometimes
> > fiddling with Spice helps.
> >
> > All that literature research and math analysis and simulation and
> > breadboarding and prototyping are just slow and expensive follow-up
> > chores for people who don't have 100% confidence in their instincts.
> > Analysis, sometimes prudent to do, but not design.
> >
> > Design is subconsious and instinctive. And it's free! And to some
> > extent, it can be taught, but seldom is.
> >
> > Most of us design things to sell, so do whatever works. We're selling
> > stuff, not publishing papers.
> >
>
> Hmm. I don't think that I agree in general, because you make it sound
> as though the process were just intuitively plucking one idea out of
> somewhere-or-other and cranking it out.
>
> You've often argued in favor of brainstorming, where you get a few smart
> people in front of a white board and try out ideas to find the best one
> and flesh it out. We've done that together, very fruitfully.
>
> It's possible to do more or less the same thing by oneself, but it
> requires the ability to tolerate uncertainty for extended periods.
> (That's a skill well worth developing, which most people are really,
> really bad at, IME.)

It helps if one has a rubber duckie (or maybe I'm just that bad at it!)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On Tuesday, January 23, 2024 at 7:43:34 AM UTC+11, john larkin wrote:
> On Mon, 22 Jan 2024 11:47:54 -0800 (PST), Fred Bloggs <bloggs.fred...@gmail.com> wrote:
> >On Sunday, January 21, 2024 at 7:06:28?PM UTC-5, John Larkin wrote:
> >> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
> >> >On 2024-01-21 10:12, John Larkin wrote:

> I don't think so. Just a few words are not enough to specify and generate a specific, reliable design.

They are enough to specify a patentable idea. Reducing it to practice takes a lot more work, and documenting a complete system takes a lot of words (and pictures). Oddly enough, software can do a lot of the documentation.

> There's not much I in AI. It's mostly a silly fad.

For particular problems it can already find solutions that humans can't

https://en.wikipedia.org/wiki/Protein_folding

AlphaFold is well ahead of any expert, and some theorem-proving programs operate without making mistakes to a degree that allows them to outperform human mathematicians on specific complex problems. It really isn't any kid of silly fad.

> But brainstorming isn't so-called. Done right, it really works.

Mainly by discouraging status-seeking creeps from insisting on concentrating on their own ideas.

--
Bill Sloman, Sydney

On Wed, 24 Jan 2024 08:00:15 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Monday, January 22, 2024 at 6:29:33?PM UTC-5, Anthony William Sloman wrote:
>> On Tuesday, January 23, 2024 at 7:43:34?AM UTC+11, john larkin wrote:
>> > On Mon, 22 Jan 2024 11:47:54 -0800 (PST), Fred Bloggs <bloggs.fred...@gmail.com> wrote:
>> > >On Sunday, January 21, 2024 at 7:06:28?PM UTC-5, John Larkin wrote:
>> > >> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
>> > >> >On 2024-01-21 10:12, John Larkin wrote:
>>
>> > I don't think so. Just a few words are not enough to specify and generate a specific, reliable design.
>> They are enough to specify a patentable idea. Reducing it to practice takes a lot more work, and documenting a complete system takes a lot of words (and pictures). Oddly enough, software can do a lot of the documentation.
>> > There's not much I in AI. It's mostly a silly fad.
>> For particular problems it can already find solutions that humans can't
>>
>> https://en.wikipedia.org/wiki/Protein_folding
>>
>> AlphaFold is well ahead of any expert, and some theorem-proving programs operate without making mistakes to a degree that allows them to outperform human mathematicians on specific complex problems. It really isn't any kid of silly fad.
>> > But brainstorming isn't so-called. Done right, it really works.
>> Mainly by discouraging status-seeking creeps from insisting on concentrating on their own ideas.
>
>To be replaced by group concentration on no ideas at all.

The people have to be right for the process to be productive of ideas.
Some people will poison a brainstorming session, and too much general
sociability in the room will reinforce conventional thinking.

>
>https://resources.pcb.cadence.com/blog/2022-the-role-of-machine-learning-in-analog-circuit-design

That's absurd. Sounds like they are trying to sell cad options to
beginners.

>
>https://www.synopsys.com/blogs/chip-design/ai-analog-design-migration-samsung-safe-forum-2023.html

Certainly a lot of computing helps design digital ICs, but I wouldn't
call that intelligence. Smart people wrote very specialized software.
I sometimes write software to solve circuit problems, but the software
just does what I told it to do.

>
>https://www.planetanalog.com/what-can-ai-do-for-analog-design/

I'd love to have a good component selection tool. The intelligence
would be in inferring things from bad data sheets that have no
standards. It would of course have to read and understand application
schematics and mechanical drawings and find gotchas buried in
footnotes and graphs.

Find me a right-angle Gbit PoE compatible RJ45 jack that has multiple
drop-in sources, two LEDs on the high side, lots of stock from
non-Chinese sources, at a good price. They have to mount on my PCB and
ground to a cutout in my panel. That's an easy one.

>
>https://www.electronicdesign.com/technologies/embedded/article/21272567/electronic-design-ai-lends-a-helping-hand-with-analog-and-custom-ic-design
>
>https://semiengineering.com/ai-for-circuit-design-quality-productivity-and-advanced-node-mapping/
>
>http://ieeexplore.ieee.org/document/31523/
>
>The list is endless. Humans are not as unique and special as they make themselves out to be. They'll all be replaced by AI before long.

Has AI ever invented anything?

>
>

I check up on Flux.ai now and then. I wonder when they will run out of
money.

On Wed, 24 Jan 2024 10:59:47 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Wednesday, January 24, 2024 at 11:28:36?AM UTC-5, John Larkin wrote:
>> On Wed, 24 Jan 2024 08:00:15 -0800 (PST), Fred Bloggs
>> <bloggs.fred...@gmail.com> wrote:
>>
>> >On Monday, January 22, 2024 at 6:29:33?PM UTC-5, Anthony William Sloman wrote:
>> >> On Tuesday, January 23, 2024 at 7:43:34?AM UTC+11, john larkin wrote:
>> >> > On Mon, 22 Jan 2024 11:47:54 -0800 (PST), Fred Bloggs <bloggs.fred...@gmail.com> wrote:
>> >> > >On Sunday, January 21, 2024 at 7:06:28?PM UTC-5, John Larkin wrote:
>> >> > >> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
>> >> > >> >On 2024-01-21 10:12, John Larkin wrote:
>> >>
>> >> > I don't think so. Just a few words are not enough to specify and generate a specific, reliable design.
>> >> They are enough to specify a patentable idea. Reducing it to practice takes a lot more work, and documenting a complete system takes a lot of words (and pictures). Oddly enough, software can do a lot of the documentation.
>> >> > There's not much I in AI. It's mostly a silly fad.
>> >> For particular problems it can already find solutions that humans can't
>> >>
>> >> https://en.wikipedia.org/wiki/Protein_folding
>> >>
>> >> AlphaFold is well ahead of any expert, and some theorem-proving programs operate without making mistakes to a degree that allows them to outperform human mathematicians on specific complex problems. It really isn't any kid of silly fad.
>> >> > But brainstorming isn't so-called. Done right, it really works.
>> >> Mainly by discouraging status-seeking creeps from insisting on concentrating on their own ideas.
>> >
>> >To be replaced by group concentration on no ideas at all.
>> The people have to be right for the process to be productive of ideas.
>> Some people will poison a brainstorming session, and too much general
>> sociability in the room will reinforce conventional thinking.
>>
>> >
>> >https://resources.pcb.cadence.com/blog/2022-the-role-of-machine-learning-in-analog-circuit-design
>>
>> That's absurd. Sounds like they are trying to sell cad options to
>> beginners.
>>
>>
>> >
>> >https://www.synopsys.com/blogs/chip-design/ai-analog-design-migration-samsung-safe-forum-2023.html
>>
>>
>> Certainly a lot of computing helps design digital ICs, but I wouldn't
>> call that intelligence. Smart people wrote very specialized software.
>> I sometimes write software to solve circuit problems, but the software
>> just does what I told it to do.
>>
>>
>> >
>> >https://www.planetanalog.com/what-can-ai-do-for-analog-design/
>>
>>
>> I'd love to have a good component selection tool. The intelligence
>> would be in inferring things from bad data sheets that have no
>> standards. It would of course have to read and understand application
>> schematics and mechanical drawings and find gotchas buried in
>> footnotes and graphs.
>>
>> Find me a right-angle Gbit PoE compatible RJ45 jack that has multiple
>> drop-in sources, two LEDs on the high side, lots of stock from
>> non-Chinese sources, at a good price. They have to mount on my PCB and
>> ground to a cutout in my panel. That's an easy one.
>
>Lots of sources for that, but if you want a good price, it will be made in Asia. The shielded ones will ground to the panel. High demand parts like that will have a long lead time:
>
>https://www.digikey.com/en/products/detail/w%C3%BCrth-elektronik/615008137421/2060608
>
>
>
>> >
>> >https://www.electronicdesign.com/technologies/embedded/article/21272567/electronic-design-ai-lends-a-helping-hand-with-analog-and-custom-ic-design
>> >
>> >https://semiengineering.com/ai-for-circuit-design-quality-productivity-and-advanced-node-mapping/
>> >
>> >http://ieeexplore.ieee.org/document/31523/
>> >
>> >The list is endless. Humans are not as unique and special as they make themselves out to be. They'll all be replaced by AI before long.
>> Has AI ever invented anything?
>
>It's doing things like running through impossibly large numbers of permutations to find something useful, as with drug discovery. It's more the case creative people are using AI to enable inventive ideas.

That's not intelligent. It's just automating a lot of grunt work, as
programmed. Line monte carlo simulation. The person who set it up is
the intelligence. All that's new is having more compute power than we
had in the past.

Computers automate grunt work and let us work faster and better and
move up the abstraction stack. Nonlinear differential equations were
never much fun.

I would like a Spice that was, say, 500x as fast as mine is now,
nvidia or something. And I'd love some way to specify results and have
a program juggle values and even library parts for a best solution.

Past attempts at such optimizations have tended to diverge. Even most
interns are smarter than that.

>>
>> >
>> >
>>
>> I check up on Flux.ai now and then. I wonder when they will run out of
>> money.

Take a look at flux. It's funny.

On Thursday, January 25, 2024 at 3:00:21 AM UTC+11, Fred Bloggs wrote:
> On Monday, January 22, 2024 at 6:29:33 PM UTC-5, Anthony William Sloman wrote:
> > On Tuesday, January 23, 2024 at 7:43:34 AM UTC+11, john larkin wrote:
> > > On Mon, 22 Jan 2024 11:47:54 -0800 (PST), Fred Bloggs <bloggs.fred...@gmail.com> wrote:
> > > >On Sunday, January 21, 2024 at 7:06:28?PM UTC-5, John Larkin wrote:
> > > >> On Sun, 21 Jan 2024 18:16:01 -0500, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:
> > > >> >On 2024-01-21 10:12, John Larkin wrote:
> >
> > > I don't think so. Just a few words are not enough to specify and generate a specific, reliable design.
> >
> > They are enough to specify a patentable idea. Reducing it to practice takes a lot more work, and documenting a complete system takes a lot of words (and pictures). Oddly enough, software can do a lot of the documentation.
> >
> > > There's not much I in AI. It's mostly a silly fad.
> >
> > For particular problems it can already find solutions that humans can't
> >
> > https://en.wikipedia.org/wiki/Protein_folding
> >
> > AlphaFold is well ahead of any expert, and some theorem-proving programs operate without making mistakes to a degree that allows them to outperform human mathematicians on specific complex problems. It really isn't any kid of silly fad.
> >
> > > But brainstorming isn't so-called. Done right, it really works.
> >
> > Mainly by discouraging status-seeking creeps from insisting on concentrating on their own ideas.
>
> To be replaced by group concentration on no ideas at all.

You've not taken apart in a brain-storming session?

<snipped ads>

> The list is endless. Humans are not as unique and special as they make themselves out to be. They'll all be replaced by AI before long.

And the sooner we can automate pessimism the faster we can replace Fred Bloggs.

Fred doesn't seem to realise how much of circuit design is tedious drudgery, which can and should be taken over by machines. He seems to be equally ignorant of the necessity to find the right point of view, which doesn't seen to be a task that anybody has automated yet. Quite a few circuit designers aren't aware that they need to find the right point of view, and soldier on, using the 555 (or whatever tool they've latched onto) to solve every problem that gets served up to them.

--
Bill Sloman, Sydney

On Wednesday, January 24, 2024 at 11:15:36 AM UTC-8, john larkin wrote:

> I would like a Spice that was, say, 500x as fast as mine is now,
> nvidia or something. And I'd love some way to specify results and have
> a program juggle values and even library parts for a best solution.
>
> Past attempts at such optimizations have tended to diverge. Even most
> interns are smarter than that.

That's why we have math, that tells us that linear equations (like SPICE solves)
have multiple ways to generate large numbers. It's catastrophe theory,
to be precise.

For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
components; there won't ever be any solutions that don't diverge, because
the linear-differential-equation solutions all have a matrix raised to
a power (and the power goes up with time). It'll always exponentially
decay or explode, because NO available component tolerances
are negligible effects.

The bugaboo of ALL multivariate optimizers is the fact that any solution
that's not unique is associated with regions in the parameter space
that have no optimum-direction sensitivity. Also, the parameter space
is huge. A dozen filter components means a ten-percent grid on
available values ranging over three decades has 72^12 = 1.9 *10^22
points to test, when the flat regions don't allow for gradient directed progress.

On Thursday, January 25, 2024 at 12:30:04 PM UTC+11, whit3rd wrote:
> On Wednesday, January 24, 2024 at 11:15:36 AM UTC-8, john larkin wrote:

<snip>

> The bugaboo of ALL multivariate optimizers is the fact that any solution
> that's not unique is associated with regions in the parameter space
> that have no optimum-direction sensitivity. Also, the parameter space
> is huge. A dozen filter components means a ten-percent grid on
> available values ranging over three decades has 72^12 = 1.9 *10^22
> points to test, when the flat regions don't allow for gradient directed progress.

I programmed one to fit my reaction data results when I was a graduate student - essentially the Fletcher-Powell procedure - which builds up a matrix of the second derivatives of the slope of the parameter space in the region it explored.

When the data was noisy it didn't work very well, but that was fine - those reactions runs got chucked out because the best fit reaction rate wouldn't have been all that well defined. You did have to start the process with reasonable values for the parameters being fitted (initial concentration, final concentration and reaction rate) but that wasn't difficult.\

As you say, if I'd had to start from scratch it wouldn't have worked. A dozen filter components wouldn't be selected at random - you'd start off with something classical (and probably fix the capacitors at values you could buy of the shelf).

--
Bill Sloman, Sydney

On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:

>On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:
>
>> I would like a Spice that was, say, 500x as fast as mine is now,
>> nvidia or something. And I'd love some way to specify results and have
>> a program juggle values and even library parts for a best solution.
>>
>> Past attempts at such optimizations have tended to diverge. Even most
>> interns are smarter than that.
>
>That's why we have math, that tells us that linear equations (like SPICE solves)
>have multiple ways to generate large numbers. It's catastrophe theory,
>to be precise.
>
>For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
>components; there won't ever be any solutions that don't diverge, because
>the linear-differential-equation solutions all have a matrix raised to
>a power (and the power goes up with time). It'll always exponentially
>decay or explode, because NO available component tolerances
>are negligible effects.
>
>The bugaboo of ALL multivariate optimizers is the fact that any solution
>that's not unique is associated with regions in the parameter space
>that have no optimum-direction sensitivity. Also, the parameter space
>is huge. A dozen filter components means a ten-percent grid on
>available values ranging over three decades has 72^12 = 1.9 *10^22
>points to test, when the flat regions don't allow for gradient directed progress.

One of my specialities is designing instant-start super low jitter LC
oscillators. The Spice sims are dead on, except for tempco
compensation, which has to be done experimentally. I'd hate to design
such oscillators using differential equations.

If you think about it, all design is a mysterious mental process that
is follwed up by analysis, which can be equations, simulation, or
hardware prototyping. Whatever works. The real magic is step 1,
inventing things.

I'm impressed by computer based high-order filter design, especially
lossy LC filters. That's been automated since the Fortran days. When I
twiddle a filter in Spice, it tends to diverge.

On Thursday, January 25, 2024 at 1:08:46 PM UTC+11, John Larkin wrote:
> On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whi...@gmail.com>
> wrote:
> >On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:

<snip>

> One of my specialities is designing instant-start super low jitter LC
> oscillators. The Spice sims are dead on, except for tempco
> compensation, which has to be done experimentally. I'd hate to design
> such oscillators using differential equations.

Nobody in their right mind would design such oscillators anyway - they are never as low-jitter as continuously running oscillators.

The more sensible approach relies on free-running low jitter oscillators (which can run much faster) and a two stage timing procedure which digitises how long after the most recent clock edge the start pulse arrived and adds that to the desired delay (which is then realsied as a countablke number of clock edges plus a vernier delay to put it in exactly the right place.

That's what we did in 1988, and it would be a lot easier now. John Larkin is actually copying a Hewlett-Packard device from 1978 when there were fewer fast semiconductor parts stocked by broad-line distributors.
> If you think about it, all design is a mysterious mental process that
> is followed up by analysis, which can be equations, simulation, or
> hardware prototyping. Whatever works. The real magic is step 1,
> inventing things.

If you are bad at it, it can look like that. Clowns that like to make a mystery of the process, in order to make their own efforts look more impressive. are a feature of every skilled profession. They don't get sent up as frequently as they should be.
> I'm impressed by computer based high-order filter design, especially
> lossy LC filters. That's been automated since the Fortran days. When I
> twiddle a filter in Spice, it tends to diverge.

Some people are better at twiddling that others. Mostly they have a clearer idea of what they are doing.

--
Bill Sloman, Sydney

On Wednesday, January 24, 2024 at 6:08:46 PM UTC-8, John Larkin wrote:
> On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whi...@gmail.com>
> wrote:
> >On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:
> >
> >> I would like a Spice that was, say, 500x as fast as mine is now,
> >> nvidia or something. And I'd love some way to specify results and have
> >> a program juggle values and even library parts for a best solution.
> >>
> >> Past attempts at such optimizations have tended to diverge. Even most
> >> interns are smarter than that.
> >
> >That's why we have math, that tells us that linear equations (like SPICE solves)
> >have multiple ways to generate large numbers. It's catastrophe theory,
> >to be precise.
> >
> >For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
> >components; there won't ever be any solutions that don't diverge, because
> >the linear-differential-equation solutions all have a matrix raised to
> >a power (and the power goes up with time). It'll always exponentially
> >decay or explode, because NO available component tolerances
> >are negligible effects.

> One of my specialities is designing instant-start super low jitter LC
> oscillators. The Spice sims are dead on, except for tempco
> compensation, which has to be done experimentally. I'd hate to design
> such oscillators using differential equations.

Oh, if you run SPICE, you ARE using differential equations... after
Laplace-transforming them to linear equations using lots of "j ⍵" bits.
The thing that cannot be done, is to do sines with all linear
components; there's no linear equation for a saturating logic
comparator, so it makes a fine oscillator (NE555)
but not a pure sine wave.

Bill Hewlett's classic sine wave oscillator design got around the
problem with a thermal-varying resistor (square law device,
NOT linear).

Doing an oscillator with LC instead of RC gets better jitter, I'm told.
Startup, though, is less linear if the inductor has any
kind of nonlinear character; you want to worry about things
(self-resonant frequencies, or remanent field) when component
selection time comes around.

On Thu, 25 Jan 2024 00:04:20 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:

>On Wednesday, January 24, 2024 at 6:08:46?PM UTC-8, John Larkin wrote:
>> On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whi...@gmail.com>
>> wrote:
>> >On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:
>> >
>> >> I would like a Spice that was, say, 500x as fast as mine is now,
>> >> nvidia or something. And I'd love some way to specify results and have
>> >> a program juggle values and even library parts for a best solution.
>> >>
>> >> Past attempts at such optimizations have tended to diverge. Even most
>> >> interns are smarter than that.
>> >
>> >That's why we have math, that tells us that linear equations (like SPICE solves)
>> >have multiple ways to generate large numbers. It's catastrophe theory,
>> >to be precise.
>> >
>> >For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
>> >components; there won't ever be any solutions that don't diverge, because
>> >the linear-differential-equation solutions all have a matrix raised to
>> >a power (and the power goes up with time). It'll always exponentially
>> >decay or explode, because NO available component tolerances
>> >are negligible effects.
>
>> One of my specialities is designing instant-start super low jitter LC
>> oscillators. The Spice sims are dead on, except for tempco
>> compensation, which has to be done experimentally. I'd hate to design
>> such oscillators using differential equations.
>
>Oh, if you run SPICE, you ARE using differential equations... after
>Laplace-transforming them to linear equations using lots of "j ?" bits.
>The thing that cannot be done, is to do sines with all linear
>components; there's no linear equation for a saturating logic
>comparator, so it makes a fine oscillator (NE555)
>but not a pure sine wave.

If Spice runs differential equations and LaPlace transforms inside, at
least I don't need to know about it. The *concept* of the diff
equation for an LC resonator, energy sloshing around and initial
conditions, is of course basic.

>
>Bill Hewlett's classic sine wave oscillator design got around the
>problem with a thermal-varying resistor (square law device,
>NOT linear).

Yes, incandescent bulb filament. That's OK for a steady-state audio
oscillator. I recall that there's a bit of THD at low frequencies.

>
>Doing an oscillator with LC instead of RC gets better jitter, I'm told.

Yes, factor of a thousand maybe. Tempcos are much better too.

>Startup, though, is less linear if the inductor has any
>kind of nonlinear character; you want to worry about things
>(self-resonant frequencies, or remanent field) when component
>selection time comes around.

Sure. But an air-core inductor is pretty linear. Startup is always
tricky, keeping the first few periods equal to within picoseconds.

Coilcraft has some great parts. Their 1812SMS is kind of magic. I cut
out maybe 4 layers of pcb copper plane below a part like that so the
field doesn't bounce off copper and especially so the pads don't see a
bunch of dreadful FR4 capacitance.

John Larkin <jl@997PotHill.com> wrote:
> On Thu, 25 Jan 2024 00:04:20 -0800 (PST), whit3rd <whit3rd@gmail.com>
> wrote:
>
>> On Wednesday, January 24, 2024 at 6:08:46?PM UTC-8, John Larkin wrote:
>>> On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whi...@gmail.com>
>>> wrote:
>>>> On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:
>>>>
>>>>> I would like a Spice that was, say, 500x as fast as mine is now,
>>>>> nvidia or something. And I'd love some way to specify results and have
>>>>> a program juggle values and even library parts for a best solution.
>>>>>
>>>>> Past attempts at such optimizations have tended to diverge. Even most
>>>>> interns are smarter than that.
>>>>
>>>> That's why we have math, that tells us that linear equations (like SPICE solves)
>>>> have multiple ways to generate large numbers. It's catastrophe theory,
>>>> to be precise.
>>>>
>>>> For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
>>>> components; there won't ever be any solutions that don't diverge, because
>>>> the linear-differential-equation solutions all have a matrix raised to
>>>> a power (and the power goes up with time). It'll always exponentially
>>>> decay or explode, because NO available component tolerances
>>>> are negligible effects.

Depends on what you mean by “ideal.“ For a pure LTI system, I agree.
However, even SPICE isn’t really LTI—besides roundoff and truncation error,
it’s implemented using floating point, which has magnitude limits.

You can easily use a nice noiseless behavioral amp whose gain is a weak
function of the time-averaged amplitude.

That’s an idealized model of the HP200-style ALC.

>>
>>> One of my specialities is designing instant-start super low jitter LC
>>> oscillators. The Spice sims are dead on, except for tempco
>>> compensation, which has to be done experimentally. I'd hate to design
>>> such oscillators using differential equations.
>>
>> Oh, if you run SPICE, you ARE using differential equations... after
>> Laplace-transforming them to linear equations using lots of "j ?" bits.
>> The thing that cannot be done, is to do sines with all linear
>> components; there's no linear equation for a saturating logic
>> comparator, so it makes a fine oscillator (NE555)
>> but not a pure sine wave.
>
> If Spice runs differential equations and LaPlace transforms inside, at
> least I don't need to know about it. The *concept* of the diff
> equation for an LC resonator, energy sloshing around and initial
> conditions, is of course basic.
>
>>
>> Bill Hewlett's classic sine wave oscillator design got around the
>> problem with a thermal-varying resistor (square law device,
>> NOT linear).
>
> Yes, incandescent bulb filament. That's OK for a steady-state audio
> oscillator. I recall that there's a bit of THD at low frequencies.
>
>>
>> Doing an oscillator with LC instead of RC gets better jitter, I'm told.
>
> Yes, factor of a thousand maybe. Tempcos are much better too.
>
>> Startup, though, is less linear if the inductor has any
>> kind of nonlinear character; you want to worry about things
>> (self-resonant frequencies, or remanent field) when component
>> selection time comes around.
>
> Sure. But an air-core inductor is pretty linear. Startup is always
> tricky, keeping the first few periods equal to within picoseconds.
>
> Coilcraft has some great parts. Their 1812SMS is kind of magic. I cut
> out maybe 4 layers of pcb copper plane below a part like that so the
> field doesn't bounce off copper and especially so the pads don't see a
> bunch of dreadful FR4 capacitance.
>
>
Cheers

Phil Hobbs
(Off to a second day of deposition in a patent case.)

--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC /
Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

On Thu, 25 Jan 2024 15:45:48 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>John Larkin <jl@997PotHill.com> wrote:
>> On Thu, 25 Jan 2024 00:04:20 -0800 (PST), whit3rd <whit3rd@gmail.com>
>> wrote:
>>
>>> On Wednesday, January 24, 2024 at 6:08:46?PM UTC-8, John Larkin wrote:
>>>> On Wed, 24 Jan 2024 17:29:57 -0800 (PST), whit3rd <whi...@gmail.com>
>>>> wrote:
>>>>> On Wednesday, January 24, 2024 at 11:15:36?AM UTC-8, john larkin wrote:
>>>>>
>>>>>> I would like a Spice that was, say, 500x as fast as mine is now,
>>>>>> nvidia or something. And I'd love some way to specify results and have
>>>>>> a program juggle values and even library parts for a best solution.
>>>>>>
>>>>>> Past attempts at such optimizations have tended to diverge. Even most
>>>>>> interns are smarter than that.
>>>>>
>>>>> That's why we have math, that tells us that linear equations (like SPICE solves)
>>>>> have multiple ways to generate large numbers. It's catastrophe theory,
>>>>> to be precise.
>>>>>
>>>>> For a stable sine wave oscillator, you can't use ideal C, R, L, and amplifier
>>>>> components; there won't ever be any solutions that don't diverge, because
>>>>> the linear-differential-equation solutions all have a matrix raised to
>>>>> a power (and the power goes up with time). It'll always exponentially
>>>>> decay or explode, because NO available component tolerances
>>>>> are negligible effects.
>
>Depends on what you mean by “ideal.“ For a pure LTI system, I agree.
>However, even SPICE isn’t really LTI—besides roundoff and truncation error,
>it’s implemented using floating point, which has magnitude limits.
>
>You can easily use a nice noiseless behavioral amp whose gain is a weak
>function of the time-averaged amplitude.
>
>That’s an idealized model of the HP200-style ALC.

I just soft clip the Colpitts LC oscillator to about 1 volt p-p, with
a voltage, a diode, and a resistor, with enough excess osc gain to be
sure it's reliable. I only care about the zero crossings - I'm making
a clock - so a little harmonic distortion doesn't matter. Done right,
one can make a sine wave that starts when triggered and is cycle-cycle
invariant starting with the first zero cross. It's a very simple
circuit that has taken us about 30 years to refine. I look back on my
early versions with horror.

One sales point in a digital delay generator is minimal and calibrated
insertion delay. An instant-start clock helps.

The other common DDG technique is to use a crystal-oscillator clock to
time out the coarse delays, and some sort of time measurement and
correction scheme to remove the inherent 1-clock p-p jitter from an
asynchronous trigger [1]. That's messy and adds a lot of insertion
delay. That's what the DG645 does. I rented one to see what's inside.
Turns out that all the "warranty void if sticker removed" stickers
(there were about 10) were the same as ones you can buy from Amazon.

[1] RMS jitter is the clock period divided by sqrt(3) for some bizarre
reason.