This Month in Design007 Magazine: What Did You Expect From Me, Anyway?

Estimated reading time: 2 minutes

As engineers, we work in the middle of a (usually long) process chain. Product requirements come from the front of the chain (marketing), the products we create are physically realized at the back of the chain (“production”), and hopefully get sold to customers who enjoy them and buy more.

It’s sort of like working on an intellectual assembly line—we get requirements and data as input, perform our particular task, and then provide our output as requirements and data to the next person on down the line. It seems easy enough. So, why is it that so many of the requirements we’re supposed to meet and so much of the data we receive is downright bad?

To be fair, “hard data” is usually okay. Component dimensions, material properties, pinout definitions, etc., all tend to be correct because, without that, reliable manufacturing would be impossible. It’s the soft stuff that tends to be the problem. In the case of signal integrity, it’s the simulation models we receive from vendors or clear guidelines on just what is and isn’t achievable from a board layout standpoint or manufacturing cost standpoint that make the analysis job difficult. Sorting through problems with data requires time that no one seems to have—at least, in the world as it existed three months ago—and any delay associated with vetting and reacquiring data presents a huge problem.

Example Issues
Why does this happen? While not an exhaustive list by any means, these are some of the issues I’ve seen.

Poor Definition of Requirements
Simulation models are a great example— even though the syntax for simulation models is well defined, there’s really no good way to assess simulation model quality or fitness for a particular analysis. In my hardware design days, I noted that just about every analysis project had some simulation models show up past the period we had reserved to test them, so we just gave them a quick test and got to work instead. Without fail, we’d use the models for a week or so before problems popped up and realized our analysis had been compromised. It was a 2–3 week hit, every time.

Sometimes the list of items to be delivered just isn’t complete or clear enough, and only part of the information needed is provided. The time it takes to go back to the source and acquire the additional data (and justify why they should take the time to provide it) causes project downtime.

To read this entire feature, which appeared in the May 2020 issue of Design007 Magazine, click here.