Thank you. I represent a really narrow slice of design compared to the other topics. I focus mostly on analog and RF design.
Top Two Challenges you use Design Management to Address
One of the challenges is we want to reuse as much IP as we can. But within our group, that really creates a conflict. The block designer wants to constantly improve the block, while the chip lead wants to have a stable release.
And if we kind of do this in the same environment, it causes a lot of chaos. So one of the challenges is: How do we manage possibly many versions of the same block? The same block can also go into many different chips, or many different radios; we have to know which ones have bugs, which ones don’t, and which has the latest features. It gets to be really chaotic trying to keep track of all these things.
Also, because of the way we’ve been doing things – we want to have a lot of flexibility. We are really pressured by time to market. We have one customer that literally wants chips – when chips come back – they want silicon in their hands in 10 days. In the old days, it would take us 10 days just to bring the chip up. So we are under a lot of pressure to get things going out the door correctly.
And with so many chips going out, we actually would have a hard time knowing where we were even taping out. We found we were doing a lot of XORing of GDS files to figure out which LNA [low-noise amplifier] we put on that chip. So just being able to build chips, or even just the radios, with clearly defined contents of the chip, is extremely valuable for us.
It’s clear what was in the tapeout and also, it’s clear what we changed between the revisions, like an A0 and an A1, or an A0 and a B0. Sometimes, like all of you, we have different versions in production at the same time, and we have got to know which version has different versions of the sub-blocks.
Three Best Practices for Design and IP Management
Some of the best practices that we put in recently, again are very specific to our team. Our team, 90% of our work is using Cadence, we draw schematics, and we do custom hand layout.
And again, analog designers think differently. They are not really familiar with version control tools. The whole concept of branching is very foreign to them, and they don’t care to learn it. So we have to impose certain restrictions on them, so that they will follow best practices, and we also can’t get in their way. As soon as they say you are putting too many restrictions on us, they can get our methodologies kicked out if they are too much of a burden. So one of the things that we have been able to do recently, is just make a simple rule: If you are designing a block, it has to be self-contained within a Cadence library. This really simplifies IP reuse and bug tracking.
Another thing that was enforced recently, using IC Manage, is now you really can’t check in cells one at a time from a schematic or a layout. So we’ve been able to push designers to check in changes as collections. Before, a layout engineer would have to check out a lot of different cells to fix a DRC error. They would fix it in one layer, check it in, fix it in another block, check that in, fix it in a different block, and then check that in.
By forcing them to use a different tool to do check-ins, they can check in all those changes in one shot. That way, if it turns out it was a bad decision, we can easily roll that out. Just a slight tool change got us moving in that direction.
Another thing we are trying to enforce now: before when people needed a new block for feature, they would just copy a block, and then start adding it. From an IP management perspective, that is really bad. All of a sudden, you have just cut any kind of version history – you’ve lost all traceability. And to them, it’s like, “I just right clicked and copied.”
So now we’ve really encouraged them to branch the design. We’ve taught them what branching means, and how this is gives the advantage of figuring out where the different blocks are being used.
Top “Must-haves” from a Design Management Technology
Some of the must-haves that we identified: We need to be able to identify where the IP is being used. This is really critical. A lot of times, especially with analog blocks, they look fine in simulation. They actually look fine during bring up. It might even look fine during production. And all of a sudden, you hit a process corner or a certain weird effect, and you have a huge fall out, and you have to identify all the different radios that are using that block, because you have to roll in, screens at ATE to catch that bug.
I had one chip that started failing miserably because the fab forgot to change a filter in one of their gas filtration systems – one block was very sensitive to that. Trying to identify all the radios that had that same block, so that we could put in a specific test, was very challenging.
So we need to know where all the IP is being used. And we also need to be able to apply bugs on this IP, and allow these bugs to bubble up to the top. Then, if a new chip lead comes in, and they end up using that bad block, they will automatically see that bug before tape-out, and know that they either have to change that block, or make sure they have the appropriate test to catch that block’s failures, after the chip comes back.
Measurable / Concrete Results
As far as measurable and concrete results, we’ve only recently moved over to IC Manage. We are starting our second chip right now. Some of the things we can easily see that we will gain are:
- Having confidence in what we are taping out. I kind of covered that – before we would have to run around doing XOR on GDS files.
- Being able to alert chip leads of errors on blocks that we have already identified, so that they can actually tape out a chip with few errors.
- Then quickly and easily configure new projects so that we can reuse IP.