• Electronic Design Checklist

    From Three Jeeps@21:1/5 to All on Mon Jul 11 19:01:15 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jjhu...@gmail.com on Mon Jul 11 21:33:43 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Jul 12 10:13:10 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to jjhudak4@gmail.com on Tue Jul 12 07:05:55 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Tue Jul 12 07:34:50 2022
    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!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Three Jeeps on Tue Jul 12 07:27:43 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Tue Jul 12 08:25:41 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Tue Jul 12 08:37:49 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Don Y on Tue Jul 12 12:08:08 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to bitrex on Tue Jul 12 12:12:21 2022
    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... :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Robertson@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Jul 12 09:22:50 2022
    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 :-#)#

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Jul 12 12:16:23 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to John Robertson on Tue Jul 12 09:57:24 2022
    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'!"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Tue Jul 12 10:14:24 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to bitrex on Tue Jul 12 10:16:25 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to bitrex on Tue Jul 12 13:54:45 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Three Jeeps@21:1/5 to jla...@highlandsniptechnology.com on Tue Jul 12 18:01:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to bitrex on Tue Jul 12 17:39:17 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)