中文 English

IP Tracking and Management

Experts at the Table, part 1: What are the important elements of an IP tracking and management system for providers and users?

popularity

Semiconductor Engineering sat down to discuss IP tracking and management with Ranjit Adhikary, VP of marketing for ClioSoft; Jim Bruister, director digital systems (since retired) at Silvaco; Marc Greenberg, product marketing group director at Cadence; and Kelvin Low, VP of Marketing at Arm. What follows are excerpts from that conversation.

SE: What is the scope of the problem? What are we trying to do with IP tracking and management?

Bruister: It is a broad subject. There are a number of different ways to look at it. On one hand it is version control. ‘Can I check in designs? Can I check out designs, keep track of them, maybe bug tracking?’ But in a broader sense, it could involve the notion of IP distribution. Not only keeping track of things, but also distributing IP, license management, and all of this can tie into version control and bug tracking.

Greenberg: One of my biggest problems is the tracking side. We license IP and a lot of the IP that we license is in source code form, such as controllers. There is no technical reason preventing people from misusing that. We are always interested in trying to track where IP actually got used. Did you purchase the appropriate number of licenses? There are a couple of solutions: we work with trusted companies and we work closely with our customers, but we need trust but verify approach.

Low: We have a challenge with IP management. Foundries come to us with so many processes. For the IP ecosystem, it is extremely hard to figure out where to invest. It is not possible for one company to invest in all of the variants out there today. Another problem is, especially in leading edge technology, where the silicon foundries are trying to push the technology out earlier and the PDKs are not stable. The churn can be extremely costly to keep up with some of the process flavors or even PDKs.

Adhikary: If you are doing analog IP, for example, and if you want to make changes to the IP, where does the documentation lay, where does the verification suite lay? If certain things were done, why was it done? What people are looking for is the information associated with my IP. They are looking for a knowledge base so you can reduce the support for the IP developer and if anyone wants to use an IP, they can look at the knowledge base and find answers to their questions, find all of the necessary collateral. Irrespective of what data management system you use, you need one portal, for all designs within the company, and this is where you can get all of the information. The second part of having that is the traceability aspect – that means that if someone is using an IP, you should know who is consuming it, what projects and the reasons why they chose your IP, if there are any. If you are using 3rd party IP, you need to make sure the license agreement has been signed. A lot of companies, such as Arm, want the concept of workflows wherein they want to see the authorizations for each level. If you have a floating IP, for example, you don’t want noise to be put into the IP, so you want a script to run and say these are all of the checks to be done and the results are annotated back into the system, goes to a second level and finally uploaded.

Bruister: Lets see if I can bound the problem. Tier 1 companies have distributed engineers all over the place and they have either developed a lot of IP over the years in house or they have bought 3rd party IP and the design staff is distributed. A simple UART – someone may have 20 different UARTs that they have licensed over the years, so it is a big management problem. How many different versions do you have, who did you buy them from, how do you keep track of this, how do you know if you are using them, and if you have a valid license? A lot of design teams don’t care about legal stuff and licenses – they will select a UART based on any number of reasons, but they may not be allowed to do that based on the licensing. If there is a lot of IP that is misused, it could be a potential legal problem for companies.

Greenberg: And that can happen completely accidentally. You just take a design database and finished rev 1 of the chip. Now you are going to do rev 2, and you take the old design database, and along the way someone forgets that there is a licensed IP in there that requires another license.

Adhikary: This happened to a customer of ours. It was found when they were audited by another IP company. Most engineers do not think from a licensing standpoint. What we need is a system that checks the validity of the license, and if the license is expiring, it needs to notify the appropriate administrator. This can limit the liabilities to some extent. It is not just external IPs that people are concerned about. Many companies develop PDKs, and that is an important aspect. Foundries are more interested in developing PDKs because each PDK gets associated with one analog IP and they want to ensure that it is not disturbed. You need to keep track of the relationship between the two. Then there is the question of internal IP. If you are developing a USB core in two different groups, in two different geographic areas, why would you do that? Visibility makes a big difference.

SE: For an IP company, how many variants can be expected to exist at any point in time?

Bruister: That is limitless. You have to look at two scopes—the scope of the OEM that is purchasing the IP, and the scope of the IP vendor that is licensing it. For the guy purchasing the IP, they want to have the latest version or the best IP when they do a new design, but chances are they don’t know about it.

SE: Would they update IP during a design?

Greenberg: You can take a PDK update.

Low: That is becoming more frequent.

