During the next five years, a great many semiconductor companies will be faced with an increasing number of underperforming business units. Chances are they’ll be selling or spinning them off. Some chip companies, large and small, will disappear altogether. Why? [More]

When planning new IC design projects, such as SoCs or complex analog or RF chips, R&D organizations that have a firm grasp on the complexity of implementing the design wield a powerful competitive advantage. Complexity is a measure of engineering difficulty and provides the foundation for reliably estimating engineering resource requirements and development cycle time for projects, which is the essence of good project planning. Can anyone disagree that consistently reliable project plans, which means projects finish on-time and within budget, translate to higher revenue and profits? But how does one get an accurate, quantitative calculation of design complexity? [More]

By Ron Collett

“We must increase our IC development productivity!” is the persistent invocation from semiconductor industry executives, and it’s getting louder by the day.  It’s not surprising. Yet when I ask the question, “What do you mean by productivity?,”  executives and R&D managers often give vague answers.  Few seem to have a firm grasp of the definition, other than saying “we need to finish projects on schedule, reduce development cycle times and use fewer engineers.” As a characterization of the benefits of boosting productivity, it’s not a bad start.  

It reminds me of U.S. Supreme Court Justice Potter Stewart’s comment in a landmark First Amendment case in which he described the challenge of defining pornography: “Pornography is hard to define, but I know it when I see it.”  Maybe semiconductor executives are saying the same thing: “Increased productivity is hard to define, but I know it when I see it.” Justice Stewart subsequently recanted, concluding that pornography can be indeed defined. So too can productivity. [More]

Is IC design productivity rising or falling? It’s a question on the minds of semiconductor executives and R&D managers throughout the industry. The answer depends on whether we view it in absolute versus relative terms. Both have merit. In absolute terms it’s rising, but in relative terms it’s falling.

A “relative” measurement compares changes in productivity to changes in design complexity: How much is productivity increasing compared to the increase in design complexity? Through that lens, productivity is falling, and recently the decline has become steeper. How do I know? [More]

By Ron Collett

From the business perspective of a semiconductor company, Numetrics’ solutions are about making substantial improvements in chip development productivity and schedule predictability. But just what is productivity, and how do you first characterize it and then improve it? What’s the outcome?

Productivity drives development throughput in your R&D organization – the higher the productivity, the greater the throughput. And throughput is a measure of how much product the engineering organization churns out during a given period of time.

There are three ways to boost R&D throughput:

• Add headcount
• Increase work-hours per week
• Raise utilization and productivity

The first two have downside: Raising R&D headcount increases cost, and more hours lead to workforce burnout and high turnover.

The only viable long-term strategies for sustaining high throughput are to increase engineering utilization and productivity.

Utilization

Increasing R&D utilization—the percentage of the engineering workforce’s effort spent on revenue-generating activities—is among the quickest and most effective ways to boost throughput. That’s because it essentially increases R&D resources without incurring additional cost.

Organizations struggling with low utilization find their engineers spend more than half their time on non-revenue-generating activities, such as sales, customer support, and product support – all of which should be handled by different groups. In large companies, that means millions of dollars a year are being squandered.

Engineering organizations in best-in-class companies, however, spend 73 percent of their engineering time on activities that generate revenue and create persistent value. By shrinking the amount of time engineers spend on projects that get cancelled, non-core research, myriad internal initiatives, and so forth, companies can significantly raise their utilization rates and, in the process, reduce R&D spending and/or develop new revenue-generating products.

Productivity

 Productivity – the second factor driving throughput – is the amount of engineering output per unit of labor expended to create that output. Productivity is a function of efficiency. Only by improving efficiency will productivity rise. Analysis of R&D efficiency compares the effort a particular set of engineering tasks should consume to what they actually consume. Reducing the effort needed to complete a set of tasks raises efficiency, which increases productivity, and this gives rise to higher throughput.

