design rigor: electronics vs. software

I said I was done trying to teach you the theory of computation.

Principal engineer. Held that title in that company for 12 of the 17 years I was there. I was also a founder.

Clifford Heath wrote in news:3YcTF.32875$Mc.7726 @fx35.iad:

FPGA (as one example)programming is the programmer telling the hardware what switches he wants it to use in what order, etc. So just like a hardware built device like a clock the signals on the hour but is 100% hardware driven, electronics can be built with or without 'processors' and still have events get 'processed'.

Programming (and the electronics behind it) is just our refinement of Frankenstein's big double blade throw switch on the wall.

Programming against a fault condition in a mission critical setting is rife with problems.

Like the attitude indictaor. Why would one even freeze up? Pretty cold up there in that airstream. So built a unit that has built in mechanical function protections in it to ensure it never stops working and never gives a false reading based on a failed mechanical aspect of its operation. Easy to say.

I suggested maybe heating the thing internally (the part that is inside the aircraft skin) and placing a mechanism in there that allows it to be 'swung' through it entire range of motion as a test of freedom of movement, and then released for use again. Could have sensors and a computer watching the test run and looking at bearing temps, etc.. Then it would decide the unit is good and can be relied on for an accurate reaing, If there is not a bird hanging off the thing outside or if it got sheared off clean yet still was able to be rotated in the test, the two most extreme failure modes.

When I get a warning, I fix it before I run the sim. That would explain why I haven't seen the old-netlist-runs thing.

I do label a lot of nodes, but just the interesting ones, not all.

I need to force myself to check all the named nodes when I copy/paste bits of a circuit. It duplicates all named nodes, which creates some interesting shorts.

--

John Larkin         Highland Technology, Inc 

The cork popped merrily, and Lord Peter rose to his feet.  
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

I understand that some people are content to just do their jobs and cash their checks.

I recently discovered that one group has been responsible, for almost

20 years, for a bunch of instrumentation of which over 80% doesn't work, and which is not used. But they still get their paychecks, so don't rock the boat.

--

John Larkin         Highland Technology, Inc 

The cork popped merrily, and Lord Peter rose to his feet.  
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

Hey, you said that you wouldn't waste more time on him.

--

John Larkin         Highland Technology, Inc 

The cork popped merrily, and Lord Peter rose to his feet.  
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

When you name the nodes, use names made from adjacent components, such as R1C1, Q1B, U1N, etc.

When you copy and paste, the component reference designations will change. You can easily find the erroneous node names since they won't match the adjacent components.

When you name a node, use names made from adjacent components, such as R1C1, Q1B, U1N, etc.

When you copy and post, the component reference designations will change, but the named nodes will remain the same. You can easily find them since they won't match the new reference designations.

So, what is in the job description of the programmers under consideration? I'll bet the prime statement is "implement the specification using the defined processes"

Nothing new there!

I'd rather cut my own throat than do that for 20 years. Sometimes my stuff doesn't work either, but that's due to it being insanely hard. A lot of the insanely hard stuff works really well though, which makes it all worthwhile. (I've often said that my ideal project is building a computer starting with sand--it's a tendency I have to fight.)

