Leveraging Design Team Energy!

Once upon a time, in 1987 to be specific, a French design team was trying to develop a 100% Made in France supercomputer. In fact, not really 100%, as the CPU chips were supposed to be made by Weitek, but we never saw any of these chips, probably too challenging to be designed right first time! Anyway, I was in charge of the design of the functions which could be used by every other design teams – 4 or 5 ASIC had to be designed, using up to date design tools from VLSI Technology, as Synopsys Design Compiler was a bit too young at that time! Thus, I was in charge of:

• Clock Distribution Arborescence (CDM did not exist, at that time) in the core
• Clock distribution block for I/O reception
• Clock distribution block for I/O emission (pretty complex function, asserted to the specific PVT of the emitting IC, eventually delayed to guarantee the Data Hold Time)
• Master JTAG Cell
• I/O JTAG Cell

Nobody had ever proposed the concept of IP Reuse at that time, but every engineer involved in this supercomputer project was convinced that it was a good idea, so the design team in charge of the various ASIC designs could focus on the specific IC functionality. Twenty seven years later, the industry has put a name on this intuitively good idea and call it “IP Reuse”, moreover, a new tool family has emerged: IP Management tools, or Hardware Configuration Management, as described by Daniel Payne in this blog.

Why using IP Management tool? The goals are multiple. The first goal is to guarantee the IP consistency across various design teams. We need to make sure that the Shanghai based team, designing the AUX Core interfacing with the ADSL2-IAD designed in San Jose, is using the same IP version than in San Jose. This is the same problem today that it was in 1987 in this supercomputer project: as soon as more than one design team is involved in the same project, you don’t want to duplicate design resource, and you want to make sure that exactly the same IP is used. Design productivity and IP consistency are the key words. This is the basic concept, but we think this concept should be extended. RTL IP has traditionally been defined as a design for which only RTL and simulation is available (soft IP), or a design, which has gone through synthesis and some placement information is available (firm IP) or has been taped out (Hard IP). But to improve design productivity it is important to broaden the scope of what has been traditionally defined as an IP. It can be extended to scripts developed to stitch the IO fabric together, regression scripts or verification test benches. Leveraging tested scripts and existing test benches help provide a jumpstart to design teams.

This means that EDA vendors should go beyond simple IP Management tool, and extends the definition of the IP being managed by the tool into a more complex “object” made of:

• RTL IP
• + Verification Test Benches
• + Regression scripts
• + Placement information
• + Routing information (when the same technology node is targeted).

Since 1987, the chip maker company behavior has completely changed. Only very few companies decide to develop an ASIC once every two or three years, and in this case, they tend to pass through an ASIC company like eSilicon, OpenSilicon, etc. On the other hand, a large ecosystem of Fabless, Foundries and IP vendors has established. Then, we may think that a Fabless (or IDM) tend to develop as many ASIC as possible, around platform IC, to target many market segment… and amortize R&D cost. For these companies, better harness the energy of the designers, and reuse IP’s wherever possible, is just a way to improve economics.

Adopting such a behavior will first require the right EDA tools, from ClioSoft for example, and also to push for mind change inside the company design community. At the IP source, the design team may have to provide extra effort to make the design reusable, at the IP sink, the well-known NIH syndrome will have to be thwarted. But this will be a low extra cost, compared with the benefit of harnessing the energy of the designers.

From Eric Esteve from IPNEST

Also Read

Webinar: Making Design Reuse Work

Importance of Data Management in SoC Verification

The CAD Team – Unsung heroes in a successful tapeout