Boosting productivity requires a reliable measurement system–one yielding accurate baselines and fair comparisons. Additionally, a robust measurement system paves the way for managers to determine the absolute minimum staffing projects need to finish on time. At that point, the projects are “optimally understaffed,” which means the projects can be staffed to levels that assume the teams will meet an improved productivity level.

And there’s where best-in-class companies are pushing the productivity envelope.

Originally published in EE Times http://www.eetimes.com/discussion/other/4201131/How-productive-is-your-R-D-organization-

By Jeffrey Eversmann
After two years of doom and gloom, it’s refreshing to attend an industry event and hear talk of innovation—at all levels. That was the atmosphere at a recent GSA Silicon Series luncheon I attended in Austin, Texas, that featured a panel discussion on blurring technology lines.

At the application-segment level, Patrick Moorhead, marketing vice president with AMD, joked:

“I’ve been hearing that the desktop market is dying for the past 15 years.”

He made that quip after holding up the “4th screen” examples he had brought with him: an iPad and a Sony eBook reader. “Only 5-10% of consumers back up their data, so a fixed device will always be in the home,” Moorhead said.

I agree. While I like the professional security that a proliferation of leading-edge microprocessors brings, I am burdened by the yearly upgrade rotation I am now on to keep current the six-plus PCs in my home. All of us in the semiconductor industry have been through multiple iterations of the tablet device, some of them from Apple. As was often said by the panel, “it’s not an either-or these days.”

Fellow panelist Naveed Sherwani, CEO of Open-Silicon, Inc., added “the new form factor will succeed if it is useful.” So, panelists agreed that the iPad is not a desktop (or even laptop) killer. The question is: Will the average consumer add yet another device to the list of electronic gadgets we carry around each day?

The panel shifted to the technology level and wrestled with an intriguing question: Will ARM replace x86 in the desktop or will x86 replace ARM in the SoC market? While some in the audience checked email on their smartphones, Sandeep Shah, director of marketing and applications at Marvell Semiconductor, Inc., and Sherwani tackled the question.

Shah argued that an “ARM architecture licensee can bring together the best of both worlds.” (This is a very interesting perspective in light of Apple’s recent purchase of Intrinsity, which worked with Samsung to develop the ARM Cortex-based A4 processor.)

Shifting processor sands

Sherwani was quick to add that while there really hasn’t been an attempt by x86 to take over SoC design, that doesn’t mean an attempt isn’t brewing:

“In the next three years or so, things will get more competitive and more intense, when x86 is available for SoC development.”

Then it was time to move on to another much-discussed technology challenge, low power design. The panel members pulled out their different battery-powered devices and rattled off the actual vs. published battery life. “What we really need is more disclosure, a ‘truth-in-battery-life’ from silicon providers,” Moorhead said.

Shah, who probably lives power issues on a daily basis, talked about how the different Blackberry models used different chips from Marvell to get different power performance in the system. Marvell focuses on both system-level and gate-level approaches to power management. Sherwani wrapped things up from a design perspective saying “we have just scratched the surface on lower power design.” Maybe what we need is a Moore’s Law for low power design – something that will challenge engineers to do things that today are viewed as impossible.

All in all, the GSA luncheon was a great opportunity to re-connect with fellow semiconductor engineers. We exchanged cards with the same cell phone numbers, but with new company names, new titles, and new addresses. We talked about how tough things have been but how happy we are to be traveling less and spending more time with our families.

It felt like the calm before the innovation storm. I don’t know about you, but I’m here and getting ready for it.

By Ron Collett

It’s a common refrain, and I heard it this week at the IEEE VLSI Test Symposium in Santa Cruz: Moore’s Law is increasingly difficult to obey. We see evidence of this perception everywhere:

• Manufacturing costs are soaring: A fab that cost $2.5 billion to construction at 90 nm now costs $6 billion at the 22 nm node. So companies are selling off their fabs and losing what was once a huge competitive differentiation for them. Their primary differentiation is increasing their product-development capability.
• System-on-Chip (SOC) development costs run anywhere from $50 million to $100 million per project. A dwindling number of markets can support the ROI that type of investment demands.

