Issue link: https://iconnect007.uberflip.com/i/1245291
26 DESIGN007 MAGAZINE I MAY 2020 up and realized our analysis had been compro- mised. 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. Domain Expertise and Lack of Global Focus Most of us interact with experts from oth- er domains who consult on our projects. Sig- nal integrity specialists are a good example; they will help out on a specific part of a de- sign. They're keenly focused on a few critical aspects, but may not see the larger picture or understand how their guidance affects it. For example, the signal integrity specialist may maintain that a low-loss dielectric is required to meet channel loss budgets without under- standing that the additional cost makes the de- sign untenable. Sometimes the experts we consult don't un- derstand their own process well enough. My team once contacted another signal integrity group in my company to get placement and routing rules for a custom ASIC they had ana- lyzed for their boards. They responded by ask- ing for our board's netlist—an odd request, but we provided the data anyway. Their response came back, "Your net names are wrong. You need to fix your schematic." We were baffled; we had asked for layout guidelines, after all. After digging deeper, we re- alized that the person we were dealing with only knew how to run an automated process that took a design's netlist and added layout con- straints based on a net naming convention the other group had established. The process had become so deeply ingrained within their group that they had lost sight of the bigger picture. In the end, we obtained a copy of their board data- base, reverse engineered the layout constraints, and proceeded with our own design. Lack of Attention to Detail There are lots of reasons for this—many of us are learning on the job, the people who can mentor us are usually busy, schedules are tight with too much to do, and mistakes hap- pen. Everyone is overloaded and swapping between tasks, so consistent attention to the smallest details is tough, requiring a combina- tion of persistence and downright stubborn- ness. Let's be truthful here: when the chips are down and the hour is late, there's a huge temptation to take whatever you have, pack it up and ship it, hoping that whoever using that data down the line will be able to figure out what to do with it. "Correcting S-param- eters for causality" wouldn't be such a big deal if people were fastidiously checking and correcting the data they produced in the first place. Poor Communication I think that we engineers routinely underes- timate the value of good communication skills, believing that simply stating the facts as we see them is good enough. We don't appreciate how difficult good communication actually is and don't recognize the need to confirm that others have actually heard and understood. When others don't really hear, problems can get swept under the rug until they become too large to ignore. Addressing These Issues Now, what can we do about these issues? Just articulating a set of problems with no plan for improvement isn't helpful, so here's what I try to do. You'll note that none of these are simply technical; they're more about being hu- man and technical at the same time. Define Requirements Clearly With a Way to Verify Them I try to give others a detailed list of what I expect as input with descriptions that are clear enough to act on and examples of what the data should look like. Ambiguity in require- ments is not your friend, and I try to be as ex- plicit as possible. I try to be just as thorough with the data I provide to others, making sure I have a complete list of what to provide and the format to provide it in.