At Cypress Semiconductor, We have dealt with IP reuse and IP management for many, many years. Unlike Calvin, I was too embarrassed to put up exactly how many years. So I put 10+ years ago. We actually had our own CVS-based solution exactly similar to Calvin’s. I actually recognize dollar IDs from back in those days.
About 10 years or so give or take we had moved to the first commercial product that was available at the time. It significantly improved our life in general; it improved the stability and improved the feature sets.
One of the bad things we noticed with that particular solution was that the scalability was just non-existent. We would actually grow our number of servers so much faster than we could actually maintain the data on it. It was just getting unwieldy and out-of-control.
IC Manage came into the picture about 6 years ago.
That’s the time when we started working with these guys, to figure out their advantage and what could we leverage from their product portfolio.
We rolled out IC manage. Cypress is one of those companies that does not go piecemeal; we either go hook, line and sinker or we just don’t do it at all. So IC Manage became literally a mandate overnight. We decided it was the solution for us and we went full tilt to deploy it.
- It was incredible to see how quickly we ramped it up. We have literally reduced our servers in our data centers by 30X.
- We have improved our support by an additional 2X over the previous DM solution, so we are about 4X from our original implementation internally.
- The performance has definitely gone through the roof. We have definitely noticed significant improvement in user satisfaction. People didn’t even really know what they were missing until they start working with IC Manage.
- One of the things that IC Manage brought to the table for us many years ago was configuration management. We used to have our own configuration management on top of the EDA solution.
However, once it was embedded and part of the system, it truly enabled real IP reuse. I’ll talk about in a couple more minutes.
Cypress used to have many more design centers, but even with the advent of a reliable data management solution, we actually consolidated more -we have gone from about 14 design centers in the past, to about six. That seems to be the right critical mass for the design centers to be fully functional and capable.
So today Cypress sits at six design centers worldwide.
The green arrows represent the contributors of the IP, and the developers, who check in the data into our San Jose repository. And then out of there, full chip groups pull the data.
It happens every which way you can imagine. It is synchronous, it is asynchronous, and it happens at all times of the day or night. People are updating it all around the world. If you just try to picture this in your head and try to imagine this in any way shape or form. It falls apart unless you have a very reliable system to enable your teams. So let me talk a little bit about this…
What does a reliable system and solution mean for IP reuse?
I made a couple of assumptions in this presentation – which are big ones, don’t get me wrong – these are very important concepts that you have to solve before the IP actually works for you.
- Product family architecture with the proper partitioning has to be written upfront, well-defined, and followed by everybody. That goes for both the software and the hardware.
- Competent IP owners have to be there, they have to be present, and ready to execute. At Cypress we call them the teams of experts. We actually have teams that are responsible for one type of IP product. They are not large teams. They are usually fairly small, they range between two people, up to 10 or 12 people.
- But all they do is that one particular part kind of IP. So they go from generation to generation, learning and growing and improving the business process as well as the knowledge of what it means to be ADC expert, a PLL expert, whatever else you may be.
- Finally, a big assumption here is that you can manage your own risk. You have to control how many new technology processes you’re introducing. How many new IP blocks per design you are actually trying to deploy.
Think about it. If you have a modern SoC, with say 70-80 IP blocks on it, what is the success of any given IP block working the first time around? If you’re really good at your job, right, it’s about 60- 70%. Take the number of blocks, raise it to that power, and the odds are astronomical that your chip is not going to work.
So managing how much new IP at high risk you put on an IP is absolutely critical.
Okay, so now I’ll talk about the execution challenges themselves.
At Cypress we have this word “Survival Kit”.
It’s kind of a military term for “Don’t give me a field guide that’s 120 pages long. Give me 4 or 5 things I can think about.” So I tried to list those things down for you just as a quick reference.
- Unified high-performance incapacity version control management system. Critical. Crucial. It’s a stone foundation of yours business process. We saw a GTR downstairs which I suddenly appreciate, I love that. But believe me a GTR is not good enough. You have to put together quality business process which will sit around your GTR, or a driver in this particular case, to achieve results.
- On top of that you have got to have a unified bug and notification system, for your IP developers as well as for the full chip, so that around the world everyone is aware of what is going on with which particular IP, and what their status is.
- Communication language. I don’t know how to put this in any better terms, but at Cypress we use very standard communication language for IPs.
- Milestones are uniform across the board for all the IP. Don’t forget the software and the firmware, exactly the same story.
- The directory structure is exactly the same, whether you choose to follow IP-XACT, or you choose to follow some other directory structure – which we do, by the way, as IP-XACT was born a long time after we invented ours. What this enables you to do is that for any piece of IP it comes to you, you know exactly where to go to locate the data.
- The deliverables themselves – the IP. You have to have standards, meaning what are they delivering? What I mean is how many views are they delivering, what types of views? Just having a LEF, DEF file, GDS files, a schematic and so on, is not adequate. What’s really important is to establish quality aspects in terms of what the IP developers are supposed to deliver around the world.
If you can put some automation in place, that’s a huge win. There’s no comparison. At Cypress, we actually have a mechanism in the system, where every IP developer has to meet a platform bar. That starts with the timing, with the power, with the types of views you have to deliver, as well as the quality of those views. Just having a SPICE netlist is not good enough. It must contain certain data in it, and it must meet a certain set of requirements.
- A unified execution tracking system. Years ago we would cut our IP developers lose, they would go on their own, and we would find out two days before tape out that was not going to happen. We would have IPs all over the world that were just not ready. You have to roll up all the status somehow, in some visual manner, so you can keep track of what’s going on. Which IPs are slipping, which ones are having problems, and be able to deploy the resources, and optimize their particular part of the equation. Because if any one of those IP blocks this on a critical path, your project is going to blow up.
Finally, and this is learned through many whippings and bleeding: verification IP, software and firmware have to be treated exactly the same way. They are not red-headed step children. They have to fall into the exact same equation, same picture.