Back in the day when I did a lot of digital and analog circuit design, I developed a checklist that was used by design reviewers (and myself) to minimize circuit design defects/blunders, board layout design rules, and mating assembly design rules. Some of the rules were developed from personal experiences, others from books like "The Art of Electronics'.
For example, a rule for digital circuits included use of bypass caps on each IC, unused inputs terminated, ensure correct polarity on caps, check for possible race conditions, pullups on all open collector outputs, etc.

I know a lot of the circuit board layout programs have fairly good DRCs - but I don't know how good. The few schematic capture packages I was familiar with a number of years ago had no such DRCs. Things may have changed.

I am looking for lists that contain rules for the current state of the art devices and chip technologies.
Pointers to design checklist of design tools/programs are appreciated.

Thanks
J

On Monday, July 11, 2022 at 10:01:19 PM UTC-4, jjhu...@gmail.com wrote:
> Back in the day when I did a lot of digital and analog circuit design, I developed a checklist that was used by design reviewers (and myself) to minimize circuit design defects/blunders, board layout design rules, and mating assembly design rules. Some of the rules were developed from personal experiences, others from books like "The Art of Electronics'.
> For example, a rule for digital circuits included use of bypass caps on each IC, unused inputs terminated, ensure correct polarity on caps, check for possible race conditions, pullups on all open collector outputs, etc.
>
> I know a lot of the circuit board layout programs have fairly good DRCs - but I don't know how good. The few schematic capture packages I was familiar with a number of years ago had no such DRCs. Things may have changed.
>
> I am looking for lists that contain rules for the current state of the art devices and chip technologies.
> Pointers to design checklist of design tools/programs are appreciated.

I can't point you to a list, but I can tell you the rule of "bypass caps on each IC" is pretty obsolete. That actually comes from the days of double sided boards with power traces. A bypass cap had to be on each chip, which meant, from pin 8 to pin 16. Yeah, that old!

In reality, power distribution design is a whole topic, vastly more complex than the "cap on every power pin" rule. Your power distribution system should have a design process and a write up that describes how you made your decisions. Many designers don't have a design process other that "a cap on every power pin". Their designs may work, but when designing high volumes, power supply distribution should be cost optimized just like everything else.

--

Rick C.

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

On Mon, 11 Jul 2022 19:01:15 -0700 (PDT), Three Jeeps
<jjhudak4@gmail.com> wrote:

>Back in the day when I did a lot of digital and analog circuit design, I developed a checklist that was used by design reviewers (and myself) to minimize circuit design defects/blunders, board layout design rules, and mating assembly design rules. Some of the rules were developed from personal experiences, others from books like "The Art of Electronics'.
>For example, a rule for digital circuits included use of bypass caps on each IC, unused inputs terminated, ensure correct polarity on caps, check for possible race conditions, pullups on all open collector outputs, etc.
>
>I know a lot of the circuit board layout programs have fairly good DRCs - but I don't know how good. The few schematic capture packages I was familiar with a number of years ago had no such DRCs. Things may have changed.
>
>I am looking for lists that contain rules for the current state of the art devices and chip technologies.
>Pointers to design checklist of design tools/programs are appreciated.
>
>Thanks
>J
>
>

We have an extensive checklist that we run before we release a PCB for
production, but it's more about the board layout than the
schematic-level design. I'll see if I can get permission from The Brat
to post it here.

It would be far more difficult to make a checklist for the electronic
design. We have design reviews for that: PDR, CDR, and lastly PCB, and
lots of brainstorms and informal meets. We have a PDR, preliminary
design review, this afternoon, for a new power supply board. The input
is the first-cut schematic and the draft manual.

I don't use any DRCs in a PCB layout program, past the obvious
clearance and connectivity checks. Too much trouble to set up, too
dumb to be much help. About all a schematic program can do is find
single-ended nets.

This new board has one blue-wire ECO. One FPGA pin won't do the SPI
function it was assigned to. Humans have to check stuff like that.

https://www.dropbox.com/s/2ci6ojajtjdbs1o/P939_Assy_Top.jpg?raw=1

(ECOs should be red wires, a badge of shame like The Scarlet Letter.)

It's astounding how much you have to know to design serious
electronics now. That's probably why kids these days prefer FPGAs or
software, which are clearly bounded and more intellectually pure, ie
easier.

