Issue link: https://iconnect007.uberflip.com/i/679419
May 2016 • The PCB Design Magazine 55 DOWNSTREAM: WHAT A LONG EDA TRIP IT'S BEEN you can't read or write to, to a neutral intelli- gent format where you can. Intelligent design formats such as the IPC-2581 can drive a com- pany's internal and external processes, and the user has control over how much content they chose to include. Now they can send off a single file to out- side or captive manufacturing companies rath- er than having a bunch of disjointed files that have been produced from a proprietary format which aren't connected and which are difficult to be kept in-sync over the life of the product. Another benefit of an industry standard design exchange format which often does not get mentioned is it enable new ideas, and gives companies choices for their EDA tools. It has been formats like IPC2581 that have enabled companies like DownStream Technologies to create and develop new ideas such as BluePrint to automate the documentation phase. Shaughnessy: It's funny; most of the gains that we've seen lately have been in bridge tools from one tool to another, because that's where the problems are. Clark: It is where the problems are. The mar- ket, which we all have to pay attention to, is clearly saying "We want to do a better job of transitioning from that virtual space of design to the manufacturing space, whether it's a cap- tive or an external contractor, which means we need to know more about the manufacturing process." These intelligent design formats like IPC- 2581 are enablers for that. We have the ability to take this intelligent format into our tools and then drive forward the downstream processes. These new ideas are good for the industry. Companies with new ideas can actually par- ticipate, rather than in the past where we were circling the wagons and nobody could read or write the proprietary formats. The market doesn't want that any more. They want to be able to choose the tools that best fit their par- ticular needs. Shaughnessy: Do you think IPC-2581 is the way forward? Are all your tools going to be built around 2581? Clark: Yes, we do believe it is the way forward. And yes, we're committed to it. In fact, just be- fore I met with you I was in one of the IPC com- mittee meetings working on an amendment to Rev B of the IPC-2518 spec, and then we're go- ing to begin defining what's going to come in Rev C. We need to deal with things like embed- ded components and flex. I think the biggest impact and trend that will be a game changer for all of us—upstream, downstream, wherever you are in the equation—is going to be from flex. While we're committed to the 2581, that does not mean there aren't other formats out there that the market might require us to sup- port, for example, ODB++ from Mentor and of course Gerber. Shaughnessy: Aren't 90% of all designs still Ger- ber? Clark: Yes, this is true and may stay this way. When I go to a fabricator, I certainly can make an argument for the IPC-2581 which contains just the Gerber equivalent, and it's clear that there are huge benefits to sending off the Ger- ber equivalent if all they are sending is a single file to the fabricator, but there will still be com- panies that choose to go external with actual Gerbers; however, that's their choice and we support that. As much as it would make our au- tomation easier, and our tools would fit better into everybody's processes and we could define the process, we can't force them to change; the market does that at its own pace. Our role is to listen and provide tools that support the var- ied processes that exist. At the same time we see ourselves as advocates to our customers and as such present new ideas and methodologies which we believe help our customers. Shaughnessy: You can't be too picky, right? If peo- ple are using Gerber you've got to support that. Clark: Correct, but it doesn't exclude those same companies that might want to use Ger- ber externally from internally driving their processes with IPC-2581. Now they can choose tools that best fit their needs when the primary EDA vendor is not addressing their needs, i.e.,