IP or not IP that is the question

At the same time vendors are taking IP and applying it in ways that the manufacturer could never have predicted.

So what needs to change?

One of the biggest issues with IP is that there is rarely any warranty offered to ensure it functions as it should.

For the engineers on projects there will be occasions when you receive a chip back from the foundry only to find it doesn’t work and, after weeks of testing, it’s the IP at fault. IP should be something that just ‘works’ as you expect it to, but instead it’s more the case of ‘buyer beware’.

There are projects where we’ve spent so much time de-bugging and fixing IP, that it would have been quicker to develop it fresh ourselves. This is slowing up the whole process, costing companies time and money but is something that can be fixed.

Bigger is not always better when it comes to selecting IP vendor. While bigger companies will have the massive R&D budgets to spend, many have legacy products that have been around for over 20 years and have genetic in-house patches and work-arounds.

When buying IP, unless you’re working on the bleeding edge, the first question should always be is this IP currently in commercial silicon? Ideally is this in volume?

Many of the challenges with IP integration can be solved by both parties stopping to think about the bigger picture. Those who make the IP are rarely, if ever, the ones who will actually be integrating it.

To go back to the car analogy, both parties need to consider what the IP could be used for and in turn what it was designed for.

Some IP will come advertised as being able to do a certain function, but what isn’t obvious it that this is sometimes only true when using specific libraries; or IP can come with a cell library from TSMC in it, but the pins are different so you can maybe spend a week fixing it.

This could be easily solved by people looking at the bigger picture – just what is my IP going to be used for and how?

Even testing IP isn’t as simple as it should be. IP is normally tested only using certain processing and with certain Fabs with no margin for process variability – which can be completely different to the real world deployment – again a problem of people not thinking of the bigger picture.

Fur functional verification more worthwhile results can be obtained when verifying IP using a test bench from a different vendor, which will help spot any potential issues and problems before the silicon is taped out.

We’ve previously worked with IP companies to ensure that their IP is tolerant when implemented in several different processes and applications to help them ensure it does the job it should.

Feedback loop

Other companies (major IDM’s for example) have IP standards that their products are listed by; so if it had to be available across any design flow for any application then it would have to be very robust. Whereas if it was just for one design then you’d know it would only work for that and nothing else.

Some IP vendors are lacking any kind of feedback loop. In just one example of the consequence of this, on one design we heard of, the memory didn’t work, only reading zeros and not ones.

After telling the vendor, we heard of another company who was using the same IP but had not been informed of the problem.

By nature, engineers are more than happy to point out problems to IP vendors and help improve products, but these opinions are rarely sought and then rarely listened to, and sometimes confidentiality (and perhaps pride) can get in the way.

While for the most part silicon IP does work – it still comes with a comprehensive ‘buyer beware’ note. Yet the reason you’re buying it is because you don’t have the time or expertise to check or do it yourself.

What’s needed is an IP ‘gold standard’ where silicon designers can be sure that the IP does exactly as it should. By implementing this IP will become infinitely easier to use and integrate.