IP Management And Development At 5/3nm

The growing complexity of moving to new process nodes is making it much more difficult to create, manage and re-use IP.

There are more rules, more data to manage, and more potential interactions as density increases, both in planar implementations and in advanced packaging. And the problems only get worse as designs move to 5nm and 3nm, and as more heterogeneous components such as accelerators and different connectivity protocols are added into increasingly customized chip architectures.

“Having multiple versions of IP to get around this can help eliminate the issue, but it exacerbates the challenge of how to manage them all,” said John Ferguson, director of marketing for Calibre DRC applications at Mentor, a Siemens Business. “When we add waiving to the equation, it can become more complicated. Each version of IP needs to be associated with the correct corresponding version of waivers.”

In a complex design with hundreds of IP blocks, fixed power budgets, thinner dielectrics and more susceptibility to noise and other physical effects, this can quickly spin out of control even for derivative chips. Moving an optimized design to a new process node means that the design functionality remains mostly unchanged while the PDK and the cell libraries are getting developed by the vendor. In many cases, the only solution is to develop test chips and find out where problems might occur.

“This is typically a symbiotic relationship where the design house and the vendor are working in collaboration,” explained Amit Varde, director of product management at ClioSoft. “To bring synergy and shorten the design cycle, PDK and/or library vendors often provide series of planned releases. It is typical for a design house to re-target multiple designs on a test chip to get the most out of the optimization exercise.”

From there the design team evaluates incorporates vendor releases of PDKs and libraries in their evaluation of the new process node’s performance for the design. “Managing the releases from the PDKs and/or library from vendors, and using them as read-only references, is necessary to make sure the design teams do not accidentally modify vendor data,” Varde said. “Effective use of branching methodologies can enable the design teams to use different variations of the libraries to determine the best options in the new process node. Most importantly, a design management system provides an accurate report of which designs on the test chip used what variations of libraries.”

But Ferguson noted that this isn’t like designs of even a couple years ago. “Previously, you could feel confident that if an IP block was DRC-clean standalone, it would still pass when placed into the context of a larger design. Today that is much more difficult. Density and antenna rules were always a bit tricky in this respect, but now there are multi-patterning requirements. It may be possible to partition a block into two separate layers on its own, but if placed next to other design components, they may force a coloring sequence that does not fit for the particular block.”

The ever-growing complexity of rules requiring connectivity adds another twist to this process. “Consider those voltage-dependent spacing rules,” he said. “Historically, designers took advantage of IP blocks for use in scenarios other than the original intention. Now, if the IP pins are all connected to voltage domains as initially expected, there should be no issue. But if they are connected to some unexpected voltage, you are likely to get new spacing violations.”

Thinking differently about IP
One of the key challenges in complex designs today is the number of variables that are constantly changing — process technology, algorithms, communications protocols, and rules around many use cases, among other things.

Within this context, IP is playing an increasingly important role, and so are the rules for how to keep that IP current with all of the other changes.

“The question should be how to manage IP development in light of PDK refreshes and deployment of half nodes be either of these two challenges will impact IP development, IP refresh and ultimately IP management,” said Tom Wong, director of marketing, design IP at Cadence, noting that node-to-node transitions are accelerating, particularly as nodelets are added into the mix. “The node-to-node transition is getting faster and faster. Going from 40nm to 28nm used to be an 18-month to 2-year cycle. Now we are seeing the transition from 16nm to 12nm in a little over a year from 16nm deployment. The migration from 7nm seems to be even shorter, so we need to understand this phenomenon before we can address IP management issues.”

In the 40nm era, a PDK was not obtained from the foundry until process development was complete and a stable SPICE model was available. As a result, there were fewer PDK refreshes because the SPICE model matched the silicon. There was little work in IP management, and once developed, the IP was good for a few years. There was no need for new SPICE models, design rules, or library timing were needed.

At 7nm and below, this has changed significantly. Foundries want to work with IP providers starting as early as version 0.1 of a new process.

“They’re willing to release early versions of PDKs and design rules and early timing models for libraries and I/Os, not to mention memory bit cells,” Wong said. “Those timing and SPICE models are aspirational, at best. They are design specs. Once the foundry gets the process developed, runs some test chips, factors in the process learning and refines the process to make it production-worthy, they will then release updated PDKs, SPICE models and libraries. The process can turn out to be faster or slower, or the design target may be too aggressive, impacting silicon yield. What to do then? Well, make an updated PDK and SPICE model to reflect the reality, and tell all upstream customers who designed using the earlier version to do a refresh. Or add design rules to constrain the designs to get better silicon yield. These are all valid points, but we don’t call this the bleeding edge for no reason.”

