By Ron Collett

In December, we were honored to participate in a Design & Reuse panel in Grenoble, France, titled “IP Reuse vs. IP Leverage: What’s the difference and what are the issues?”

Andrea Fortunato, our European director of professional services, represented us and gave an overview of the particular challenges that design reuse brings. He blogged about it right after the panel (Design Reuse: It’s Harder Than it Looks).

Our friends at D&R have just posted an audio Webinar of that panel. It’s definitely worth a listen if you’re designing with cores and trying to take advantage of reusability.

Have you had design reuse challenges recently? If so, feel free to comment on this post to let us know what they were and how you overcame them. Improving productivity in the semiconductor industry is a communal effort!

By Ron Collett

The concept seems simple: The more ip blocks you re-use in an IC or system design, the faster and more productively you’ll get your design done. The ITRS roadmap began identifying the benefits as long ago as 1997, showing the industry could reasonably expect 56,000 gates per designer per year when using large ip blocks (75,000-1 million gates). By 2007 that figure was up to 600,000 gates per designer per year, a tenfold increase.

There’s no doubt design reuse is here to stay. In 2007, a third of all logic was reused design blocks. That’s expected to rise to nearly 50 percent by 2015, according to the ITRS.

The numbers and the theory behind it are encouraging, but reality is much different. Making 30 percent of your design from reused IP blocks doesn’t mean you’re going to be 30 percent more productive at the end of the project. That’s because IC design teams tend to underestimate the work needed to implement the reused IP. This can cause project delays and missed market opportunities.

The challenge is that it’s very difficult to estimate design complexity, especially the impact of reuse. IC design schedules can falter because of the inability to estimate the impact of IP modifications on project effort.

Even a small percentage of reuse can add outsized effort to a development project. For example, if you add one new block of 600,000 gates to a 6 million-gate design, you’re adding 10 percent to the IC but increasing the effort required on the project by 24 percent. Adding 10 percent new circuitry to all blocks in that 6 million-gate design—with 90 percent of each block being re-used—doubles the effort required on the project, even though it increases the IC size by just 10 percent to 6.6 million gates.

This issue will be part of a larger discussion Dec. 1 at IP-ESC 2009 in Grenoble. We were invited to sit on a panel—“IP Reuse vs. IP Leverage: What’s the difference, and what are the issues?”—with Kathryn Kranen, CEO of Jasper Design Automation, and Olivier Haller, who manages the design verification team in the Functional Verification Group at STMicroelectronics. Our director of professional services, Andrea Fortunato, will represent Numetrics.

This is a well-timed panel in my opinion because re-use is an issue that transcends the industry and is crucial for its future. And how we go about optimizing design re-use is crucial to manage today.

(Summary: A clever YouTube video highlights how communications disconnects can prompt IC product-development projects to slip schedule).

By Ron Collett

We talk a lot about schedule predictability and maximizing IC design throughput. That’s what we do as part of our goal to help product-development teams improve productivity and ROI. But there’s another, more subtle goal, and that’s improving engineering communications and expectations.

Engineers will work most productively when given an aggressive schedule if they know it to be realistic because it’s rooted in fact-based planning. With unrealistic schedule assumptions, the reaction is “been there, done that,” and productivity—and ultimately morale—suffers.

This dynamic is vibrantly illustrated in a YouTube video inspired and narrated by Jasper Design Automation CEO Kathryn Kranen, called How Engineers Communicate: A Video Parody.

In it, the mythical company WonderChips is planning its T-1000 communications device. The video takes us through the planning process, the assumptions and most importantly the communications disconnects engineers and executives encounter along the way.

To summarize the story line:

• In the beginning, Rakesh determines that the T-1000 device is four times more complex than its predecessor and therefore a new EDA tool is needed to speed this project to completion on schedule. His boss, however, rejects the investment.

• Next, the T-1000 team grabs a conference room to begin its bottom-up planning approach, fueled by chips and soda and catered food. Hours go by, punctuated by arguments over how long certain blocks will take to design.

• Eventually, the team leader seems satisfied. She tells the group, “Assuming all these assumptions hold, I think the schedule looks really good.” The team agrees, and the leader goes off to present the schedule to executive management.

• Later, she returns to the team with good news and bad news: The good news is the executive staff loves the feature set. Bad news is the T-800, another project, is slipping schedule, and there’s competitive pressure in the market. So the executives want the T-1000 to sample months sooner than the team’s bottom-up plan called for. Oh, and they need to beef up the memory subsystem while they’re at it.

Says the team leader: “I know as a team we can do this. You guys with me?”

The team groans. As the engineers exit the conference room, shaking their heads in disbelief, one engineer murmurs: “It will be done when it is done.”

The T-1000 ends up slipping by at more than six months, and the executive who turned down the tool investment demands tape out at any cost.

From my perspective, WonderChips would have benefited by complementing its bottom-up scheduling approach with a top-down methodology—using quantified estimates of the chip’s complexity, the team’s productivity and a model of the rate at which effort will be expended on the project.

It would have helped engineers and management communicate in a common language and build an aggressive yet achievable schedule. And it would saved WonderChips’ management from having to extend the on-site day care closing time to midnight to get the chip done.