On 7/12/2022 10:05 AM, jlarkin@highlandsniptechnology.com wrote:
> On Mon, 11 Jul 2022 19:01:15 -0700 (PDT), Three Jeeps
> <jjhudak4@gmail.com> wrote:
>
>> Back in the day when I did a lot of digital and analog circuit design, I developed a checklist that was used by design reviewers (and myself) to minimize circuit design defects/blunders, board layout design rules, and mating assembly design rules. Some of the rules were developed from personal experiences, others from books like "The Art of Electronics'.
>> For example, a rule for digital circuits included use of bypass caps on each IC, unused inputs terminated, ensure correct polarity on caps, check for possible race conditions, pullups on all open collector outputs, etc.
>>
>> I know a lot of the circuit board layout programs have fairly good DRCs - but I don't know how good. The few schematic capture packages I was familiar with a number of years ago had no such DRCs. Things may have changed.
>>
>> I am looking for lists that contain rules for the current state of the art devices and chip technologies.
>> Pointers to design checklist of design tools/programs are appreciated.
>>
>> Thanks
>> J
>>
>>
>
> We have an extensive checklist that we run before we release a PCB for
> production, but it's more about the board layout than the
> schematic-level design. I'll see if I can get permission from The Brat
> to post it here.
>
> It would be far more difficult to make a checklist for the electronic
> design. We have design reviews for that: PDR, CDR, and lastly PCB, and
> lots of brainstorms and informal meets. We have a PDR, preliminary
> design review, this afternoon, for a new power supply board. The input
> is the first-cut schematic and the draft manual.
>
> I don't use any DRCs in a PCB layout program, past the obvious
> clearance and connectivity checks. Too much trouble to set up, too
> dumb to be much help. About all a schematic program can do is find
> single-ended nets.
>
> This new board has one blue-wire ECO. One FPGA pin won't do the SPI
> function it was assigned to. Humans have to check stuff like that.
>
> https://www.dropbox.com/s/2ci6ojajtjdbs1o/P939_Assy_Top.jpg?raw=1
>
> (ECOs should be red wires, a badge of shame like The Scarlet Letter.)
>
> It's astounding how much you have to know to design serious
> electronics now. That's probably why kids these days prefer FPGAs or
> software, which are clearly bounded and more intellectually pure, ie
> easier.

It often tends to pay better, too. It's also astounding how many
start-ups who'd gladly pay a software engineer whatever, turn up their
noses at what "serious electronics" costs to do.

I run away from start-ups who are doing projects that involve both
software and hardware and are giving the software guys free spa days
while treating the hardware side like an afterthought (we'll just
outsource that)

On 7/11/2022 7:01 PM, Three Jeeps wrote:
> Back in the day when I did a lot of digital and analog circuit design, I
> developed a checklist that was used by design reviewers (and myself) to
> minimize circuit design defects/blunders, board layout design rules, and
> mating assembly design rules. Some of the rules were developed from personal
> experiences, others from books like "The Art of Electronics'. For example, a
> rule for digital circuits included use of bypass caps on each IC, unused
> inputs terminated, ensure correct polarity on caps, check for possible race
> conditions, pullups on all open collector outputs, etc.

