DAC 2012: Avoid IP getting lost in translation
Do you know where the IP for your design has been? Or where it’s going? That’s the question a lot of CAD groups at chipmakers have been asking themselves as they struggle with a combination of regulatory, bug-fixing and yield issues.
IP reuse has helped keep productivity on track but it’s leading to problems of data management. In a Monday DAC panel organized by IC Manage, customers from AMD, Broadcom, and nVidia as well as Gary Smith, chief analyst at Gary Smith EDA, described the problems they face with huge, distributed design databases hosted around the world.
Smith said, based on recent surveys of users said: “Network storage bottlenecks are now a big issue although the EDA tool vendors don’t like to talk about the slowdown.”
One survey pointed to 30 per cent of project time being spent waiting for the network to respond. Other problems are less obvious but carry big penalties way beyond a delayed chip.
“One big challenge is dealing with US export controls,” said Vincent Ross, CAD architect at AMD.
Most big chipmakers have design teams dotted around the world but export regulations such as ITAR mean there are sensitive pieces of IP they can never see – making sure the remote offices cannot see them is a big challenge without an automated design-management system in place.
The problem for CAD managers bringing in design management is getting the design teams to use the tools and not simply store bits of circuitry and RTL on their own hard disks because they don’t want to go through the rigmarole of checking stuff out and back in again.
“Analog designers are not familiar with code control tools and version branching,” Rael said. So design-management tools have to avoid being burdensome to the engineer, or they will try to avoid using the tools.
“We have a simple rule: keep every block self-contained in a library. You can check in changes as collections. They used to have to check out lots of cells individually to make a change. Now they can check in with one shot. And, if there was a problem with that version, it can be rolled back in one hit,” explained Jacob Rael, director of IC design at Broadcom.
Doug Quist, director of engineering at nVidia, said design management needs buy in at the highest level to make sure design teams understand they need to use the tools. He said nVidia has the policy “if it isn’t checked in, it doesn’t exist”.
Another policy echoed by the other panelists is that of using a branching strategy for reused IP “so bugs can be fixed once and then applied to everything,” Ross said.
Without branching enforced by a version-control system, it is just too easy for a block to be copied and, in effect, vanish into the system. If a bugfix turns up for the parent block, the only way to apply it to the copied block is to apply it manually – assuming that the engineer who copied it realizes a change was made, which is unlikely in the middle of a busy project.
“You want to be confident in what you are taping out and be able to alert chip leads of errors in IP,” Rael said. “We need to identify where the blocks are being used. Very often with analog blocks, they look fine in simulation and in production. Then, you hit a certain process corner and they all fall out.”
Without branching, intensive searches have to be carried out across designs to find out where IP went, Rael added: “You do a lot of XORing to find out what LNA [low-noise amplifier] you put on. What you want is to be able to build a chip with a bill of materials so that it’s clear what is in the tape-out.
If you don’t have a clear idea of where the failing IP block is being used in other chips to avoid this process corner killing yield in future, a lot of engineering ends up being wasted in the search.
“Branching allows us to figure out where the blocks are being used,” said Rael.
Shiv Sikand, vice president of engineering at IC Manage, said: “You want bug-dependency tracking to be computed, not something where you have to go through an Excel spreadsheet.”
Sikand said that the move away from monolithic chip design to one based on platforms and IP demands a chip-assembly methodology. “You really want to use a top-down approach,” he claimed.
Ross said the ability to manage design waivers in a consistent way is vital. “There are occasions when you want to be able allow waivers following management review and allow documented management tradeoffs as the tape-out cut-off date approaches.”
Rael said ESD protection on pads for RF devices are one area where consistent waiver control is essential. “The ESD protection can kill RF performance,” he said. But if a waiver is issued to allow certain pads to not use the ESD circuitry and the chip later suffers from failures in the field, having the documentation of the decision process used to assign that waiver readily available avoids a lot of unnecessary finger-pointing.
Pingback: DAC 2012 Notebook | Tech Design Forums