Chip Design Teams And Restaurant Kitchen Staff Have A Lot In Common

By Anagha Pandharpurkar

Believe it or not, electronic device and systems-design teams have a lot in common with kitchen staff in big commercial restaurants: They both leverage many different tools and resources to churn out great products in a high-pressure environment to a demanding audience that wants it now, not tomorrow.

Unfortunately, design teams are often not nearly as well equipped to complete their projects as kitchen staff are. In a well-run kitchen, the staff knows exactly where every knife, fork, pot, pan, ingredient, and appliance are, and they know what shape it’s in. In design engineering, it’s not often that orderly.

This challenge has increased in recent years, as the use of IP blocks has soared to speed design, keep costs low, give teams the opportunity to focus on their device’s core value and achieve first-time silicon success. From the most basic building blocks such as matrix multipliers and DSPs to the larger subsystems such as a memory or compute subsystems, design and implementation is being done keeping reusability in mind. The challenge comes because these data blocks may be scattered around, built by diverse teams separated by geographies, business units and using different infrastructure for management. It’s as if the knives were stored in the refrigerator and the pots and pans were sometimes hanging from hooks in the kitchen, sometimes stuffed under the bathroom sink.

Most engineering teams recognize the challenge but often are so busy with design projects they don’t have time to organize their IP management.

Where is the data?

Over the past two decades, design management systems have become an integral part of the design process. A little-celebrated value of the tool chain, they provide a solid backbone in assembling the design and a collaborative environment for the engineers to piece the project together.

Providing version control, work-area management and release management, these data management (DM) systems are no longer considered nice-to-have but are an essential part of the design-to-tapeout flow. The design-management systems contain all the hooks to provide collaboration when the projects are self-contained with few interdependencies. But as SoC design gets more and more complex, the projects now incorporate reusable components from a host of other projects. They include IPs that can have complex hierarchical relationships. The IP components might come from different projects. It would be convenient to have a tool that provides a high-level view of the project – as design and IP blocks, rather than files and directories. The data files could come from different sources managed in different data management systems. The end user need not be aware of where the individual components come from or what DM systems manage them.

Where are the IPs?

In this context, the first step to IP reuse in a design would obviously be to easily find the IPs that can be used in the design. (In other words, the knives should reside in a drawer near the cutting boards).

The reusable blocks exist in IP repositories – either saved on network disks or managed in a design management system such as Cliosoft’s SOS, Subversion (SVN), GIT, etc. In smaller companies they may all exist under one design management system. In larger companies, with diverse teams and business units added through acquisitions, the IPs may exist in multiple design management systems.

Within a company there might be several IPs that provide a similar function but have different parameters. For example, they may have been targeted for different process nodes or may have different power modes, etc. It would be convenient to find the right IP by matching the parameters required in the current project.

The IPs may have been built internally or acquired from third-party vendors. In case of third-party IPs, there might be licensing restrictions to be aware of before using the IP in the project. For different IPs there may be different levels of approvals needed to make sure the IP usage is in compliance.

Cliosoft HUB provides all these capabilities in a catalog that is easy to browse and search. The IP metadata is tracked in attributes and documents that can be configured based on the different kinds of IPs available in the company. The IP data itself can be maintained in the design management system or on disk. HUB tracks the data location fields necessary to give access to the IP to users who have been approved to use it in their project.

HUB provides a project page so the users can track the IPs they are using in the project. The IPs can be managed in different design management systems. These systems are registered with HUB, so HUB is aware of the exact set of commands to run to publish and download the data. There are hooks that make it easy for the HUB administrators to plug in a new and proprietary DM system to access the data using HUB.

Get it together

Mid-sized to large companies may be using a multitude of systems for design and development. If teams have been added through acquisitions, they may be using different products in their toolchain. For example, each team that is producing the IPs could be using a different design management system to manage the IPs. Since the IPs are coming from diverse sources, does the engineer working on the design now learn a plethora of commands to interact with the different DM systems? Wouldn’t it be much easier if there were a uniform set of commands for the user to interact with the project and IPs in the work area?

HUB can make this assembly much easier for the user working on the project. Registering the various design management systems allows HUB to create wrappers around the various data management operations. With HUB being aware of the DM system managing the project as well as the IP data location, users can now use HUB to:

• Create a work area for the project, bringing in the project data as well as IPs in the project BOM. The IPs could be coming from different data management systems.
• See the status of project and IPs in the work area at IP block or file level,
• Update to newer versions of the files as newer revisions of the IP are published and added to the project BOM.
• Flag conflicts if there are different revisions of the same IP used in the hierarchical BOM of the project.
• Extend the DM operations by adding pre and post event script-hooks to massage the data brought into the work area.

Restaurant customers who have to wait for a meal because the chef couldn’t find a key saucepan might not come back next time. Similarly, design teams whose project schedules bog down because of issues around finding the right, up-to-date IP risk losing out to swifter, more efficient competitors. Design management systems like Cliosoft’s HUB take the important work of managing IP in fast-moving engineering departments off the heads and hands of the team, and make it easier, faster and more cost-efficient to innovate.

Anagha Pandharpurkar is the Director of Software Engineering at Cliosoft.