Why Open and Supported Interfaces Matter

Back in the early 1980’s during the nascent years of electronic design automation (EDA), I worked at Texas Instruments supporting what would become their merchant ASIC business. Back then, life was a bit different. The challenge we faced was to make our ASIC library available on as many EDA flows as we could to give as many users as possible a path to our silicon. CAD flows then tended to be one-vendor flows but even so I was all to keenly aware of the need for open and supported interfaces. What good was an EDA tool flow if my customers had no easy way to hand-off a design to our fab? In those days, we literally hand-crafted each interface. I still remember my first programming assignment at TI was to get a Daisy Logician system to talk to a TI 990 mini-computer through a RS232 serial port. Ouch… My second program was to write the Daisy netlister as there were no standards for such things back then.

Fast forward to the present, and the need for open and supported interfaces has not diminished in the least. We made significant progress in three decades with all kinds of data formats for designs, libraries, constraints, floorplanning, test vectors, packaging etc. You would think by now that interfaces would be a solved problem and not much of a concern any more. Well if you are thinking that way, think again.

As time has moved forward, we have indeed solved many different interface issues, however the size and complexity of our designs have rushed ahead at a pace far exceeding what we imagined when we invented those interfaces and many of them are now showing their age.

The funny thing about standards, whether they be defacto or otherwise, is that by their very nature they imply stability. Yet, stability is problematic in an industry that literally reinvents itself about every 18 to 24 months with the complexity of its designs rising exponentially at every evolutionary step. Take GDSII for example. It has been the staple format for design hand-off to the fab for the last thirty years. Ten or so years ago it was already struggling to keep up and the industry created a new format called OASIS to take its place. Yet here we are a decade later and the very stake in the ground that made GDSII so stable and useful is what has been holding the industry back from widely adopting OASIS.

Over the last three decades we’ve had the COT revolution that delaminated the entire supply chain, an explosion of EDA companies that eventually got acquired and merged into the big three, the fighting over Joe Costello’s proverbial dog food bowl with all-in-one flows and now, another resurgence of smaller EDA companies again providing solutions for the new challenges that come with each new process node. We are in a continual cycle of reinventing the industry and all the while, at each step, designers are scrambling to use the best tools available for the job at hand.

So, what’s the key to survival?

The first is to recognize that one size does not fit all. I’ve proven this repeatedly in my 30+ years in EDA. All I need do is to look in my closet and see three different sizes of clothes that I’ve managed to grow out of and into and realize that design teams and companies do much the same thing. A startup’s needs are vastly different than the needs of an Intel or Qualcomm and we should not assume that the same set of EDA tools and flows will work equally well for both. The acquisition of Tanner by Mentor seems to be a good indication that at least one of the big three have recognized that times are again changing.

The second thing is that no matter what the size of your company or what silicon platform you are using, having a well thought-out and controlled design process that fits your problem is essential. As one of my old bosses at TI used to say, “you can’t improve something unless you can measure it and control it first”. And, don’t assume that you existing tool flow must do everything the way it used to. Or perhaps a better way to think of it is to use the right tool for the right job. A good example of this is the merging of design blocks into a large SoC. Our first inclination is to merge all the blocks into the place and route (P&R) tool, finish up the connections and then stream out the GDSII (or now OASIS). However, this is not necessarily a core strength of P&R. Instead perhaps a better way might be to truly do hierarchical design and use another tool to merge the layouts for the final repair and stream-out process. I’m not advocating one flow over another here, I just saying you need to be open to re-engineering your flow every so often just like the fabs re-tool to handle the next process node.

Lastly, since we do re-engineer ourselves every couple of years it’s time as an industry to truly embrace open and supported interfaces as a necessity of life. They are not a luxury, nor are they something that should be taken for granted. At best, life if miserable without them and at worst the lack of good interfaces can literally mean the lack of a design flow needed to get your job done.

The Calibre team at Mentor seem to get this point. Mentor does an exemplary job of maintaining links to the rest of the EDA tool ecosystem. I can tell you this does not come for free. It takes time, vision, foresight and willingness to keep all these interfaces updated and working properly. Mentor should be applauded for understanding the importance of this work as it normally isn’t readily associated with driving product revenue for the company.

Translated, this all boils down to the industry financially valuing good, clean, open and reliable interfaces. After all, financially rewarding vendors who do a good job of creating and supporting open interfaces is one way of protecting the valuable investment you’ve made in their tools.

See also:
Mentor Calibre Interfaces