You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • How to Live with Rapid Changes During Early Development of IP

    Best practices call for using a version control system with systematic releases when developing IP. However, in the early stages of IP development using a rigid version control system with a cumbersome release process can hinder productivity. To fully understand how this works we should start by defining what is meant when we say IP.

    The term IP is used broadly in IC design. It can refer to libraries, memory blocks, or portions of a design coming from internal or external organizations. Furthermore, blocks developed using IP may themselves become IP for higher level design. In this case the lower level IP are referred to as IP resources.

    Article: How many languages an Engineer should speak?-ip_lifecycle.jpg


    Methodics has thought through the implications of developing and using IP early in a project’s lifecycle. This stage is characterized by rapid changes and short loop iteration. If each time a work in progress change is made early on in the development process, it was necessary to create a release, the entire work flow will be slowed down. To solve this problem Methodics supports a specification that uses the most recent version of the files to populate a workspace. This is known as IP@HEAD.

    Article: How many languages an Engineer should speak?-ip-head_example_1.jpg


    There are a number of subtleties in its usage. They key point being that loading a workspace with IP@HEAD will pull in the then current versions of not only the IP itself but the resources the IP relies on. Additionally, if the IP resources are themselves running on an orderly release system, as opposed to @HEAD, then the most recent release will be what are loaded. A release update of an IP resource will update the user’s workspace that is using @HEAD.

    The history of design management in the IC space is a long and checkered one. It is definitely a different problem than source code revision control management. Designers have balked at systems that impose restrictions on their method of operation. The cost benefit-trade off is most difficult to justify at the beginning of a project, especially if the design management system is imposing unneeded and inefficient processes.

    Later as a design matures, the benefits are more readily apparent and design management provides some huge wins for reliability, quality, repeatability and traceability. When a design starts by using IP@HEAD for its workspaces, as the design matures a release methodology can be put in place so there is less uncertainly as functionality is stabilized.

    Methodics has built a sophisticated IC centric data management system. One of the plusses of their system is that it is based on industry standard revision control systems like Perforce and Subversion. This means that the design data will never be locked in. Their infrastructure also enables multisite sharing, disaster recovery and design progress analytics.

    If you want more information on using IP@HEAD in Methodics, please look here. For more general information about Methodics their website offers useful information.

    Follow the adventures of SemiWiki on LinkedIn HERE!