In my semiconductor and EDA travels I’ve enjoyed visiting engineers across the USA, Canada, Europe, Japan, Taiwan and South Korea. I’ll never forget on one trip to South Korea where I was visiting a semiconductor company and upon reaching the lobby a security officer asked me to take out my laptop computer, because he wanted me to issue the dir command at the C: prompt so that he could write down how many files were on my computer, and the exact number of bytes. After my visit and presentation with the customer, the same security officer checked my laptop again to make certain that there were no extra files on my laptop, keeping his facility safe from IP theft from a visiting EDA vendor. That got me to thinking about how semiconductor IP is used, shared and protected, because in the USA we have “the deemed export rule” where the release of a controlled technology and info to a non-U.S. person, is considered an Export.
Releasing sensitive IP to a non-U.S. person while not having a deemed export license is a violation, and the fines can cost you dearly, thousands to millions of dollars. One semiconductor company paid a $10M fine for violating export control laws in 2014.
When I designed chips at Intel we would share IP between design groups in California, Oregon, Japan and Israel, but all of our IP tracking was done by a simple email exchange, nothing really traceable and certainly not enforceable. So in the industry today we have the issue of IP leakage, which is simply IP that inadvertently is getting shipped to a country where it is not allowed. Here are four examples of IP leakage to consider:
- Access controls where anyone can view and download IP without any enforcement.
- Using tar balls to share IP.
- An IP block embedded inside other IP, but without any visibility or traceability.
- A traveling engineer unaware of IP restrictions in a visited geography.
The IP Lifecycle Management (IPLM) experts at Methodics are on top of this issue of IP leakage and have designed a tool called Percipient that helps engineers prevent accidental IP leakage. The approach with Percipient is to use a centralized, traceable management system with an admin sets up permissions at the very start of a project. Three levels of permissions are defined: Read, Write, Owner.
Percipient works with existing infrastructure like the Unix file system and your favorite Data Management (DM) system: Perforce, Subversion, Git, etc. All of your IC design data stays in its native format, and Percipient integrates with the data sources, connecting IP producers to IP users.
With this approach an engineer can quickly build a workspace using a native DM system, and each workspace is traceable and tracked, so no more email messages and manual methods to keep track of everything by hand.
IP often uses a hierarchy which includes many smaller IP blocks, however if one embedded IP block several levels deep is restricted then how would a user know about that at the top level?
The architecture of Percipient understands and preserves all of your IP hierarchy, so there’s never a chance of accidentally sharing a restricted IP block buried deep inside of any hierarchy.
The challenge of an engineer traveling to a new geography and then starting to build a workspace, inadvertently starting to use restricted IP needs to be addressed. In Percipient there’s a feature called ‘geo-fencing’, where there’s a self-managed IP Cache and fencing enforces a “Do Not Download” list for all IPs in the cache. An admin marks each restricted IP block. Here’s a diagram of how the “Do Not Download” feature is enforced:
In this methodology a user is blocked from loading any restricted IP for their geography, and the admin can show through traceability that no sensitive IP was accidentally leaked.
Summary
The semiconductor industry has spread worldwide, and yet the concern for protecting semiconductor IP remains a looming issue as ITAR (International Traffic in Arms Regulations) and Deemed Export Rules have steep financial penalties for those companies that are leaking restricted IP. Instead of using manual methods to track IP and risk the chance of IP leakage, why not use something like Percipient that helps to automate and enforce IP reuse in a safe, legal manner.
In this blog I’ve summarized the features and methodology used in the Percipient IPLM tool which block accidental IP leakage, so that your engineers can concentrate on bringing to market new SoC systems and products that satisfy export rules with the least manual overhead.
To read the complete 11 page paper on this topic, visit the Methodics site and register.
Related Blogs
- Webinar Recap: IP Security Threats in your SoC
- Workflow Automation Applied to IP Lifecycle Management
- Achieving Functional Safety through a Certified Flow
- IP Lifecycle Management and Permissions
- A Brief History of Methodics
- A Brief History of IP Management
Next Generation of Systems Design at Siemens