What comes to mind when you hear the term IP Distribution? How do people like ARM and MIPS get their cores into people’s hands? Pricing, contracts and legal issues? Maybe third-party Web sites like Chip Estimate and Design & Reuse? Yes, they are all factors in how independently developed IP gets distributed to users. But as the commercial IP industry matures, these things are getting much more efficient and well-oiled.

For me, when I talk to people about IP distribution, the conversation generally focuses on how IP—mainly internally developed design elements, including things like PDKs, libraries, test files, constraint information—are shared among designers and across companies. In the ‘old days’ this might not have been that big of a deal, as internal networks could handle the relatively small amounts of data being shared. Plus, more centralized design teams made the challenges a bit easier, as they had more direct and efficient communication.

Two things have changed dramatically that are making internal IP distribution a major issue, and neither of them should come as a big surprise.

First, the volume, complexity and sources of design data required for a modern SoC have exploded, bringing even well-designed networks to their knees in terms of the speed at which they can deliver data to clients. This can result in very frustrating delays and unpredictable design schedules—neither of which a manger wants to hear about.

And second, design teams are much more dispersed than in years past, with engineers of different backgrounds, disciplines and knowledge levels spread across the globe. This scenario can add layers of inefficiency as designers work with unfamiliar IP, the wrong versions of IP, and suffer from a general lack of coordination project-wide.

Let’s look at what I would call the infrastructure issue first, the bandwidth of existing networks. Networks aren’t keeping up with the huge amount being moved around, and the Band-Aid solution—remote data centers—complicates matters more. For example, complex PDKs often can take a full working day to propagate to remote design centers using traditional methods like Scp and RSync. This first problem has become one of the main bottlenecks for keeping distributed teams connected and able to collaborate successfully (see problem #2).

One of the issues is the serial nature of how IP is distributed, i.e., one IP block at a time along a serial pipe without leveraging the existing versions and generating deltas between the before and after versions. Also, managing and scheduling the transfers can become a bottleneck.

We don’t actually need faster networks, although like never being too rich or too thin, you can never have too much bandwidth. A more sophisticated way to manage design data would go a long way to improving the performance of data distribution. We are seeing more companies moving to centrally managed systems that allow IP use and revisions to be tracked across the enterprise, but also use project IP workspaces at the client level. Work gets done at the local level, and updates are easily checked in to the master system. Data distribution is parallelized, which is particularly useful in expediting delivery to remote sites. In our SoC Integrator system, for example, read operations (version history, locks, etc.) on the repository are always local operations for remote users, and write operations are sent automatically over TCP/IP to the master. As a result, communications between IP “owners” and “users,” regardless of where they are located, becomes much more streamlined. That allows for easy defect tracking and project management. These portal-like structures are great for monitoring IP validation regressions and tracking bugs, too, and generally keep people “on the same page” as designs evolve, without huge amounts of network traffic being generated.

Not that there aren’t things that can be done to improve overall network performance. A well-conceived IP distribution system 1) offers scalability that takes advantage of an optimized relational database to ensure rapid response times; 2) supports an efficient streaming network protocol to minimize the effects of latency, and 3) uses an intelligent, server-centric data model that is network-friendly and keeps the database performing at top speed. Also critical is on-demand data replication across remote data centers, which reduces network traffic and storage requirements.

IP distribution is the lifeblood of any company developing advanced SoCs today. It shouldn’t be left to chance, or be a bottleneck, through the use of insecure and overly burdened corporate networks. Think strategically about how your design data is shared, updated and archived, and I am certain you will see significant improvement in designer efficiency.

–Simon Butler is the CEO of Methodics.

By Simon Butler
Over the past month I have had the opportunity to visit Japan and Europe through my company’s participation in the EDS Fair (in Yokohama) and IP-SoC Conference (in Grenoble). Both events attracted very focused groups of engineers and management, whom I think represented well the specific needs and challenges involved in SoC design in those regions. Both regions are typified by large, electronics companies that usually have dispersed design teams and lots of legacy IP and design data in house. Those characteristics create the ideal scenario for design chaos.

I had the chance to talk many people involved in SoC design and IP use during these trips. While culturally very diverse, their challenges when it comes to managing, assembling and verifying complex ICs are very similar. Currently, the majority uses a combination of techniques to track the critical design data they need to reach the tape-out phase of a design. It’s actually quite shocking how such large, otherwise sophisticated, companies manage design data—through retrofitted CM tools and IT databases, various cataloguing schemes, spreadsheets, intranets and wikis (often sporadically supported and updated), or just plain old e-mail.

