Issue link: https://iconnect007.uberflip.com/i/1219242
26 DESIGN007 MAGAZINE I MARCH 2020 have faced, they said, "It isn't the hard stuff, like 112 Gb/s serial links or DDR5 interfaces, that we need help with. Those are big chal- lenges, but we know to focus on those, and we solve them. It's the simple stuff that we're not focused on that often nails us." Most SI/PI experts have a collection of dif- ferent tools that they use with a unique flow they've developed themselves. Their flow is a complex series of steps that usually only they can run because it's been designed for their own use. Experts are solving demanding prob- lems, by definition, and their focus is on solv- ing those problems, not creating paths for oth- ers to follow. Add to that the fact that none of us seems to have enough SI experts in our or- ganization, and you end up with a design anal- ysis bottleneck. We all manage scarce SI resources the same way. We identify interfaces based on risk and priority, and only the toughest problems get expert attention. Thus, there's an increasingly small percentage of designs that experts look at, and everything else gets designed and ver- ified to manufacturer guidelines or industry best practices (rules of thumb). How do those interfaces get verified? You got it: good old- fashioned manual design reviews. Shaughnessy: And most design review meet- ings are slightly more enjoyable than torture. Westerhoff: That's right. Let's face it: Manu- al design review meetings are long, boring, and tedious. About 20 years ago, we asked EMI specialists at Sun Microsystems how they signed off boards for EMC, and they said, "We look at the layout layer by layer." I was amazed at the time, wondering how they kept from go- ing blind. The truth is, 20 years later, this is still what people are doing for most of their de- signs, and not just for EMC. If 10% of the design is getting expert attention, 90% of the design is just getting eyeballed. De- signers and their peers are reviewing the design and hoping for the best. Given the complexity of modern designs and how repetitive the pro- cess is, it's not surprising that stuff gets missed. We have a product called HyperLynx DRC that encodes domain-oriented design rules (SI, PI, EMC, analog, safety) and automatically checks the design to identify possible problems. Note that I said possible problems, not just prob- lems, and that's a key point. You can think of this as a "design rule scanner." It quickly iden- tifies areas for a designer to review, making a decision about whether the design is okay, definitely needs to change, or requires detailed analysis to investigate. The important points here are that checking is quick and spans do- mains and that analysis can be performed by the designers directly. Shaughnessy: Right. The designer doesn't want a tool that requires a Ph.D. to operate. Westerhoff: Absolutely, but there's a balance between simplicity and usefulness. We all want everything to be simple so that we can use it with no training and get useful infor- mation out of it. With DRC, in particular, it's definitely a case where the more you tell it, the more useful the output becomes. When I use DRC to check a design for decoupling cap placement, it needs to know what the metrics are. It needs to know which pins on ICs are power pins, how to identify decoupling caps, and what the maximum allowable distance from an IC to decoupling cap is. That's not hard, but I still have to perform a level of set- up to get useful output, and that's a mixed bag. There's a class of people who will do that without hesitation and swear by it, and there's another class of people that won't put even that level of effort in. The latter tend to say, "If Experts are solving demanding problems, by definition, and their focus is on solving those problems, not creating paths for others to follow.