This increasing risk has significantly cooled VC investment in our industry. In 2000, venture capitalists invested nearly $4 billion in semiconductor companies; last year, it was $771 million.

This means that to be successful in 2010 and beyond, semiconductor companies must “do Moore” with less. That requires a focus on product-development capability. How do you transform your product-development organization into a world-class team?

Here are some best practices:

• Start with an integrated framework of product-development capabilities. We, with our partners, the global operational-strategy consulting firm PRTM, counsel such a framework to improve product and cycle-time excellence. It’s remarkable how few companies have this kind of framework, but, implemented correctly, it translates into a capability to improve your overall maturity. And the more mature your product-development maturity, the faster you’ll see revenue growth.
• Optimize your R&D footprint. No one builds an SoC at a single site any more. An integrated approach to R&D management is key to taking advantage of synergies and scaling opportunities.
• Extend your enterprise: The cost of development is so high, it’s no longer possible to develop everything in house. Establishing relationships with other companies and with universities is becoming essential.

In an era of doing more with less, these best practices can help semiconductor companies “do Moore” with less, widen their competitive differentiation and increase revenues and profits.

By Steven Gary

What keeps people in our industry up at night? If you joined us at the DVCon Industry Leaders panel, moderated by engineer and blogger JL Gray (Cool Verification blog), you heard at least four things:

• We’re struggling to manage the growing complexity
• New tools and IP reuse are not sufficient
• Training next-generation engineers is lacking
• Metrics are needed

Distilling all four, at least to me, yielded a single, fundamental question: How do we as an industry get more productive? Is it the right high-level language? The hot new verification methodology?

Our panel (L-R) John Goodenough, Victor Melamed, Sheela Pillia, Steven Gary, and Jim Crocker (Photo by Joe Hupcey, Cadence Design Systems)

John Goodenough, Worldwide Director Design Technology, ARM, (far left in photo) answered the question with a question:

“How many designers do I have to deploy, train and how do I build this?”

Goodenough said asking about methodology is the wrong question. Asking about workflow is the right question because that’s what affects cost and schedule.

He noted that at ARM, “We’ve stopped talking about interoperability, and we’re now talking about enablement.”

So how does the adoption of new technologies and methods affect your project? How do you figure that out? I noted that engineers are conservative by nature but must push to reach the next level.  After adopting new tools and methodologies, they need a way to quantify how that affects productivity or adds risk to their development schedules.

John said:

“You can’t fix anything you can’t measure, so you have to measure it. It’s hard to measure things; it’s hard to measure intangible things, but you have to take a crack at it.”

Once you begin to measure things, you start to start to see the true workload costs. For example, the industry generally has very high expectations that design reuse will improve productivity simply because those blocks don’t have to be designed from scratch. Yet we’ve measured that and found that below a certain level of design data reuse on an IP block (around 50 percent), the savings from reuse rapidly approach zero. At very low levels, it can cost more to reuse an ip block than to design one from scratch. (We blogged about this paradox last fall: The Design Reuse Paradox).

In the end, it was clear that design and verification today is an enormously complex challenge—from fellow panelist Sheela Pillai’s task at AMD driving complex mixed-signal IP development or Victor Melamed at Ambarella trying to help his colleagues figure out the most effective high-level design language to choose or Jim Crocker from Paradigm Works grappling with engineering training. Quantifying those challenges is the first step toward predictable project outcomes and boosting the industry’s productivity—and getting a good night’s sleep.

P.S. To read more about the panel, please check out Cadence blogger Richard Goering’s post, another interesting perspective that’s definitely worth your time.

By Ron Collett

We’re gearing up for DVCon (Feb. 22-25) in San Jose and not just because we’re participating in a panel. DVCon (on Twitter, @dvCon), which has emerged as a increasingly important event in recent years, features as keynoter Cadence CEO Lip-bu Tan. His topic gives a new voice to the mounting productivity crisis in semiconductor and system design.