Adhikary: In the analog/mixed-signal space, people will be using versions of an IP and then they get a new update. They want to test it out before they use that throughout a project, so we have teams on the IP version itself, within the project’s lifespan.

Bruister: If you are an IP provider, it is important to have a management system that alerts people to the IP version so they know if they have the latest version. It is important, as an IP vendor, that you have a system that tracks your licenses, who owns it, who is using it, and you need to have a tracking system of the changes so that you can alert them. We have this capability of fingerprinting where you can fingerprint all of the IP. You can tag IP and its database so that if someone uses that piece of IP or some of the IP contained within a part of a larger design, then you can run an analytics report and find it. Large tier-1 companies can then find out if they have unlicensed IP in their design, or whether it’s the latest version.

SE: What if you change the IP? How do you protect against derivatives that may be malicious, accidental, which try to circumvent licensing?

Greenberg: That depends upon the IP. Common license terms and conditions say don’t do that. That is one form of protection. A well-meaning engineer getting into the middle of the code and changing something is a common provision within the industry. ‘If you broke it, you bought it.’ When engineers receive IP from the vendor, they recognize the vendor has validated it, regressed it, put it into other people’s chips, so there is not a lot of desire to touch it for fear of breaking it. They may not have the whole testbench.

Adhikary: When you get a third-party IP, you are signing a legal document. This prevents you from doing anything stupid. Second, at the end of the day, designers want someone to be accountable for the results. They will not muck around with the code. Third, with any third-party IP you get, there will be some deliverables that you are adhering to. You monitor those, and if there are enhancements you are looking for – engineers will not go in change the code.

Low: Large tier-1 companies intentionally want to have some flexibility to modify the IP, but that is a discussion held upfront, and the legal agreement covers that. We allow some flexibility for that to take place. For standard-based IP, such as USB, typically you use it untouched.

SE: So far you are talking about ethical people.

Bruister: Yes, and there can be attacks, trojans or theft. It is a problem. Fingerprinting helps. It is like a sex offender database. It doesn’t stop people from doing crimes, but it helps you find them when they do.

Adhikary: If you are an IP provider, you are looking at supporting different process nodes, you are looking at having IP that can be configured for a variety of platforms, and you need to maintain all of the data. Who you gave which version to, how it was configured, what process was it given on? To manage all of that information in a seamless manner becomes critical. If you are a provider and say a person wants to find the code for that, he needs to know which branch of the code he should use to fix things.

Greenberg: On malicious intent, it is actually quite hard to steal IP. It can happen accidentally from rev 1 to 2. These are customers who are already purchasing the IP. Sooner or later they figure it out and they pay for another license. If it is someone trying to steal it, they will not have any support, and a lot of IP is support-intensive. With outright theft, the biggest fear would be they have no support, they may not be on the correct revision, they will not have access to bug fixes. Given the cost of a tapeout, they are taking a huge risk. Ultimately, there are still ways in which we can find where the IP went. It is hard to keep a whole company quiet, so if there is institutional level theft of IP, then it only takes one disgruntled employee who can blow the whistle. Even if that does not happen and someone releases a chip, and their databook happens to look like your databook – you can find things after the fact and then have a frank discussion when that happens.

Adhikary: Yes, people find similarities. People have learned from prior experiences.

SE: Lets talk about the Cloud. Until all of your IP has become available, working in the Cloud is difficult. Why is it so hard to get IP into the Cloud?

Bruister: Because of legacy companies and their business models. People want to protect their IP and keep it close to their vest. There is a lot of support that goes along with it, as well. There are some people who are worried about it being in the Cloud and that it makes it easy to steal, that there is easy access to it.

Greenberg: We have launched a Cloud solution, and from internal discussions, our Cloud platforms and secure chambers are probably more secure than the rest of our IT infrastructure. Does that create difficulty in getting IP in or out? Possibly, but that is part of the price you pay for security. Access is controlled about who can put stuff into it and take stuff out, and what people are allowed to do inside.

Bruister: That is changing. We have an enterprise system, and we also have a Cloud system, and it is a distributed system.

Adhikary: Security becomes a critical component. You need traceability. Why this is being loaded and offloaded? What issues made them do the upload? Anything you do with an IP, it records why it was done, who was using it, etc. The second part with the Cloud is that upload is free, but download is costly. Do you really want all of the data to be uploaded upfront, or do you just want the metadata that people can browse through to see what they need, and then upload as needed? They are choices that companies have to make and, depending upon the platform that is used, optimize for that.



Leave a Reply


(Note: This name will be displayed publicly)