tag:blogger.com,1999:blog-34363336.post196067898482724737..comments2021-05-25T07:58:48.563-07:00Comments on Coaching Excellence in NPD Teams: Why your Internal IP Reuse Strategy is not WorkingJeff Jorvig - IC Design Leaderhttp://www.blogger.com/profile/15518464303087106227noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-34363336.post-83852225291844572062010-02-10T02:32:29.843-07:002010-02-10T02:32:29.843-07:00Hi Jeff
It is great to hear that people are taking...Hi Jeff<br />It 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! <br />I agree with your comments and would like to add the following: <br />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. <br />This leads on to the re-use mantra: Minimum data for maximum benefit. <br />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.<br />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!’<br />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.Mike Smithhttp://www.duolog.comnoreply@blogger.comtag:blogger.com,1999:blog-34363336.post-46339216150724478222010-02-03T11:07:37.442-07:002010-02-03T11:07:37.442-07:00This is a great topic Jeff, and one of prime impor...This is a great topic Jeff, and one of prime importance. <br /><br />Internal IP reuse is a difficult problem. It sounds great theory and is often difficult to put into practice. <br /><br />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.<br /><br />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.<br /><br />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. <br /><br />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. <br /><br />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.Jeremy Ralphhttp://productive-eda.com/register-managementnoreply@blogger.com