You’re frustrated and suddenly stalled on the freeway and what happens in larger organizations is chillingly clear: a chain-reaction crash that creates incredible chaos across the R&D group.

Missing Schedule

Part of the reason so many semiconductor projects miss schedule is that staffing levels are not aligned with the level of complexity that the design team needs to undertake. This is solvable problem.

Fact-based planning provides the team with data for decision-making—ensuring that projects are staffed properly to meet the demands of the design’s complexity. Estimates of design complexity, project-staffing requirements and development cycle time are generated using empirically calibrated models. This is the heart of Fact-based planning, which is used by top semiconductor companies across the industry.

Fact-based planning

• Eases the traditional tension between groups within the enterprise that struggle to communicate in different languages by guiding discussions and strategy with facts and data.
• Enables predictable revenue streams because it yields accurate schedule estimates, therefore there are no surprise shortfalls in revenue or margins.
• Leads to predictable schedules, which is crucial in an era when time to market is more important than ever, and companies can’t afford to miss the market upturn.
• Doesn’t replace bottom-up, detailed planning but complements it.

Boosting Productivity

Fact-based planning is essential to an important productivity boosting best practice: seeing the project execution pipeline clearly and managing it centrally. This best practice—and the tooling behind it—rolls up all project plans to generate a picture that shows the total resources consumed by all project plans. With this bird’s-eye view of all project plans, engineering managers can observe where there are shortfalls and over-subscriptions role by role, month by month. This becomes an essential tool for managing the pipeline.

This isn’t an airbag that protects you in a chain reaction crash. This is a radar system that prevents the crash in the first place and gets everyone to their destinations safely.

Originally published in EETimes http://www.eetimes.com/discussion/other/4205031/The-ripple-effect

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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-

Related posts:

1. Optimal Team Sizes for Chip Projects What’s the optimal team size for a given IC...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Sometimes the simple questions are the most vexing. That hit me this week while participating in a DesignCon panel in Santa Clara, moderated by EDN Executive Editor Ron Wilson.

The title seemed easy enough: “Getting to Design Quality Closure Without Compromising Productivity.”

But really, what IS quality? How do we define it?

My fellow panelist, Camille Kokozaki, president of Design Rivers, quipped “It’s like pornography: you know it when you see it.”

Piyush Sancheti, senior director of business development at Atrenta, came close:

“Quality is meeting the design objectives you have: whether it’s area, power, timing functionality, or, in a broader sense, customer expectations. Productivity is getting there.”

Sancheti then added:

“Being able to measure it (productivity) with tools like Numetrics is important because you want to hit your objectives as fast and effectively as possible.”

Not surprisingly, our panel wrestled with one of the big issues in design quality today: verification. It deeply affects design quality and productivity. Sancheti noted that for some teams, 70 percent of the entire design development is spent on verification.

What I see first hand from customers is they struggle to understand how verification affects their productivity. Some program managers I talk to say:

“I understand the scope of logic design and physical implementation. Verification is an unknown for me. If I give the verification team another two months, they’ll take it, but how do I know that we’re better off?”

So, I think we’re seeing that verification needs to come up with some sort of model of completion so people can move on. And that’s not easy. Our data shows that some companies toggle up the tape-outs as part of a larger verification strategy, but that can hurt overall productivity.

How we fix verification is a broader issue. Do we lean on formal methods at the architectural level as opposed to time- and engineering-consuming test vectors?

For now, our role is to help teams quantify their design effort, properly staff their projects, and understand where they stand with respect to the industry’s best teams. From there they can make fact-based decisions to drive productivity improvements.

That’s our contribution to the broader challenges of verification and design quality, but as we all know, it takes a village (and many future industry panels) to come up with the solution.

(Jeff is Numetrics’ director of professional services and product marketing).

Bright lights in a dimly lit DesignCon room: (L-R) Camille Kokozaki, Design Rivers; Piyush Sancheti, Atrenta; Jeff Eversmann, Numetrics; Michel Tabusse, Satin IP

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

By Andrea Fortunato

How best can we leverage IP in an era of relentlessly increasing design complexity? That was the question on the table at this week’s IP-ESC 2009 conference here in Grenoble. I was honored to sit on a panel with Jasper Design Automation CEO Kathryn Kranen and Olivier Haller, who manages the design verification team in the Functional Verification Group at STMicroelectronics.

Our CEO, Ron Collett, described the IP situation in a post last week as the design reuse paradox, in that re-using IP is harder than it looks. In fact, there are dangerous consequences for any project leaders who think it’ll be a cakewalk.

During the panel this week, I made the point that most teams underestimate the complexity that the reused IP— adapting a particular block to a new context or adding particular features and then validating it—will add to their project.

This miscalculation is particularly dangerous for derivative designs, whereby the reuse level of their blocks is expected to be significantly high. Executive management loves derivative designs because they’re operating under the assumption that most of the work has already been done on the original design and the derivatives will be easier and deliver higher margin.

Truth and Consequences

But the reality is teams use ever-more IP blocks (including complete functions and sub-systems) on a chip. Underestimating the complexity at the block level is compounded at the chip level, and this creates unrealistic performance expectations from the development teams.

What happens?

• The project schedule slips

• Team members have to be pulled from other on-going projects to bring the project to closure, throwing the predictability of schedule in those other projects into doubt.

What are the consequences?

• The overall market window is reduced and peak time window for product introduction is reduced

• Development cost increases, exploding the project’s initial budget. ROI window is reduced

• Both time to market and ROI are affected!

The ripple effect of underestimating the effort needed to develop, integrate and validate the IP is far-reaching: The resource disruptions delay key projects because resources already involved on other developments are pulled in to salvage one development. The ripples turn into waves that slam the schedule and cause budget over-runs for the whole the project pipeline.

Remediation

There are two major ways to address this situation.

First, fact-based planning at the project’s outset helps avoid this turmoil. By measuring and quantifying project complexity and schedule risk, team leaders can see the gap that might result between their initial effort assumptions and the effort they’ll actually need based on the data. This helps them make fact-backed what-if staffing simulations and create aggressive—yet achievable—schedules.

Second, pick your design battles carefully. Analyzing projects in our extensive industry database, we see that best-in-class design teams show a lower amount of reuse than the average of their segment. This means that those best-in-class projects re-use IP where it is most appropriate to do so—for example in standard functions that don’t bring value add and real differentiation to the final product. But, best-in-class companies leverage their own innovation and fully engage their engineering resources in situations where the performances of specific functions are the key differentiating factors from the competition.

In the end, the key challenge for an IP user is :”Keep the ROI in the Product Development!”

(Andrea Fortunato is director of professional services for Numetrics, based in Grenoble).

Related posts:

1. The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

Related posts brought to you by Yet Another Related Posts Plugin.