design rigor: electronics vs. software

That board is duck soup to lay out. It literally would take very little skill to do it. Mostly it is easy because there is so much space to work in all you need to do is route the signals.

Can't really see detail around the BGA, but it looks like either no vias or via in pad. Either way, the traces are fat enough you probably route them to the outer two rows only. That really makes life easy with BGA routing.

I try to avoid BGAs because of the fine design rules it places on the boards. Maybe that's no big deal with some fab houses, but in general going below 5/5 design rules starts to cost more in the board. Also the micro vias run the price up too.

Maybe the best in India... I'm just sayin'...

If your car crashed once every three years due to software glitches I don't think you would be as impressed...

John :-#(#

I dunno, a 176-pin PLCCC and a 256-pin BGA, plus lots of other critical stuff, that's not so clear.

Anyway, I think John made his point.

I don't follow your thinking. The size of the parts aren't important if th ere is lots of space to run the traces. The 176 pin QFp is trivial really. Notice it only has connections to a couple of dozen pads.

This board was stuffed to the gills with parts on both sides and a very, ve ry challenging layout. The rev 1.1 board was in production and some upgrad es were requested. The result was barely able to fit on the board. At one point I was ready to give up and I found a way to better overlap pads on t he two sides to free up just enough space to complete the routing.

That was a hard layout.

If I have to redo the board it will require using a BGA unless one of the n ew FPGA brands offer a part in an appropriate package. The BGA has many mo re pins with little advantage since I don't need the large number of I/Os. In fact they would make routing harder given the difficulties of fan out o n a BGA. That's why having a lot of board space makes routing a snap.

And what was that other than showing his design?

There are four photodiode time stampers with 6 ps resolution, and three delay generators with sub-ps resolution. There's a high-speed SPI-like link to a control computer, and five more to energy measurement boxes. Lots of controlled-impedance clocks and signals.

Rev A worked perfectly first try. No breadboards, no prototypes, no cuts or jumpers. 6 layers.

Article is from June of last year. Zero evidence that "outsourced coders" had anything to do with the 737 Max's fatal problems.

Nope, despite numerous attempts to pin the blame on the backwards foreigners all the evidence points to the s******ds in question being the best lily-White American-know-how engineers and managers money could buy employed at the top levels of the Boeing.

Liked article is from June of last year. Zero evidence that "outsourced coders" had anything to do with the 737 Max's fatal problems.

Nope, despite numerous attempts to pin the blame on the backwards foreigners all the evidence points to the s******ds in question being the best lily-White American-know-how engineers and managers money could buy employed at the top levels of Boeing.

Not necessarily. The code written may well have exactly implemented the algorithm(s) that the clowns supervised by monkeys specified. It isn't the job of programmers to double check the workings of the people who do the detailed calculations of aerodynamic force vectors and torques.

It is not the programmers fault if the systems engineering, failure analysis and aerodynamics calculations are incorrect in some way!

They knew that the whole design was a rats nest intended to make the

I have never been in the position of coding software that would actually kill people but I have been put in the position by aggressive salesmen where meeting a customers specification would require the repeal of one or more laws of physics. The guys who sell stuff on a wing and a prayer typically move on fast enough that after pocketing their quadratic over target sales bonus they are well out of it before the s*it hits the fan.

They get a specification which in the strictest terms possible specifies what it must do in all cases. Aerospace you would expect every possible path to be fully tested including the seldom travelled worst case error recovery ones. Boeing used to be fantastically good at this!

Snag is if someone changes the maximum allowed limits from a fairly reasonable 0.6 degree to a larger 2.5 degrees then all bets are off. The code would have been fine with the original 0.6 degree adjustment limit told to the FAA and other international flight safety organisations.

I expect everybody here has seen that.

Useful phrases include "that's great; how did you solve the Byzantine general's problem?", and similar.

Yup, seen that too, and not just w.r.t. software!

Trying to change the culture so they don't get their bonus until after customer acceptance (or even engineering sign off) is an exercise in futility.

Related point: all sales forecasts climb rapidly after 2 years. No need to guess why.

Martin Brown wrote in news:qvfj7v$fl6$ snipped-for-privacy@gioia.aioe.org:

"the programmers" at those levels likely DO have to do some of the calculations in the crafting of their code.

S*it C coders and "Aerodynamic Engineers with coding acumen" are two different things.

That's a bit facile, I think. Folks who take an interest in their professions aren't that easy to confine that way.

Back in my one foray into big-system design, we design engineers were always getting in the systems guys' faces about various pieces of stupidity in the specs. It was all pretty good-natured, and we wound up with the pain and suffering distributed about equally.

Cheers

Phil Hobbs

Phil Hobbs wrote in news: snipped-for-privacy@electrooptical.net:

That is how men get work done... even 'the programmers'. Very well said, there.

That is like the old dig on 'the hourly help'.

Some programmers are very smart. Others not so much.

I guess choosing to go into it is not such a smart move so they take a hit from the start. :-)

