Internal IP reuse is something that every business wants, although the current scorecard indicates these objectives are not being met. A fairly large gap exists between leadership's vision of an ideal internal IP reuse strategy and the implementations in place today. Management views IP reuse as an essential ingredient of quicker time to market while the design communities perceive it as a road plagued with dangerous potholes. Reality - continue overlooking the designer's needs and internal reuse will remain a distant vision.
Every organization has some type of reuse activity going on. For some, they are content with their current approach in handling reuse. However, for the majority there is more effort required to achieve anything approaching an ideal set of reuse objectives. At the low end of reuse strategies, what I affectionately call Whack and Plop (WAP), is where IP blocks are excised out of an existing chip and dropped into a new design.
A more desired implementation of reuse includes a full repository scheme where the designer can eagerly shop for IP and download it with a full suite of documentation, test benches and characterization data. This ideal vision of reuse is where most want to be, some form of WAP is where most are today.
So what's keeping reuse in the dark ages? It is simply that the needs of the re-user are not being attended to, technology is in charge instead of the needs of potential end users. The fears of reuse are not being addressed and the design community is pushing back because the deliverables associated with IP are not mitigating these concerns. Without proper IP content designers will only reuse what they are comfortable with, either their own work or someone else's work that they respect and have easy access to. The major hurdle today is in achieving a level of IP deliverable content that will diminish the fears of reuse, thus allowing designers to develop the confidence to favor formal IP reuse over WAP or the initiation of a new design.
First Rule of IP reuse - Content Rules
It's not the repository that will cinch reuse; it's the content deliverables for specific IP. If a designer digs through a wonderfully crafted repository, downloads the deliverables and finds 
a deficiency in IP content, you have lost them for a very long time. Start with content, not a fancy repository; content is the foundation of any IP reuse growth strategy.
The worst implementations will be those that are developed solely by a team of non-designers that are great with software. Keep in mind that reuse enablement is not a software or EDA task; it is a deliverable content development task to provide the essential design collateral designers must have to be able to validate and gain confidence in another designers work.
Second rule of IP Reuse - Address Reuse Concerns
Know what the concerns of reuse are and address them. Talk to your design community and make sure you understand both what would enable them to reuse and what would turn them off. This is as simple as listening and applying what is learned. Leave this vital process out and you may as well stay with a WAP reuse strategy; you will be wasting time and money trying to make it work. You can lead a horse to water but you can't make him drink; the solution is finding out what will make him want to drink.
Third Rule of IP Reuse - Marketing Strategy
Develop a marketing strategy to define and roll out the internal reuse implementation. Consider this as a product with customers that need to be wowed. The designer's are not generally a captive audience where reuse has been legislated, therefore it is essential you properly market IP as a product. A proper marketing strategy will also drive closure on the first two rules of IP reuse - giving customers what they need.
Consider the following:
- Appeal - Why would someone want to use it?
- History - Has it been used before? Where? Any data?
- Features - Overly complex or not enough bells and whistles.
- Options - Does it need configuration options to cover a broader design space?
After the first three rules have been addressed it's time to put the IP into a repository. I suggest something pretty simple since there is not likely going to be a large initial offering. The repository can be enhanced over time as you get feedback from the users. A word of warning - don't put anything in the repository that does not meet the first two rules. Any perception of garbage in the repository will ruin your efforts for a long time. Remember - Content rules! The repository leaves a short term impression, what the designers receive from it leaves a long term impression.
Closing thoughts on Internal Reuse
The end user will make or break your reuse strategy. It is paramount to understand what will "make it work" for them.- Think first about what is needed... the deliverable content.
- The repository will leave a short-term impression on the end users. The IP deliverable content impression will last a lifetime. Focus on what matters!
- Creating reusable IP should not be much more effort than a good, high quality design effort!
- Reuse content will need to be kept current based on silicon usage and tool updates. Don't ignore or underestimate your work here.
- Reuse enablement requires the matching of re-user needs with cataloged content.
Posts
This is a great topic Jeff, and one of prime importance.
ReplyDeleteInternal IP reuse is a difficult problem. It sounds great theory and is often difficult to put into practice.
At the engineering level, different designers and architects will have drastically different views on the topic. There are those who put a lot of time and effort into making internal IP generic and reusable in many different dimensions, at the cost of added development complexity. Then, there are those who, when faced with the opportunity to reuse something, say it's easier to make a copy of the original version of the IP and custom tailor it for the next case.
A generator approach offers a combination of both generic-ness and custom tailoring. This allows each IP block to be abstracted into a generic family of IP blocks which can fit into different circumstances given instance specific user requirements and specifications. The related deliverables, which are needed in the IP consumers' problem domain, can be auto-generated.
Such a generator approach aligns with IEEE 1685, the SPIRIT Consortium's IP-XACT XML standard for IP metadata and reuse. The idea is to package all relevant metadata for IP reuse in a way that it can be produced/consumed/shared by the different stakeholders.
For highly generic and widespread IP, like on-chip interconnect and register map interfaces, auto-generation makes a lot of sense. These types of IP share commonalities across all cases, yet differ based on the specifics of the IP and system. Each IP block will have something to contribute to the system, and each system will have a different overall interconnect and memory/register map. Commercial tools like SONICS SNAP, Altera SOPC Builder, and Xilinx XPS can take care of the interconnect while a tool like PDTi SpectaReg takes care of the the System and IP level registers maps for design, verification, documentation, and firmware.
The value of a commercial tool over an in-house solutions makes increasing sense as more and more sharing of IP is needed across teams and locations. Imagine trying to create a book with 10 chapters written by 10 different people. Imagine each collaborator uses a different word processor with a proprietary data format. Creating the overall document would be difficult. Having everyone use the same word processor format and tool for their content and deliverables makes it easy. This type of "network effect" is needed for economical, ecosystem-wide reuse and integration of IP.
Hi Jeff
ReplyDeleteIt is great to hear that people are taking re-use seriously – 5 years ago we had to sell the problem, before we could start talking about any solutions!
I agree with your comments and would like to add the following:
In order to achieve successful re-use it is important to capture information about overall IP design intent rather than domain specific information or static views. IP information stored in a repository should be in a suitably abstracted form so that it can be used to create a breadth of views, rather than storing information for a single point solution. For example a spreadsheet to automatically create a C-API using a VBA script does not necessarily help with views required by hardware and verification teams.
This leads on to the re-use mantra: Minimum data for maximum benefit.
Engineers are only human and are under pressure to delivery their projects on time. For IP re-use to work it needs to be as unobtrusive as possible and introducing it within organisations cannot be at the unacceptable expense of delayed project deliverables. This means you typically need very effective capture, import/parser tools and by distilling the information required by the different teams involved in a project, it is possible to create a common set of data that requires minimum capture time for maximum re-use benefits.
Finally any re-use solution needs to have extremely effective checking and output view generation capabilities as this is where its major benefits are. Engineers must be able to quickly create generators for new views or tweek exisiting ones otherwise you will hear the fateful words ‘ ..it would have been quicker for me to have written that by hand!’
Clearly working with Duolog Technologies I am biased towards commercial IP re-use tools such as Bitwise, but I genuinely applaud any forward thinking companies or individuals who promote re-use – regardless of the solution they adopt.