While there is almost universal acknowledgement that there must be a better way to manage SoC development, it typically seems as if it is always “someone’s else job” or “down the list of priorities.” That’s understandable, given the time and resource pressures these companies face, and the notion of taking one step back to take two forward is often hard to accept.

In a nutshell, these companies are desperate for a more structured, reliable scalable and purpose-built way in which to manage all the moving pieces of SoC development. Yes, they want faster and more automated tools for specific design tasks. But clearly, without a solid foundation on which to base a design methodology and the massive amount of data inherent in these huge ICs, the benefits of better EDA tools are lost in the mayhem of trying to manage data across multiple teams, time zones and design projects.

At the IP-SoC Conference, I sat on a panel discussion that included two large users of IP—FPGA supplier Xilinx (which is both a user and supplier of IP), and mixed-signal IC supplier ZMDI. Both representatives talked about the huge challenge of IP management and what steps their respective organizations are taking to tackle the issues. While both are major users of EDA tools, it was clear that IP management was the critical aspect of their product development process, and they both recognized the time and cost savings that can be realized by investing in a dedicated process. The ZMDI manager said that by implementing best practices in IP management, his organization can realize a 5x productivity improvement over an entire SoC project.

The issues at hand
The first step is to understand the nature of the problem. In general, I can categorize the issues I heard from SoC designers into four buckets (and by the way, these are similar to what we hear in the US as well):

First, IP distribution is slow and inefficient. By IP, I mean any kind of design data asset—a PDK for example, or test coverage data. And distribution refers not to the process of how the IP is acquired from the supplier (whether internal or external), but rather how it is disseminated across the relevant design teams. Networks aren’t keeping up with the huge amount so data that need to be shared and remote data centers complicate matters more. I heard horror stories of how it takes up to 8 hours or more to complete the distribution of a PDK. And, there is also the tricky matter of IP security to deal with.

Second, verifying IP releases is very difficult. By this I mean the process by which design teams ensure they are using the right versions and the right combination of IP deliverables to achieve design closure. I heard one case where a company tracks 120 different types of IP deliverables for a single IC design. Imagine the data management challenge associated with that. As a result, I often hear of “design paralysis” as organizations are afraid to release a design to tape-out because they are unsure all the deliverables are in sync.

Related to that is the challenge of configuration management. It is not uncommon for the use of a wrong version of IP to actually cause the need for a complete re-spin of design. With so many hands touching the design, design teams need an automated way to integrate the ‘right’ IP across the SoC subsystem, and a centralized way to manage the final BOM.

Finally, IP quality and the SoC integration process needs to be visible all the way up the hierarchy, at the top-level SoC view as well at the sub-system levels. Again, a centralized and synchronized data management system that tracks IP versions, use and conformance to the specifications would go a long way to giving both desk-level engineers and their management better visibility into the SoC development process.

Personally, I came back from these travels with a renewed optimism about our industry and SoC design in general. Designers around the world are really pushing the leading edge when it comes to complexity and IP use. And the third-party IP industry is responding to the need for better, more innovative and easier to use technology that can save companies time and money.

The challenge going forward will be to centralize IP management, automate release mechanisms to synchronize design data, and to make design catalogs more accessible. That will help solve SoC design problems in any language.

–Simon Butler is the CEO of Methodics.

By Simon Butler
The topic of IP quality in the SoC era is difficult to define, and solutions to problems relating to IP quality, verification, and use are hard to find. Debates rage between IP users, suppliers, and EDA vendors about where the responsibility lies for making quality IP available for use and re-use in an efficient, predictable, and scalable manner.

The use of IP—whether internally developed or sourced from a third party—is inherently complex. IC and SoC projects require a large volume of IP blocks, and the difficulty of managing this volume is compounded by factors such as geographically diverse design teams, a lack of standards for IP use and quality, and shifting design parameters. Today, many design organizations struggle to keep project data organized properly and to communicate changes effectively. Finally, exacerbating the situation, companies suffer from poor or no permission management strategy, bad performance, inconsistent data management systems, and spiraling disk/network resource requirements.