A good deal of that is related to other processes (and preferences) in
the organization -- not "universally accepted". E.g., not just how
many inputs to tie to a pullup (think: noise) but *which* ones to
tie to each pullup (so you can exercise parts of the design by
overdriving a particular pullup without its effects being negated by
other signals that are directly connected to that same pullup.
Ditto pulldowns.

> I know a lot of the circuit board layout programs have fairly good DRCs -
> but I don't know how good. The few schematic capture packages I was
> familiar with a number of years ago had no such DRCs. Things may have
> changed.

IIRC, Strides had them back in the 80's. The problem with all of the
"automated checking" is that it relies on comprehensive "models" of
the components in question. E.g., declaring a pin to be OC and not
just OUTPUT.

And, nowadays, too many pins are multimodal so the design won't know
how the pins will be configured at run time and, thus, can't tell if
you're doing something "wrong".

And, if your design has different stuffing options, flagrant rule
violations often result as two or more options result in different
devices driving (or loading) individual signals -- the tool doesn't
know that only one of U3, U13 or U22 will be stuffed in any given board.

PCB DRCs usually deal with voltage-related clearances, current carrying
capabilities, etc. Some packages will do thermal. But, again, you've
got to have the models in place. As you can't buy a comprehensive
library of EVERY part that exists (or WILL exist), you have to plan on
building those models -- and building them correctly -- within the
framework of the PARTICULAR tool you've chosen. Change tools and
discard library (as you can't often automate the porting of parts
from one tool to another).

> I am looking for lists that contain rules for the current state of the art
> devices and chip technologies. Pointers to design checklist of design
> tools/programs are appreciated.

You can look at the manual pages for current tools to see the options
they support in their DRCs.

On 7/12/2022 7:13 AM, bitrex wrote:
> It often tends to pay better, too. It's also astounding how many start-ups
> who'd gladly pay a software engineer whatever, turn up their noses at what
> "serious electronics" costs to do.
>
> I run away from start-ups who are doing projects that involve both software and
> hardware and are giving the software guys free spa days
> while treating the hardware side like an afterthought (we'll just outsource that)

Because too many designs, now, treat entire "systems" as COTS "components".
Buy a little board that has features X, Y and Z -- even if it also has Q and W
(that might be unneeded).

I am always amazed at how folks will convince themselves to buy a "module"...
and then design another card that addresses the parts that the module doesn't.
So, you're still designing a PCB, have likely complicated the packaging
(or, restricted your choices concerning it) AND are reliant on a more
complex component -- which likely isn't completely documented nor guaranteed
not to change in some meaningful way -- that could become unobtainable,
overnight (as many of the modules are sourced from small shops)

But, people are of the mindset that hardware can be "canned" and neglect
to discipline themselves to treat software similarly; they (largely) approach
it as "ground up" for each project! (I chose my projects to leverage past
designs heavily; I only want to deal with a small part of a design's
uniqueness, not treat everything as novel!)

On Tue, 12 Jul 2022 07:34:50 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/12/2022 7:13 AM, bitrex wrote:
>> It often tends to pay better, too. It's also astounding how many start-ups
>> who'd gladly pay a software engineer whatever, turn up their noses at what
>> "serious electronics" costs to do.
>>
>> I run away from start-ups who are doing projects that involve both software and
>> hardware and are giving the software guys free spa days
>> while treating the hardware side like an afterthought (we'll just outsource that)
>
>Because too many designs, now, treat entire "systems" as COTS "components".
>Buy a little board that has features X, Y and Z -- even if it also has Q and W
>(that might be unneeded).
>
>I am always amazed at how folks will convince themselves to buy a "module"...
>and then design another card that addresses the parts that the module doesn't.
>So, you're still designing a PCB, have likely complicated the packaging
>(or, restricted your choices concerning it) AND are reliant on a more
>complex component -- which likely isn't completely documented nor guaranteed
>not to change in some meaningful way -- that could become unobtainable,
>overnight (as many of the modules are sourced from small shops)
>
>But, people are of the mindset that hardware can be "canned" and neglect
>to discipline themselves to treat software similarly; they (largely) approach
>it as "ground up" for each project! (I chose my projects to leverage past
>designs heavily; I only want to deal with a small part of a design's
>uniqueness, not treat everything as novel!)

We do sometimes use a MicroZed board as a plugin assembly. It does a
lot of tedious stuff, but more importantly we can get them.

We also use some LCD eval boards as displays, because we can get the
evals but we can't get the chips on them.

On Tue, 12 Jul 2022 07:27:43 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/11/2022 7:01 PM, Three Jeeps wrote:
>> Back in the day when I did a lot of digital and analog circuit design, I
>> developed a checklist that was used by design reviewers (and myself) to
>> minimize circuit design defects/blunders, board layout design rules, and
>> mating assembly design rules. Some of the rules were developed from personal
>> experiences, others from books like "The Art of Electronics'. For example, a
>> rule for digital circuits included use of bypass caps on each IC, unused
>> inputs terminated, ensure correct polarity on caps, check for possible race
>> conditions, pullups on all open collector outputs, etc.
>
>A good deal of that is related to other processes (and preferences) in
>the organization -- not "universally accepted". E.g., not just how
>many inputs to tie to a pullup (think: noise) but *which* ones to
>tie to each pullup (so you can exercise parts of the design by
>overdriving a particular pullup without its effects being negated by
>other signals that are directly connected to that same pullup.
>Ditto pulldowns.
>
>> I know a lot of the circuit board layout programs have fairly good DRCs -
>> but I don't know how good. The few schematic capture packages I was
>> familiar with a number of years ago had no such DRCs. Things may have
>> changed.
>
>IIRC, Strides had them back in the 80's. The problem with all of the
>"automated checking" is that it relies on comprehensive "models" of
>the components in question. E.g., declaring a pin to be OC and not
>just OUTPUT.
>
>And, nowadays, too many pins are multimodal so the design won't know
>how the pins will be configured at run time and, thus, can't tell if
>you're doing something "wrong".

Automated checking of stuff like that is hopeless. It's better to let
people do that. You'd even save time by building a board and seeing if
it will work (which we don't like to do. We check things.)

I know of one big organization that defines six distinct steps, and
uses all of them. Why be careful when you know you will have five more
iterations?

>
>And, if your design has different stuffing options, flagrant rule
>violations often result as two or more options result in different
>devices driving (or loading) individual signals -- the tool doesn't
>know that only one of U3, U13 or U22 will be stuffed in any given board.

We live in desperate times. Logic isolators are hard to get, so one
upcoming board will have our preferred parts on top and alternates on
the bottom.

>
>PCB DRCs usually deal with voltage-related clearances, current carrying
>capabilities, etc. Some packages will do thermal. But, again, you've
>got to have the models in place. As you can't buy a comprehensive
>library of EVERY part that exists (or WILL exist), you have to plan on
>building those models -- and building them correctly -- within the
>framework of the PARTICULAR tool you've chosen. Change tools and
>discard library (as you can't often automate the porting of parts
>from one tool to another).
>
>> I am looking for lists that contain rules for the current state of the art
>> devices and chip technologies. Pointers to design checklist of design
>> tools/programs are appreciated.
>
>You can look at the manual pages for current tools to see the options
>they support in their DRCs.

Engineering schools like to teach math and such but seldom mention how
the engineering process is organized. I've worked for and with
multiple outfits, and each one developed a unique way to organize
("organize" in quotes) the design and documentation process. Some are
horrors.

DRC can be a lazy way to avoid hard thinking.

On 7/12/2022 10:34 AM, Don Y wrote:
> On 7/12/2022 7:13 AM, bitrex wrote:
>> It often tends to pay better, too. It's also astounding how many
>> start-ups who'd gladly pay a software engineer whatever, turn up their
>> noses at what "serious electronics" costs to do.
>>
>> I run away from start-ups who are doing projects that involve both
>> software and hardware and are giving the software guys free spa days
>> while treating the hardware side like an afterthought (we'll just
>> outsource that)
>
> Because too many designs, now, treat entire "systems" as COTS "components".
> Buy a little board that has features X, Y and Z -- even if it also has Q
> and W
> (that might be unneeded).
>
> I am always amazed at how folks will convince themselves to buy a
> "module"...
> and then design another card that addresses the parts that the module
> doesn't.
> So, you're still designing a PCB, have likely complicated the packaging
> (or, restricted your choices concerning it) AND are reliant on a more
> complex component -- which likely isn't completely documented nor
> guaranteed
> not to change in some meaningful way -- that could become unobtainable,
> overnight (as many of the modules are sourced from small shops)
>
> But, people are of the mindset that hardware can be "canned" and neglect
> to discipline themselves to treat software similarly; they (largely)
> approach
> it as "ground up" for each project!  (I chose my projects to leverage past
> designs heavily; I only want to deal with a small part of a design's
> uniqueness, not treat everything as novel!)

Going back to Mr. Larkin's comment about "It's astounding how much you
have to know to design serious electronics now" some potential clients
seem to want one to be both a hotshot circuit designer and a hotshot PCB
layout person also, which IMO is asking a lot.

I can understand the perspective that the person who designed the design
is sometimes the best to lay it out, but still.

Particularly frustrating in a few cases I've had where I've told the
potential client "Yeah I have a past design that I can modify to suit
your requirements no problem, can have you up in running in no t..."

"We need the absolute best production-cost-optimized PCB for it, also."

"Well I'm probably not the best person to do tha.."

"Ok, not interested we'll look elsewhere."

And then some time later they're still looking. Meanwhile they probably
got nine coders on staff.

I also see it's pretty common in this area for various companies to have
open positions for "Senior Hardware Dev" that go unfilled for months or
years.

On 7/12/2022 12:08 PM, bitrex wrote:
> On 7/12/2022 10:34 AM, Don Y wrote:
>> On 7/12/2022 7:13 AM, bitrex wrote:
>>> It often tends to pay better, too. It's also astounding how many
>>> start-ups who'd gladly pay a software engineer whatever, turn up
>>> their noses at what "serious electronics" costs to do.
>>>
>>> I run away from start-ups who are doing projects that involve both
>>> software and hardware and are giving the software guys free spa days
>>> while treating the hardware side like an afterthought (we'll just
>>> outsource that)
>>
>> Because too many designs, now, treat entire "systems" as COTS
>> "components".
>> Buy a little board that has features X, Y and Z -- even if it also has
>> Q and W
>> (that might be unneeded).
>>
>> I am always amazed at how folks will convince themselves to buy a
>> "module"...
>> and then design another card that addresses the parts that the module
>> doesn't.
>> So, you're still designing a PCB, have likely complicated the packaging
>> (or, restricted your choices concerning it) AND are reliant on a more
>> complex component -- which likely isn't completely documented nor
>> guaranteed
>> not to change in some meaningful way -- that could become unobtainable,
>> overnight (as many of the modules are sourced from small shops)
>>
>> But, people are of the mindset that hardware can be "canned" and neglect
>> to discipline themselves to treat software similarly; they (largely)
>> approach
>> it as "ground up" for each project!  (I chose my projects to leverage
>> past
>> designs heavily; I only want to deal with a small part of a design's
>> uniqueness, not treat everything as novel!)
>
> Going back to Mr. Larkin's comment about "It's astounding how much you
> have to know to design serious electronics now" some potential clients
> seem to want one to be both a hotshot circuit designer and a hotshot PCB
> layout person also, which IMO is asking a lot.
>
> I can understand the perspective that the person who designed the design
> is sometimes the best to lay it out, but still.
>
> Particularly frustrating in a few cases I've had where I've told the
> potential client "Yeah I have a past design that I can modify to suit
> your requirements no problem, can have you up in running in no t..."
>
> "We need the absolute best production-cost-optimized PCB for it, also."
>
> "Well I'm probably not the best person to do tha.."
>
> "Ok, not interested we'll look elsewhere."

I should probably just raise my price, use the extra to hire someone to
assist me myself and shut my mouth about it, huh... :)

On 7/12/2022 11:37 AM, jlarkin@highlandsniptechnology.com wrote:
> On Tue, 12 Jul 2022 07:27:43 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 7/11/2022 7:01 PM, Three Jeeps wrote:
>>> Back in the day when I did a lot of digital and analog circuit design, I
>>> developed a checklist that was used by design reviewers (and myself) to
>>> minimize circuit design defects/blunders, board layout design rules, and
>>> mating assembly design rules. Some of the rules were developed from personal
>>> experiences, others from books like "The Art of Electronics'. For example, a
>>> rule for digital circuits included use of bypass caps on each IC, unused
>>> inputs terminated, ensure correct polarity on caps, check for possible race
>>> conditions, pullups on all open collector outputs, etc.
>>
>> A good deal of that is related to other processes (and preferences) in
>> the organization -- not "universally accepted". E.g., not just how
>> many inputs to tie to a pullup (think: noise) but *which* ones to
>> tie to each pullup (so you can exercise parts of the design by
>> overdriving a particular pullup without its effects being negated by
>> other signals that are directly connected to that same pullup.
>> Ditto pulldowns.
>>
>>> I know a lot of the circuit board layout programs have fairly good DRCs -
>>> but I don't know how good. The few schematic capture packages I was
>>> familiar with a number of years ago had no such DRCs. Things may have
>>> changed.
>>
>> IIRC, Strides had them back in the 80's. The problem with all of the
>> "automated checking" is that it relies on comprehensive "models" of
>> the components in question. E.g., declaring a pin to be OC and not
>> just OUTPUT.
>>
>> And, nowadays, too many pins are multimodal so the design won't know
>> how the pins will be configured at run time and, thus, can't tell if
>> you're doing something "wrong".
>
> Automated checking of stuff like that is hopeless. It's better to let
> people do that. You'd even save time by building a board and seeing if
> it will work (which we don't like to do. We check things.)
>
> I know of one big organization that defines six distinct steps, and
> uses all of them. Why be careful when you know you will have five more
> iterations?
>
>>
>> And, if your design has different stuffing options, flagrant rule
>> violations often result as two or more options result in different
>> devices driving (or loading) individual signals -- the tool doesn't
>> know that only one of U3, U13 or U22 will be stuffed in any given board.
>
> We live in desperate times. Logic isolators are hard to get, so one
> upcoming board will have our preferred parts on top and alternates on
> the bottom.

How fast do you need to go, can you not get there with discretes?

On 2022/07/12 8:37 a.m., jlarkin@highlandsniptechnology.com wrote:
> On Tue, 12 Jul 2022 07:27:43 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 7/11/2022 7:01 PM, Three Jeeps wrote:
>>> Back in the day when I did a lot of digital and analog circuit design, I
>>> developed a checklist that was used by design reviewers (and myself) to
>>> minimize circuit design defects/blunders, board layout design rules, and
>>> mating assembly design rules. Some of the rules were developed from personal
>>> experiences, others from books like "The Art of Electronics'. For example, a
>>> rule for digital circuits included use of bypass caps on each IC, unused
>>> inputs terminated, ensure correct polarity on caps, check for possible race
>>> conditions, pullups on all open collector outputs, etc.
>>
>> A good deal of that is related to other processes (and preferences) in
>> the organization -- not "universally accepted". E.g., not just how
>> many inputs to tie to a pullup (think: noise) but *which* ones to
>> tie to each pullup (so you can exercise parts of the design by
>> overdriving a particular pullup without its effects being negated by
>> other signals that are directly connected to that same pullup.
>> Ditto pulldowns.
>>
>>> I know a lot of the circuit board layout programs have fairly good DRCs -
>>> but I don't know how good. The few schematic capture packages I was
>>> familiar with a number of years ago had no such DRCs. Things may have
>>> changed.
>>
>> IIRC, Strides had them back in the 80's. The problem with all of the
>> "automated checking" is that it relies on comprehensive "models" of
>> the components in question. E.g., declaring a pin to be OC and not
>> just OUTPUT.
>...
>>
>> And, if your design has different stuffing options, flagrant rule
>> violations often result as two or more options result in different
>> devices driving (or loading) individual signals -- the tool doesn't
>> know that only one of U3, U13 or U22 will be stuffed in any given board.
>
> We live in desperate times. Logic isolators are hard to get, so one
> upcoming board will have our preferred parts on top and alternates on
> the bottom.
>
....

Not the first time circuit boards have been laid out to allow for supply
disruptions. In pinball games in the early 80s it wasn't uncommon for
manufacturers to have several overlapping device layouts to cover
possible shortages of HV chips.

John :-#)#

On 7/12/2022 9:22 AM, John Robertson wrote:
> Not the first time circuit boards have been laid out to allow for supply
> disruptions. In pinball games in the early 80s it wasn't uncommon for
> manufacturers to have several overlapping device layouts to cover possible
> shortages of HV chips.

You don't even have to be covering for supply problems.

E.g., I would routinely plug SRAM into EPROM sites to ease development
(write image into SRAM, flip a "write protect" switch -- bad things
happen, otherwise -- and run AS IF you wer using EPROM). Software guys
loved me as waiting for EPROMs to burn is a tedious waste of time. It
limits how often you can "turn the crank" in a typical day. And, with
a writeable store, you can patch a live system instead of having to
do a new build!

So, you have tristate outputs on the EPROM device, on the scheme, as well
as I/Os for the SRAM replacement.

"And what is WE\ doing tied to that *EPROM* (site)??"

["No, we're not going to ship the machines with all that expensive SRAM
inside! We just need a few prototypes and it's silly to design a different
board JUST for 'development'!"

On 7/12/2022 9:08 AM, bitrex wrote:
> On 7/12/2022 10:34 AM, Don Y wrote:
>> On 7/12/2022 7:13 AM, bitrex wrote:
>>> It often tends to pay better, too. It's also astounding how many start-ups
>>> who'd gladly pay a software engineer whatever, turn up their noses at what
>>> "serious electronics" costs to do.
>>>
>>> I run away from start-ups who are doing projects that involve both software
>>> and hardware and are giving the software guys free spa days
>>> while treating the hardware side like an afterthought (we'll just outsource
>>> that)
>>
>> Because too many designs, now, treat entire "systems" as COTS "components".
>> Buy a little board that has features X, Y and Z -- even if it also has Q and W
>> (that might be unneeded).
>>
>> I am always amazed at how folks will convince themselves to buy a "module"...
>> and then design another card that addresses the parts that the module doesn't.
>> So, you're still designing a PCB, have likely complicated the packaging
>> (or, restricted your choices concerning it) AND are reliant on a more
>> complex component -- which likely isn't completely documented nor guaranteed
>> not to change in some meaningful way -- that could become unobtainable,
>> overnight (as many of the modules are sourced from small shops)
>>
>> But, people are of the mindset that hardware can be "canned" and neglect
>> to discipline themselves to treat software similarly; they (largely) approach
>> it as "ground up" for each project! (I chose my projects to leverage past
>> designs heavily; I only want to deal with a small part of a design's
>> uniqueness, not treat everything as novel!)
>
> Going back to Mr. Larkin's comment about "It's astounding how much you have to
> know to design serious electronics now" some potential clients seem to want one
> to be both a hotshot circuit designer and a hotshot PCB layout person also,
> which IMO is asking a lot.

I've typically left (production) layout to someone who does that exclusively.
They know what their pick-n-place kit's restrictions are, how they like to
panelize boards, the sorts of test fixtures they'll want, packaging details
(which will likely change) etc.

I layout prototypes (simply because its easier to prototype in foil than
any other technique) as an expedient -- no need to wait for the client to
develop "proper" schematic symbols, PCB footprints, etc. And, I can
put in any "hooks" that *I* might think helpful (which may well be
elided in production).

> I can understand the perspective that the person who designed the design is
> sometimes the best to lay it out, but still.

IME, the more effective combination is hardware-software codesign (not hardware
and layout). Designs wherein the hardware and software were independently
(orthogonally) created often have clumsier implementations.

E.g., I designed a removable sensor array in a product. I wanted the software
(which I was also writing) to be able to detect when the array was "not
connected", connected but one or more sensors shorted -- or opened, etc.
And, not spend any recurring dollars to do so!

> Particularly frustrating in a few cases I've had where I've told the potential
> client "Yeah I have a past design that I can modify to suit your requirements
> no problem, can have you up in running in no t..."
>
> "We need the absolute best production-cost-optimized PCB for it, also."

Hardware is cheap. Spend your time coming up with ways to cut software
development and maintenance costs (assuming most products have software in
them). And, other "support" costs (e.g., depot repair).

E.g., if someone is going to have to look at a unit after the sale, that's
a $100+ hit to profit (or, adder for the customer's TCO)

> "Well I'm probably not the best person to do tha.."

ALWAYS the best approach. I've had folks balk at some of my estimates.
No, I'm not going to "rethink them" with an eye towards cutting YOUR cost.
Find someone else who is "less expensive" (or, more efficient OR less
accurate in their estimating). And, if you are honest with yourself,
you'll look at those actual costs to see if you're decision making process
is in need of review.

> "Ok, not interested we'll look elsewhere."
>
> And then some time later they're still looking. Meanwhile they probably got
> nine coders on staff.
>
> I also see it's pretty common in this area for various companies to have open
> positions for "Senior Hardware Dev" that go unfilled for months or years.

Hardware is seen as easier and a "one time" process. A hardware revision
is almost always to fix a fuckup (in design, use or supply). Software is
also, often, for "fixes". But, also, for *enhancements*. It is not
uncommon to release a product with a plan in place as to how to evolve
the implementation, over time. If you have to swap/add boards, then it's
costly.

So, you want (need?) *one* guy who can tackle all of your imagined needs.
In practice, its usually easier to outsource that, as req'd.

I have a buddy that I always sub work for low noise analog design. OTOH,
he calls me for anything digital/integrated. We're each capable of doing
both. But, have more expertise in our own little domains and the trust we
share means it is easy to sub portions out -- without long negotiations, etc.

On Tue, 12 Jul 2022 12:16:23 -0400, bitrex <user@example.net> wrote:

>On 7/12/2022 11:37 AM, jlarkin@highlandsniptechnology.com wrote:
>> On Tue, 12 Jul 2022 07:27:43 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> On 7/11/2022 7:01 PM, Three Jeeps wrote:
>>>> Back in the day when I did a lot of digital and analog circuit design, I
>>>> developed a checklist that was used by design reviewers (and myself) to
>>>> minimize circuit design defects/blunders, board layout design rules, and
>>>> mating assembly design rules. Some of the rules were developed from personal
>>>> experiences, others from books like "The Art of Electronics'. For example, a
>>>> rule for digital circuits included use of bypass caps on each IC, unused
>>>> inputs terminated, ensure correct polarity on caps, check for possible race
>>>> conditions, pullups on all open collector outputs, etc.
>>>
>>> A good deal of that is related to other processes (and preferences) in
>>> the organization -- not "universally accepted". E.g., not just how
>>> many inputs to tie to a pullup (think: noise) but *which* ones to
>>> tie to each pullup (so you can exercise parts of the design by
>>> overdriving a particular pullup without its effects being negated by
>>> other signals that are directly connected to that same pullup.
>>> Ditto pulldowns.
>>>
>>>> I know a lot of the circuit board layout programs have fairly good DRCs -
>>>> but I don't know how good. The few schematic capture packages I was
>>>> familiar with a number of years ago had no such DRCs. Things may have
>>>> changed.
>>>
>>> IIRC, Strides had them back in the 80's. The problem with all of the
>>> "automated checking" is that it relies on comprehensive "models" of
>>> the components in question. E.g., declaring a pin to be OC and not
>>> just OUTPUT.
>>>
>>> And, nowadays, too many pins are multimodal so the design won't know
>>> how the pins will be configured at run time and, thus, can't tell if
>>> you're doing something "wrong".
>>
>> Automated checking of stuff like that is hopeless. It's better to let
>> people do that. You'd even save time by building a board and seeing if
>> it will work (which we don't like to do. We check things.)
>>
>> I know of one big organization that defines six distinct steps, and
>> uses all of them. Why be careful when you know you will have five more
>> iterations?
>>
>>>
>>> And, if your design has different stuffing options, flagrant rule
>>> violations often result as two or more options result in different
>>> devices driving (or loading) individual signals -- the tool doesn't
>>> know that only one of U3, U13 or U22 will be stuffed in any given board.
>>
>> We live in desperate times. Logic isolators are hard to get, so one
>> upcoming board will have our preferred parts on top and alternates on
>> the bottom.
>
>How fast do you need to go, can you not get there with discretes?

We will probably use a 6x TI isolator, 5 channels one way and one
back. Because we can get them. We'd like to drive an isolated AD7699
ADC at 15 or 20 MHz clock rate.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

On Tue, 12 Jul 2022 12:08:08 -0400, bitrex <user@example.net> wrote:

>On 7/12/2022 10:34 AM, Don Y wrote:
>> On 7/12/2022 7:13 AM, bitrex wrote:
>>> It often tends to pay better, too. It's also astounding how many
>>> start-ups who'd gladly pay a software engineer whatever, turn up their
>>> noses at what "serious electronics" costs to do.
>>>
>>> I run away from start-ups who are doing projects that involve both
>>> software and hardware and are giving the software guys free spa days
>>> while treating the hardware side like an afterthought (we'll just
>>> outsource that)
>>
>> Because too many designs, now, treat entire "systems" as COTS "components".
>> Buy a little board that has features X, Y and Z -- even if it also has Q
>> and W
>> (that might be unneeded).
>>
>> I am always amazed at how folks will convince themselves to buy a
>> "module"...
>> and then design another card that addresses the parts that the module
>> doesn't.
>> So, you're still designing a PCB, have likely complicated the packaging
>> (or, restricted your choices concerning it) AND are reliant on a more
>> complex component -- which likely isn't completely documented nor
>> guaranteed
>> not to change in some meaningful way -- that could become unobtainable,
>> overnight (as many of the modules are sourced from small shops)
>>
>> But, people are of the mindset that hardware can be "canned" and neglect
>> to discipline themselves to treat software similarly; they (largely)
>> approach
>> it as "ground up" for each project!  (I chose my projects to leverage past
>> designs heavily; I only want to deal with a small part of a design's
>> uniqueness, not treat everything as novel!)
>
>Going back to Mr. Larkin's comment about "It's astounding how much you
>have to know to design serious electronics now" some potential clients
>seem to want one to be both a hotshot circuit designer and a hotshot PCB
>layout person also, which IMO is asking a lot.
>
>I can understand the perspective that the person who designed the design
>is sometimes the best to lay it out, but still.

In my experience, the best PCB designers have been women who didn't
understand electronics.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

On Tuesday, July 12, 2022 at 12:12:28 PM UTC-4, bitrex wrote:
> On 7/12/2022 12:08 PM, bitrex wrote:
> > On 7/12/2022 10:34 AM, Don Y wrote:
> >> On 7/12/2022 7:13 AM, bitrex wrote:
> >>> It often tends to pay better, too. It's also astounding how many
> >>> start-ups who'd gladly pay a software engineer whatever, turn up
> >>> their noses at what "serious electronics" costs to do.
> >>>
> >>> I run away from start-ups who are doing projects that involve both
> >>> software and hardware and are giving the software guys free spa days
> >>> while treating the hardware side like an afterthought (we'll just
> >>> outsource that)
> >>
> >> Because too many designs, now, treat entire "systems" as COTS
> >> "components".
> >> Buy a little board that has features X, Y and Z -- even if it also has
> >> Q and W
> >> (that might be unneeded).
> >>
> >> I am always amazed at how folks will convince themselves to buy a
> >> "module"...
> >> and then design another card that addresses the parts that the module
> >> doesn't.
> >> So, you're still designing a PCB, have likely complicated the packaging
> >> (or, restricted your choices concerning it) AND are reliant on a more
> >> complex component -- which likely isn't completely documented nor
> >> guaranteed
> >> not to change in some meaningful way -- that could become unobtainable,
> >> overnight (as many of the modules are sourced from small shops)
> >>
> >> But, people are of the mindset that hardware can be "canned" and neglect
> >> to discipline themselves to treat software similarly; they (largely)
> >> approach
> >> it as "ground up" for each project! (I chose my projects to leverage
> >> past
> >> designs heavily; I only want to deal with a small part of a design's
> >> uniqueness, not treat everything as novel!)
> >
> > Going back to Mr. Larkin's comment about "It's astounding how much you
> > have to know to design serious electronics now" some potential clients
> > seem to want one to be both a hotshot circuit designer and a hotshot PCB
> > layout person also, which IMO is asking a lot.
> >
> > I can understand the perspective that the person who designed the design
> > is sometimes the best to lay it out, but still.
> >
> > Particularly frustrating in a few cases I've had where I've told the
> > potential client "Yeah I have a past design that I can modify to suit
> > your requirements no problem, can have you up in running in no t..."
> >
> > "We need the absolute best production-cost-optimized PCB for it, also."
> >
> > "Well I'm probably not the best person to do tha.."
> >
> > "Ok, not interested we'll look elsewhere."
> I should probably just raise my price, use the extra to hire someone to
> assist me myself and shut my mouth about it, huh... :)

If you can raise your price, why haven't you done that already?

As to hiring someone, I was working at a defense contractor making two way radios. We were adopting some four letter abbreviation for hardware that the software guys already used a three letter form of. We were writing our justifications for our estimates and we pretty much all added time for dealing with the paperwork of this new paradigm. We got yelled at for adding time for this, because if it took more work, something was wrong. It was supposed to let us work more effectively. This company had grown so fast, it essentially had become a new company, a young company, and few people knew how to bid the durn thing.

My point is, if you have to raise your price to hire someone, maybe that's a mistake.

I will say it is seldom a good idea to say you can't do something, unless it really is not something you can do. I try not to shy away from learning opportunities if I think I can learn how to do it.

--

Rick C.

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

On Tuesday, July 12, 2022 at 10:06:05 AM UTC-4, jla...@highlandsniptechnology.com wrote:
> On Mon, 11 Jul 2022 19:01:15 -0700 (PDT), Three Jeeps
> <jjhu...@gmail.com> wrote:
>
> >Back in the day when I did a lot of digital and analog circuit design, I developed a checklist that was used by design reviewers (and myself) to minimize circuit design defects/blunders, board layout design rules, and mating assembly design rules. Some of the rules were developed from personal experiences, others from books like "The Art of Electronics'.
> >For example, a rule for digital circuits included use of bypass caps on each IC, unused inputs terminated, ensure correct polarity on caps, check for possible race conditions, pullups on all open collector outputs, etc.
> >
> >I know a lot of the circuit board layout programs have fairly good DRCs - but I don't know how good. The few schematic capture packages I was familiar with a number of years ago had no such DRCs. Things may have changed.
> >
> >I am looking for lists that contain rules for the current state of the art devices and chip technologies.
> >Pointers to design checklist of design tools/programs are appreciated.
> >
> >Thanks
> >J
> >
> >
> We have an extensive checklist that we run before we release a PCB for
> production, but it's more about the board layout than the
> schematic-level design. I'll see if I can get permission from The Brat
> to post it here.
>
> It would be far more difficult to make a checklist for the electronic
> design. We have design reviews for that: PDR, CDR, and lastly PCB, and
> lots of brainstorms and informal meets. We have a PDR, preliminary
> design review, this afternoon, for a new power supply board. The input
> is the first-cut schematic and the draft manual.
>
> I don't use any DRCs in a PCB layout program, past the obvious
> clearance and connectivity checks. Too much trouble to set up, too
> dumb to be much help. About all a schematic program can do is find
> single-ended nets.
>
> This new board has one blue-wire ECO. One FPGA pin won't do the SPI
> function it was assigned to. Humans have to check stuff like that.
>
> https://www.dropbox.com/s/2ci6ojajtjdbs1o/P939_Assy_Top.jpg?raw=1
>
> (ECOs should be red wires, a badge of shame like The Scarlet Letter.)
>
> It's astounding how much you have to know to design serious
> electronics now. That's probably why kids these days prefer FPGAs or K
> software, which are clearly bounded and more intellectually pure, ie
> easier.

Thank you.
I understand and agree with how much one has to know. I also agree about human eyes and brains on the design. My goal for seeking checklists is to help guide thinking.
My undergrad courses were geared to both understanding and applying all the design equations and 'theory' as well as the practical aspect of actually building things. Grad school was all about theory. My first exposure to designing and building real boards & systems met with 'looks good on paper but doesn't work on the wirewrap/proto board.'...An older experienced EE explained some of the realities. I, in turn passed on my learning and experiences to new EE's.
I also understand the complexity factor has been ratcheted up since my hands on design days, that I why is posed the request. My last real boards was a amd 29000 bit-slice cpu used for jet engine simulation. Learned some interesting things about dynamic RAM on that one....
Thanks for the insight.
BTW, I worked in a small group of both hardware EEs and Sw engineers. We found that intense design reviews caught both design and potential implementation problems. Things worked well for the most part. One day we hired a EE who 'knew everything' and our design reviews turned into him always knowing better and not dealing with the design at hand. Some points were valid, most were to show how smart/clever he was. During that time, I was fortunate enough to learn some of the 'art' of electronics as well as behavior aspects of certain components. (Also learned that data sheets are not always correct - imagine that).
j