According to an abstract of his talk:

“…the industry must approach the product development process much differently. The classic ‘brute force’ methods cannot scale to support the complexity of today’s SoCs and Systems. These traditional methods result in mounting costs and unpredictable schedules that are detrimental to profitability.”

• Cadence approaches the problem by giving engineers (among many other things) design exploration options that speed the implementation of the physical architecture of a chip.

• Numetrics approaches the problem by helping teams quantify the complexity of their design effort and build reliable project and staffing plans. This is crucial in an era where most IC projects slip schedule significantly.

Our vice president of professional services, Steve Gary, will speak on a panel just after Tan’s, titled “What Keeps You Up at Night?” It’s moderated by JL Gray from Verilabs, who writes the excellent Cool Verification blog; he’s posted a panel preview this week.  Also in the conversation will be John Goodenough from ARM Ltd., Sheela Pillai of Advanced Micro Devices, Inc., Jim Crocker from Paradigm Works, Inc. and Victor Melamed from Ambarella.

There are plenty of things keeping the industry up at night, but I think we’ll hear a lot of excellent ways to overcome the sleeplessness and drive productivity—and the industry—to the next level. Hope to see you there.

(Summary: The recently published book “The Checklist Manifesto” holds important lessons for how semiconductor and embedded systems design teams can improve their product-development productivity.)

“The complexity of what we have to deliver on exceeds our abilities as experts partly because the volume of knowledge has exceeded what training can possible provide an expert.”

By Ron Collett

That’s how Atul Gawande, author of “The Checklist Manifesto,” sets up the problem during a podcast interview with Harvard IdeaCast. Gawande is a surgeon and a staff writer for The New Yorker magazine who looks at our ability to be productive in complex situations. His interest, of course, is improving surgical outcomes.
There are, he says, 6,000 drugs and 4,000 medical procedures and increasingly specialized doctors and nurses. We’ve all read stories where surgical implements get left behind in the patient’s body.

I was fascinated by how relevant this is to semiconductor and embedded design. Teams of varying sizes are pulled together on a regular basis—digital specialists, memory specialists, analog designers, software engineers. They’re asked to build increasingly complex systems, with tighter market opportunities, and, like surgery, they find it nearly impossible to plan for the unexpected.

Process, not check marks

Gawande’s checklist approach isn’t about ticking off boxes per se. In the operating room, Gawande devised a two-minute checklist that builds in pauses during surgery to make sure that tasks have been accomplished, that blood is still on hand, and so forth. Perhaps most astonishingly, before the first incision is made, the team takes time to introduce each other by name, so everyone knows everyone else and their expertise and the goal of the operation.

He cites a study done by Geoffrey Smart, who studied decision making among venture capitalists. He compared outcomes of those VCs who, in choosing a entrepreneur, went with their gut (the “art critics”) and those who employed a checklist approach in their selection process (the “airline captains”).

Those who used the checklist approach had far fewer regrets about their selection of managers, and their investments had higher returns.

But the vast majority of VCs are “art critics,” relying on their instincts and experience, rather than the more successful approach.

In system design, many managers rely on their instincts at the beginning of product development to assess how much staff they’ll need and how long the project will take. Clearly something’s wrong because more than 80 percent of semiconductor projects slip schedule.

Learning from the past

It doesn’t have to be this way. Gawande points out that some in the investment banking community rigorously study past investments to understand where failed investments went awry. Sometimes that education leads to adding a check for their next investment checklist: “read all foot notes in the prospectus,” for example.

Successful system-design teams, whether in name or spirit, use similar approaches, and they start with benchmarking themselves against the industry or their own past efforts to understand how to approach their latest product development.

As Gawande implies, it’s often the simplest approaches—and, I’d add, approaches based on facts rather than instinct—that work most effectively.