The bleeding edge isn’t just about process nodes, though. It also includes new technologies, such as automotive sensors and AI, and the IP for those types of chips needs to adapt to constantly changing specs for safety-critical electronics and new security rules.

“Some of these devices are always on, but even within them not everything may be on all the time,” said Gordon Cooper, product marketing manager for embedded vision products at Synopsys. “Think about a convolutional neural network (CNN), for example. In ultra-low-power applications, the embedded vision engine may not be on. And it may run deep neural network acceleration with all vision off.”

Fig. 1: Vision processor’s varied usage. Source: Synopsys

As of today, much of the IP being developed is soft IP. In theory, that should make it process-node agnostic. But the use cases for IP can change significantly, which puts more emphasis on how the IP is architected.

“If you look at a CNN, that only sees what’s in front of it,” said Cooper. “A deep neural network will support CNNs and batched large-scale deep neural networks (LSDNNs) and recurrent neural networks (RNNs). But RNNs save a lot of data over time, so if you group the RNNs and LSDNNs together, you can take advantage of batch.”

To make things even more complicated, as the market begins to adopt a chiplet approach, along with more flavors of advanced packaging, all of this will have to be characterized across a wide variety of criteria, from applications to use cases.

Half nodes and nodelets add another dimension to this problem. Samsung and TSMC have announced nodes or nodelets at every digit from 12nm down to 4nm. Here, the process and design rules do not change much, but there are new libraries available with fewer tracks.

“If you have a digital design that was designed in 9T, and you believe that you can gain an area and power advantage by using the new 7.5T library, then you may consider a refresh of the IP (or the SoC) by utilizing the new 7.5T libraries,” Wong said. “However, this is a costly endeavor as it amounts to a re-design. From a design perspective, you must weigh the tradeoffs to determine if such a redesign is warranted. What is the area of the IP relative to the SoC? How much area and power will you save in a redesign of the IP? Is it really worth doing? Luckily, most advanced protocols are operating at such high speeds that you may not get the performance you need in a 7.5T library and your trusty 9T design will be fine, so the half-node process improvement will have no impact on your IP design.”

Similarly, a shift in SPICE performance may or may not need a re-design. “If the original design has sufficient design margin, then a shift in SPICE model may not impact the design at all. Then a simple re-characterization of the IP is all that’s needed. On the other hand, if your original design does not have sufficient margin, then the change in SPICE timing makes your IP not meet target specs. Then you have a problem. You can either re-spec the IP to accommodate the degradation in performance/margin, or do a complete re-design. Depending on the type of IP and performance band, it is possible that you can get away with it. Ultimately, these are considerations that a SoC designer needs to understand and factor in at the beginning of a SoC design. You must try to anticipate all the conditions and plan accordingly. There is no substitute for experienced designers,” Wong said.

Best practices
Still, Mentor’s Ferguson stressed there are some specific best practices to keep in mind at the implementation level. “For multi-patterning, some designers will pre-color the IP blocks to help ensure that when they are placed, they will work properly. Some even go so far as to have multiple options of coloring for the same IP to try to enable options in placement. When that is not possible, the best approach is to give sufficient space between neighboring blocks or IP. Users also should choose a consistent coloring scheme for things like power and ground that cross multiple IPs to avoid issues.”

Another tip is to avoid running all of these complex rules early in the design process. “When the design is likely very dirty, these rules will run slowly and produce thousands of errors,” Ferguson said. “Because these are heavily context-dependent, the location of the errors do not likely point to the root cause of the problem. Instead users are encouraged to run a subset of the rules, focusing on checks with a local scope. These will run fast, scale very well, and generate results that are more likely to pinpoint systematic problems. Once cleaned up, the issues that plague the context specific rules will be greatly diminished, thus reducing the entire iteration cycle time dramatically.”

Another common approach is to do more checking in parallel while top-level routing, block design, and IP incorporation are all still in active stages. For example, it is possible to greatly reduce the detailed checking of blocks or IP to focus only on the top-level routing results. By ensuring the individual pieces are clean before doing the full checking, significant time is eliminated with common design issues that are often hard to locate and/or fix.

Waiving of known violations is similarly important, which can include waiving known errors in an IP block that are expected to be fixed later, are expected to be fixed in context, or are not expected to be fixed and will be waived by the designer at tape-out to the foundry.

Gray boxes
In some cases, third-party IP providers do not provide the full layout to designers. This really can make things challenging. In the case where the block was standalone clean, but may have a problem when placed into context, how is that identified if the geometries are not visible to the PV tool suite?