While there are many tools available to help verify, debug, assemble and otherwise manipulate IP, there’s a distinct absence of solid design data management systems that address the specific needs of IC and SoC designers. As a result, IP use often suffers from a bad rap, at least when quality is at issue. Users blame providers, and tool vendors and CAD managers are often caught in the middle, trying to put together solutions that track changes, understand and monitor IP use and quality with models, and offer some degree of version control. Complicating matters is the fact that the term “IP quality” has different meanings to different people: Is IP quality 1) the functional correctness of the IP—does it work they way it is supposed to (i.e., is it bug free)? or 2) defined by the IP’s ability to do what is expected with respect to design parameters such as power, timing, area, etc.?

Developing and integrating quality IP by either or both of those definitions requires a system that can effectively track changes and input across the entire design team at the desktop level and provide real-time access to a wide range of meta data and quality information on IP, as well as keep project managers and other senior management informed on how the use of IP is impacting schedules, budgets and design resources.

Historically, there has been no single way to control, measure, or manage the use of IP in IC and SoC projects. In the past, designers used relatively simplistic RCS/CVS file versioning to manage changes in designs. Over the years, next generation DM (data management) tools emerged that improved performance and reliability. These tools added a layer of abstraction over the file versioning problem. As designs became more complex and design teams diversified, it became common to have multiple DM repositories and even multiple DM tools used on a single project. Companies have also addressed IP management problems through proprietary solutions, or have tried to integrate enterprise PLM (Project Life-Cycle Management) systems.

These approaches have not solved the problems efficiently and effectively, but rather are time-consuming and distracting for an organization that needs to be focused on IC and SoC design rather than project management systems. Further, none provides a complete way to address the specific needs of a complex SOC project.

An SoC-oriented design data management system can dramatically improve IP quality. Improvements in the way designers can access IP information ‘on-the-fly’ and use it to ensure they are utilizing functionally-correct and design-appropriate IP will pay huge dividends. Of course, such a system must be easily integrated within the existing design flow and be non-disruptive to designers. If implemented correctly, a robust DM solution not only ensures higher levels of IP quality, but will result in significant improvements in designer productivity, development costs, and time to market. And, maybe even end the finger pointing!

–Simon Butler is CEO of MethodICs.

Subversion 1.7 was released earlier this week. This is a major milestone in the SVN project and something we’ve been waiting for over 2 years.. Gentlemen, start your engines!

Some of the new features in 1.7 include:

• HTTPv2 – a new HTTP protocol variant designed to enhance performance between Subversion clients and the server.
• A new in-memory caching system for FSFS repository backends
• Network compression – a protocol for avoiding CPU bottlenecks on the compression side.
• svnrdump – a new client tool that provides the same functionality as svnadmin dump and svnadmin load, but on remote repositories.

The other major change is the addition of a client sqlite database for working copy meta-data caching. This should make for a good performance improvement for our large VersIC/SVN customers with large libraries.

Please keep us posted on your data-management exploits with SVN 1.7!

We recently had an article posted on EE Times discussing some innovation around data-management in the SoC space. The EE Times editor asked us for some background on how DM systems have evolved so we provided an overview. Unfortunately someone connected with a competitor started posting comments trying to undermine the article but thats OK.. It gave us a chance to discuss whats unique about our approach. The last comment was particularly important and sums up one of the major differences between our solution and the other tools in this space

IC Manage is a proprietary solution and the standard p4 clients just don’t work. Users are required to purchase artificial annual licenses instead of the standard 1-time cost of a Perforce permanent key and and to enforce that IC Manage has disabled the p4 command line interface, the p4v visual client, IDE access, etc.

The Methodics approach is to license our client applications on a standard Perforce database. Digital (Verilog) designers can use the standard Perforce interface which means they can work for $0 in the same depots as the Cadence designers on the project.

This is actually true of all of our competitors in the IC DM space. Their approach has been to ensure all DM database activity goes through their licensing activity and clients, including source code editing. This makes no sense to us at all, the Subversion and Perforce (and Git, and ClearCase etc) have best-in-class source-code development flows and clients that have been developed by the software community. Verilog designers should be using those tools to do their work, not something a niche hardware DM company has developed for them.. We should be leveraging the software community’s expertise and ecosystem for these kinds of files, they outnumber us by 1000-1 and their tools are usually free!

Hi, my name is Simon Butler and I’m the CEO of Methodics. I’ll be posting here on a regular basis bringing you news from Methodics and interesting updates in the SoC development space.