If that is how men get work done then they are not using software and syste m engineering techniques developed in the last 15-20 years and their result s are *still* subject to the same types of errors. I do research and teach in this area. A number of studies, and one in particular, cites up to 70% of software faults are introduced on the LHS of the 'V' development model (Other software design lifecycle models have similar fault percentages.) A major issue is that most of these errors are observed at integration time (software+software, software+hardware). The cost of defect removal along t he RHS of the 'V' development model is anywhere from 50-200X of the removal cost along the LHS of the 'V'. (no wonder why systems cost so much) The talk about errors in this thread are very high level and most ppl have the mindset that they are thinking about errors at the unit test level. The re are numerous techniques developed to identify and fix fault types thorug hout the entire development lifecycle but regrettably a lot of they are no t employed. Actually a large percentage of the errors are discovered and f ixed at that level. Errors of the type: units mismatch, variable type mism atch, and a slew of concurrency issues aren't discovered till integration t ime. Usually, at that point, there is a 'rush' to get the system fielded. The horror stories and lessons learned are well documented. IDK what exactly happened (yet) with the Boeing MAX development. I do have info from some sources that cannot be disclosed at this point. From what I' ve read, there were major mistakes made from inception through implementati on and integration. My personal view, is that one should almost never (nev er?) place the task on software to correct an inherently unstable airframe design - it is putting a bandaid on the source of the problem. Another majo r issue is the hazard analysis and fault tolerance approach was not done a t the system (the redundancy approach was pitiful, as well as the *logic* u sed in implementing it as well as conceptual. I do think that the better software engineers do have a more holistic view of the system (hardware knowledge + system operational knowledge) which wil l allow them to ask questions when things don't 'seem right.' OTHO, the so ftware engineers should not go making assumptions about things and coding t o those assumptions. (It happens more than you think) It is the job of the software architect to ensure that any development assumptions are captured and specified in the software architecture. In studies I have looked at, the percentage of requirements errors is somew here between 30-40% of the overall number of faults during the design lifec ycle, and the 'industry standard' approach approach to dealing with this pr oblem is woefully indequate despite techniques to detect and remove the err ors. A LOT Of time is spent doing software requirements tracing as opposed to doing verification of requirements. People argue that one cannot verif y the requirements until the system has been built - which is complete BS b ut industry is very slow to change. We have shown that using software archi tecture modeling addresses a large percentage of system level problems earl y in the design life cycle. We are trying to convince industry. Until ch ange happens, the parade of failures like the MAX will continue.

Nice rant. Could you tell us more about the 'V' model?

What sorts of techniques to you use to find problems in the specifications?

Yup. Leaving too much stuff for the system integration step is a very very well-known way to fail.

It's commonly done, though, isn't it? I remember reading Ben Rich's book on the Skunk Works, where he says that the F-117's very squirrelly handling characteristics were fixed up in software to make it a beautiful plane to fly. That was about 1980.

In real life, though, it's super important to have two-way communications during development, no? My large-system experience was all hardware (the first civilian satellite DBS system, 1981-83), so things were quite a bit simpler than in a large software-intensive system. I'd expect the need for bottom-up communication to be greater now rather than less.

I'd love to hear more about that.

Cheers

Phil Hobbs

Wow! That sound like quite a box. Four inputs? What's the dead time on a channel? More or less than $10k?

George H.

I guess he's referring to this one:

We use it at work, or actually used to use it. Now we are transitioning to agile methods, since V model is really rigid and respons poorly to changes during development. In particular SW can benefit a lot from agile mindset, and making automatic test that has high test coverage

Cheers

Klaus

tem engineering techniques developed in the last 15-20 years and their resu lts are *still* subject to the same types of errors. I do research and tea ch in this area. A number of studies, and one in particular, cites up to 7

That reminds me of a fact of designing FPGAs that surprised me when I reali zed it. We go to great lengths to assure the proper design of the code tha t goes into logic devices. But an equally important part is the timing of the logic paths. We have constraints that we use to specify the timing req uirements which are then used to test the speed of the resulting logic in a nalysis. However, we don't have a way to verify that the constraints are s pecifying what we intended. So any logic design can potentially be a failu re due to improper timing constraints which can not be tested or verified t o be correct.

Go figure!

See below for pointers to John Hudak's and SEI's work in this area.

There is a number of other approaches that I don't see covered in their work too.

is one. is another.

All work on different aspects of verification, but basically they aim to express (model) the problem in different ways to allow it to be inspected and tested with hypothesized situations to find anomalies.

FBM looks for static anomalies (a model which allows any situation that makes no sense). TLA looks for behavioural anomalies (sequence of actions which could violate a system constraint). AADL looks for performance/real-time anomalies.

The biggest difficulty with bottom-up communication is that the folk "at the bottom" work with highly technical or formal artefacts, and feel the need to communicate in the same way - but the folk who need to understand what is being said simply don't understand what is being said, and being frequently more senior, don't want to admit their lack of understanding.

There is a deep gulf between requirements specification and implementation. Folk in implementation use their formal methods training to spot logical errors in the specifications, and assume that the reason is that the requirements folk simply don't know what they want. Sometimes they're right, but more often, they simply don't have a sufficiently precise language to express it.

The gulf can be crossed - but only by formal languages that can be expressed in understandable ways.

Building tools to cross this languagelogic gulf using so-called "fact-based modeling" has been the focus of my last 12 years of research.

The Software Engineering Institute at CMU (where John Hudak works) is one of the foremost (but by no means the only) eminent body working in this space - nor is their approach the only one that has made significant inroads into this class of problem.

Clifford Heath