This only adds to the complexity of moving to a new process node. “There are a whole bunch of factors that play into this,” said Dean Drako, CEO of IC Manage. “If you’re going to do a whole new fresh design at a new node, that’s one thing. If you’re going to port a design to a new node — shrink it and make it better, faster, stronger — that’s a different thing. But it all ties back to proper design management (DM) practices. What are the best practices for doing DM? If I do my DM properly, then it’s as easy as conceivably possible to move a design to the new node. Design reuse practices must be considered at the same time, which might be reuse in the same node, in a different node, in another node but a different vendor, or another chip in the same node or a different node.”

Best practices for design reuse, as well as design management in general, are what help the move to a new node be as efficient as possible.

The first step in design reuse is to make sure the IP is partitioned into good functional blocks. “It’s kind of obvious, but you’d be amazed at how many people mess it up,” Drako said. “Also, it’s important to have a standard methodology of where you have your designers put and organize their files. Suppose I have a block IP, and suppose it’s a CPU or a cache. It’s going to have the HDL, the SPI, the LIB, the LEF-DEF, the SPF, the GDS, that are describing and are part of that block. If every engineer names them differently, puts them in the directory differently, that makes it much harder for to do the scripts and tools necessary to move it to the next process node, or for one engineer to take it over from another engineer.”

Another issue that often comes up is that some teams put some of their IP in the repository, and other IP they don’t. “They might get some external IP from a third-party vendor and say, ‘We’re not changing that so we don’t need to version track it.’ But they very quickly learn that when moving to a new process node, they need a different version of a module, and have to figure out how to get that into the design, and because they don’t have versions on it so they end up with a mess. For this reason, one of the rules that we have is make sure that all of your IP, both internal and external, is put into the repository and tracked,” he explained.

While it does come down to a lot of common sense, and it’s obvious after the fact, when the design time is under tremendous time pressure, it isn’t so obvious. “For this reason,” Drako said, “we’re strong believers in tying the IP repository to the bug tracking system so that if you have a bug, you know which version of which block that bug is tied to. And when you fix the bug, you know what version of which block fixed that bug, so you have dependency tracking as well.”

Here, an assembly concept can be used to capture IP dependencies. “Similar to a bill of materials (BOM), you have all of your IP blocks, and then you have a BOM that says these are all of the things that are going to go into the chip, and here’s the version of each of those things that is going into that chip which is extremely important such that, ‘Version 1.0 of this block, Version 27.8 of this block, Version 33B of this block — that’s the thing that I want.’ But that assembly/BOM process is a little hard for some people to get their heads around, and to coordinate because it’s slightly foreign. They’re used to being able to say, ‘Let’s put in a link. We’ll point at this one. Just pull that in.’ But if you’re good about it, you can be very organized, know exactly what you’re getting, and then when you tape out your chip, the next version of that block, you may have to modify that block for the next process node but you have all the history associated with the old process node, you’re making the block better, and then in the new process node, you reference the new block. But the old release, which is still working on the old block, references the old release, and that’s all okay. It’s all clear and clean,” he said.

Another problem that is common is cloning or copying IP for a derivative chip.

“The problem is that I’ve made a change in A+ and nobody in Chip A knows that that change has been made,” Drako said. “Now I’ve got a duplicate and two copies of everything in my repository, and I’ve forked everything. This means if a designer goes and changes Chip A, I don’t know. If somebody changes Chip A+, the engineer on Chip A doesn’t know. All this stuff gets messed up, and the only way it gets fixed is basically the engineers talk to each other on each block, and that doesn’t work when there are hundreds of engineers. What you want to do is instead branch. In the DM system, the branch basically only changes the copies of the files that you changed, and it does it automatically. You say ‘I’m going to branch my Design A to create Design A+ and it gives you a working directory and all the files you need but the version control system (the DM system), is basically keeping track that all the files are the same as A. Then, when you change a file, out of the 10 million files that are in there, it keeps track that only these 7 files have been changed, and those are the old ones so you can see the changes between A and A+. That gives you the ability to A) not duplicate all your data; B) not make mistakes and have to fix them twice; and C) get your design on the new process node faster.”

Conclusion
Keeping track of IP, what can be re-used, how it has changed from previous implementations, and how well it plays with new process technology and other components is becoming much more difficult. And it gets even more difficult with designs that are customized for specific markets or use cases, such as automotive or 5G chips, where end technologies are still evolving and the rules are constantly changing, or with AI chips where the algorithms are in a state of almost constant flux.

IP can still be a big time-saver in many designs, but managing that IP is becoming much more difficult and complex, and the days of keeping track of it on a spreadsheet are long gone. It now requires specialized tools, strong methodology, and much deeper understanding of the physical and electrical characteristics of that IP in real-world applications.