Client work almost always succeeds, and the occasional failures are mostly due to the customer's prevarication, such as taking my proof-of-concept system, giving it to a CE outfit, and then pulling me back in to attempt to fix the CE's mess--of course at the last minute, when they've almost run out of money. That's happened a couple of times, so I try very hard to discourage it. (The two were the transcutaneous blood glucose/alcohol system and the blood-spot detector for hens' eggs.)

Cheers

Phil Hobbs

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

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

When our stuff doesn't work, it's usually because of some dumb mistake, which we can fix.

The other kind of "failure" is when our stuff works, but the customer's system or product doesn't work, or doesn't sell, or after we do it, they discover that they can do it themselves.

--

John Larkin         Highland Technology, Inc 

The cork popped merrily, and Lord Peter rose to his feet.  
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

I very deliberately avoided the "20 years experience being 1 year repeated 20 times" trap.

I use a specific example from my early career, and the technique I used to avoid it, to sensitise youngsters to the kind of decisions they may face in the future.

Herbert's ?they?d chosen always the clear, safe course that leads ever downward into stagnation.? was an awful warning for me.

But in some companies, and worse industries, that can be a very difficult trap to avoid.

On Sunday, January 12, 2020 at 7:33:40 PM UTC-5, Phil Hobbs wrote:

Phil, et al.... I meant to post some information wrt your inquiry about techniques to expre ss and analyze requirements and about model checking but got OBE. I found this slide set that rather concisely lays out the problem & approac hes to express requirements.

When I read through English text requirements, I tend to do two things simu ltaneously: map them to some abstract component in the system hierarchy (be cause the written requirements are usually spread all over the system, Re-e xpress them in a semi formal or formal notation (usually semi-formal such a s state-charts, ER diagrams, sequence diagrams, interaction diagrams.) This gives me an idea if things are collectively coherent. I look for conflicts and omissions primarily. I then take my understanding of the components and their interactions and t hen construct an AADL model to: understand who talks to who, data communica ted, and then map requirements to the components and do analysis on the mod el (signal flows and latency are usually the top properties. I then try to tease out what the fault tolerance approach is and model that, keeping in mind error types and look for error flow, mitigation approaches, etc. If there is an area that is really confusing, I'll construct state models a nd use model checking. Some useful tools are nuSMV,

and SPIN As a note, using model checking for the engineer can be a challenge. They have not seen anything like this in undergrad or grad school unless they ar e leaning more in computer science. We looked at this issue 20 years ago a nd produced a number of reports that tried to take the approach as a tool k it and identified types of analysis and patterns that could be identified a nd more easily applied by an engineer unfamiliar with the area. They are s omewhere on the SEI website.

Speaking of model checking, below are two of the more often cited model che cking approaches and successful applications. There is little 'how to' but more of here is the problem and how we solved it. (Details left to the rea der ;) )

rotocol.pdf

There is a report from NASA some years ago that gave some excellent guideli nes in writing requirements - I can't locate it at the moment but this webs ite has some good guidelines, many of which were in the NASA report.

(It still amazes me that even now, requirements docs that I've seen don't d o half of these things....) Hope this helps J

I was talking to my MD, a really wonderful lady, about problem solving. The thing is, her mistakes might kill people, but I can blow things up just to see what might happen.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

Absolutely. Sometimes common sense is safer than nuance.

(Not to start a political branch.)

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

I'd rather use something that describes the signal, not the parts. Like ADC_IN or something. So the plots make sense and can be used as illustrations in manuals, for example.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

That's why in modern times you avoid working with "naked" ones at all costs. In architectures with managed memory like x86 and ARM with an operating system there's pretty much no good reason to use naked pointers at all unless you are yourself writing a memory manager or allocator. There are test suites to find all potential memory leaks! There's no good excuse to have programs that leak resources anymore...

That's a bit strong. It's still reasonable to use void* deep in the implementation of templates for performance-critical stuff. My clusterized EM simulator uses bare pointers in structs, because they vectorize dramatically better, but again that's optimized innermost-loop stuff.

For other things, std::shared_ptr, std::unique_ptr, std::weak_ptr, and the standard containers are the bomb.

RAII is really good medicine. I used to like mudflap a lot, but it got rolled up into GCC's sanitizers, which are super useful too.

Cheers

Phil Hobbs

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

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

Some electronics/software people are in the position that their products can people, even when they are working as designed.

That /ought/ to colour their mentality and practices!

of course. Vin, Vout, Clk, Diff, VCC, etc. These are all good for external connecting signals.

But if you want signals internal to a circuit block, you need some way to identify them. If you leave them unnamed, they will get renumbered every time you make a change to the circuit. So you cannot use unnamed nodes to plot waveforms.

I find it saves time to go ahead and name every node. It doesn't take long, and you don't have to waste time naming a node that you find out you need, then re-run the sim again.