Issue link: https://iconnect007.uberflip.com/i/994883
14 DESIGN007 MAGAZINE I JUNE 2018 The third challenge is optimizing product reliability. I'm designing this system and I've worked across the teams efficiently, but I still may not be catching all the errors, and as I build larger and larger systems the chances of designing in errors increases, and so the need for technology to validate designs through- out the process increases. Validation starts with the connectivity between the multiple boards—simple things like connector pin mis- matches can cost millions to identify and rede- sign. It also includes system-level schematic checking and system-level modeling for signal and power integrity, thermal and mechatronic behavior. The last challenge is leveraging the IP gener- ated during the design process across the orga- nization, and that partly gets into that digital thread of data passing throughout the flow, but it also says, "Hey, look. If I design a piece of circuitry, I want others to be able to reuse it." At the single board level, I've seen upwards of 80% of a design reused from one generation of a product to the next. You want to enable that efficiently, but that's not multi-board design. When it comes to multi-board, people are reus- ing entire boards. Shaughnessy: Well, it sounds like there's a lot going on at the very front end. Wiens: Yes. It's at the front end and it's also really throughout the whole process because, again, you want to enable that guy at the front end to make smart decisions, but you also want to enable progressive refinement with optimization. As the thing goes through and you realize, "Hey, this either won't work or it won't work as well as it could have. Hey, what changes can we make? Can we put this set of functionalities onto this board? You know, onto board A instead of board B?" Can we, in some cases, say, "I want a really, really fast connec- tion; can I have a fiberoptic cable connection between these two boards instead of going through a whole bunch of physical connectors across back planes and things like that?" Those are the kinds of decisions that some- body is going to sit there and try to think through, once they start seeing the physical incarnation of the board being built. Shaughnessy: Speaking of the front end, I've heard of designers who want the schematic to represent multiple boards. Is a multi-board schematic that different? Wiens: It certainly is. We certainly have had cus- tomers who started there. Most modern EDA tools have a hierarchical schematic system. That just means you have high-level blocks, you design at a high level, and then you start to poke into a block and you can see more data, and you can progressively go down multiple levels of that. Engineers naturally said, "Well, okay. So if at the top level today my high-level schematic is just one board, well, what if I go one level above that? Now, I'm looking at mul- tiple boards." That is possible, but it gets back to the complexity of managing all that data, managing the connections, and really at that level the schematic tool is really a documenta- tion tool, not an architecture optimization tool, if you know what I mean. In addition, system engineers don't normally know or really use schematic capture tools. They use higher-level abstraction tools, like Visio, which is basically just a hopped-up ver- sion of PowerPoint drawing tools. I'm under- selling it, but you know what I mean if you've ever used Visio. But of course, they want that high-level abstraction to transfer directly to "Hey, look. If I design a piece of circuitry, I want others to be able to reuse it." At the single board level, I've seen upwards of 80% of a design reused from one generation of a product to the next.