Numetrics » Schedule Predictability

End of the Free Ride

Ron Collett — Tue, 25 Oct 2011 00:31:10 +0000

According to Pagemill Partners, a well-known Silicon Valley venture capital (VC) firm, the number of semiconductor companies spawned with VC funding has been steadily declining for nearly a decade. In 2003, VCs gave life to 63 new chip companies. Last year the number was 13. It’s a trend that promises to reshape the semiconductor industry. (Note: the figures reflect companies formed in North America, Europe and Israel.)

Established chip companies planning to expand via acquisitions should take notice. Fewer start-ups mean two things will likely happen. First, a feeding frenzy will ensue for the handful of hot start-ups demonstrating impending dominance in their respective markets. Second, limited supply of these successful upstarts will force would-be suitors to rely more heavily on their own R&D organizations for new product development and revenue growth.

The problem with relying on internal R&D is that many executives will learn the hard way that their development organizations are not up to the task. They’ll discover R&D initiatives plagued by low R&D productivity, poor schedule predictability and missed market windows. Division by division, these groups probably will be shuttered or sold off to bargain hunters.

VCs are turning away from semiconductor investments because the return-on-investment (ROI) simply isn’t what it once was. Buyers won’t pay the risk-adjusted price premiums VCs demand. Today, some VCs claim their investments are nothing more than R&D subsidies for established semiconductor companies—and the free ride is over.

Imbalance in the ROI equation stems from the increasing investment necessary to develop complex chips—upwards of $100 million for a system-on-chip IC. For investors to part with that amount of cash, they must see a clear path to a $500 million to $700 million liquidity event. Buyers are loath to pay those prices in all but a few cases. That’s because they don’t think they can extract the requisite sales revenue from the end market to justify the purchase price—often due to cut-throat competition, which is pushing down revenue and margins faster than ever before.

On the other hand, buyers do seem willing to pay $150 million to $250 million for winning start-ups, which means that if VCs serve up companies whose cumulative investment is $30 million to $40 million, we’ll see a steady stream of win-win deals. Toward this end, VC’s are funding specialty chip companies that require substantially less capital, such as those developing analog, RF and mixed-signal chips.

VC firms raising exceptionally large investment funds will probably sideline themselves from the semiconductor game—$30 million to $40 million investments are usually too small for them to justify, especially since the investment is often divided among several firms. But that simply means smaller VC funds will take up the slack.

Another path investors will surely pursue is off-shoring R&D to lower cost geographies, where the size and quality of the labor force has been growing during the past decade. This will reduce start-up costs by 25 percent to 50 percent, or even more. But it will be quite a while before the supply and demand for these offshore-based start-ups comes into balance. Between now and then, semiconductor companies will need to rely heavily on their own R&D organizations.

Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4229889/End-of-the-free-ride#

Death of the SoC Rumors of the SoC’s impending death have been popping...

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

The Realities of IP Reuse

Ron Collett — Wed, 24 Aug 2011 21:22:55 +0000

Long touted as a silver bullet, IP reuse often fails to live up to expectations when it comes to increasing semiconductor R&D productivity and throughput . That’s because most IC development teams fail to recognize a critical non-linear relationship exists between the amount of circuitry they modify or “improve” in pre-existing IP blocks and the effort the engineering team expends in making those modified blocks operate properly in the target IC. Bottom line: small changes can have a disproportionate impact on project effort. Not being fully cognizant of the specifics of this non-linear behavior is a common trap into which myriad engineering teams unwittingly fall.

Conventional thinking, for example, might presume that modifying a mere 20 percent to 30 percent of a block translates into a relatively modest amount of engineering effort, compared to the effort the team would expend if creating that block from scratch. After all, most of the block remains untouched, has already been verified and perhaps even implemented in silicon. But therein lies the rub. Because of the non-linear relationship, the 20 to 30 percent change (or even less) often translates to engineering effort far in excess of what the project team anticipates.

Frequently, the additional effort is significant. For instance, when teams modify upwards of 40 percent or 50 percent of a block, the total effort expended to make the block work in the target IC can be equivalent to designing it from scratch.

Yet the biggest problem is not the additional effort, but rather it’s that it’s unexpected, which is a common root cause of schedule slip and poor predictability , as well as low R&D productivity. It’s an insidious problem that often disrupts the entire project development pipeline, as resources fail to roll in a timely manner from one project to the next.

Each family of circuit blocks has a unique set of non-linear reuse curves—analog, RF, logic, processor, memory, etc.—and the curves vary with respect to whether the particular IP is hard or soft and the amount of its verification suite reused. When teams apply the curves during the project’s planning phase, the impact can be tremendous: dramatically reduced schedule slip, greatly improved predictability and noticeable productivity gains, all of which go right to the financial bottom line.

Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4218842/The-realities-of-IP-reuse

Comments

AlPothoof

8/17/2011 6:26 PM EDT

The numbers I have seen in the software industry indicate that if you need to modify as little as 25% of the code, you are ahead to start from scratch; the modifications will take longer and cost more.

John.Gyurek_#2

8/18/2011 9:35 AM EDT

All true but the real point here is that if you don’t have a well defined need with standard or well defined I/O that does NOT require modification you are shopping in the wrong aisle. Design reuse is different than integrating an IP block. An experianced project manager should know the difference and schedule accordingly.

Duane Benson

8/18/2011 11:58 AM EDT

I don’t think the software industry gets enough credit in this regard. Consider that language and OS libraries are really just code reuse. If each developer had to hand code all of the functionality that lives in libraries, then we could say that IP reuse doesn’t really exist.

As it is, we’re typically only looking at the in-house coding and ignoring all of the externally developed code.

ndancer

8/18/2011 3:28 PM EDT

I stole this from somewhere – don’t remember where … sometimes, the best IP reuse is to recover the disk space …

Death of the SoC Rumors of the SoC’s impending death have been popping...
In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...

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

Death of the SoC

Ron Collett — Thu, 12 May 2011 21:20:11 +0000

Rumors of the SoC’s impending death have been popping up in the semiconductor and systems industries. Are they exaggerated? Not entirely. A decreasing number of companies are investing in system-on-chips (SoCs). Likewise, the number of concurrent SoC projects that typical R&D organizations can undertake is shrinking. The reason: soaring design cost and poor schedule predictability .That makes SoC development increasingly difficult to justify. But does this foreshadow the SoC’s complete demise? I doubt it, but these factors will surely chase more players from the market and drive greater use of alternative solutions.

A look inside the venture capital community reveals a bellwether of the trend. During the past five years, a declining number of firms have shown interest in investing in SoC start-ups (although a lot of money has poured into programmable devices aiming to unseat Xilinx and Altera). Only when the SoC’s risks can be significantly mitigated and revenue projections credibly defended will investors even consider the opportunity. Even then, it’s a tough sell.

Up until a few years ago, a customer of mine (chip company) routinely had six or seven concurrent SoC projects underway. Today, the number is a mere three, with a combined development cost of is $150 million to $200 million. To justify the investment, the three products must garner more than a billion dollars in sales revenue. The company has a good chance of meeting its targets, because it consistently hits its development schedules, but there is no guarantee that the expected volumes will fully materialize. In other words, even with best-in-class R&D execution a nd predictability, market uncertainty makes it a risky bet.

Systems companies developing their own chips (ASICs) encountered a similar situation starting in the second half of the 1990s. High cost, complexity and risk made ASIC development prohibitive except among those whose end-products boasted high profit margins and volume. The requirement persists today. Not surprisingly, many systems houses still developing their own ASICs struggle to rationalize the cost, especially those with poor schedule predictability.

Engineering labor consumes much of the SoC’s development cost—team sizes typically range from 100 to 200 engineers. Such large teams result directly from the inability of R&D productivity to keep pace with growing design complexity. Simply put, to offset falling relative-productivity, more engineers are needed to achieve the throughput required to meet time-to-market constraints. More engineers means higher cost–although many companies attempt to reduce costs by off-shoring development.

Cost mitigation tactics notwithstanding, I suspect that we will continue witnessing the decline of the (dedicated) SoC, except among those companies boasting both market vision and consistent R&D excellence, which means delivering high-margin product on-time and within budget to high volume markets.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4215872/Death-of-the-SoC#

Comments

resistion

5/10/2011 1:57 PM EDT

Only large established companies who strive for chip supply chain independence will continue SoC development.

daleste

5/11/2011 11:03 PM EDT

Good article Ronald. I agree with what you wrote. During the 80’s and 90’s we were able to build custom devices for large customers. We needed at least $1M revenue to start a design. As the process continues to shrink, the design and development costs have gone up too much for customers to bear. Unless the system can’t be built any other way, it is not likely that a custom SOC is warranted. Most IDE’s are building catalog SOC’s with broad market appeal. The only way to get enough volume to reach break even is to have multiple customers in multiple markets. That’s for large SOCs. I do think there are still many opportunities for smaller devices especially analog and mixed signal.

nosubject

5/12/2011 10:28 AM EDT

“Today, the number is a mere three, with a combined development cost of is $150 million to $200 million.”

How to get the estimation of $150~200M development cost?
The cost of 100~200 engineers per year is about $20~30M. Beyond that, the major costs are IP cost, license cost, fab and tools. Are those costs more than 80% of the SOC development cost? (150M-30M)/150M = 80%.

RCollett

5/12/2011 5:20 PM EDT

SoC development cycles are typically around two years, so the $20M to $30M labor cost needs to be doubled.

nosubject

5/12/2011 7:40 PM EDT

But SOC developments are pipelined. At the end of the 2nd year, the 1st SoC is validated and into the production; the 4th SoC is in design; the 2nd and 3rd SoC are in verification and bringup.

2years development cycle cannot justify the high labor cost. Instead, because of the design pipeline, the labor cost is lower than the $20~30M I put there.

Raul Lopez

5/16/2011 12:09 PM EDT

Unfortunately the pipeline seldom happens with such efficiency. Design engineers are often tied up in documentation, SW bring-up, early-access customer bugs and other less-than-ideal tasks for at least two quarters after tapeout.

NickLethaby

5/12/2011 9:14 PM EDT

Don’t forget about the software. Typically customers are expecting Linux, Android, and WinCE ports along with some RTOS ports as well. With today’s SoCs having 30 or more peripherals, including graphics, multimedia, and protocol accelerators that need to integrated into hihger level stacks, you often need dozens of SW engineers as well. Furthermore with the semiconductor-supplied software now running into tens or hundreds of megabytes, the application support burden becomes significant as well.

cliffnotes

5/14/2011 4:21 PM EDT

The way to solve the problem is automation. Why use a shovel when you can use a bulldozer? www.analograils.com/why

resistion

5/14/2011 7:40 PM EDT

The problem seems to be customization rather than SoC. SiP wouldn’t solve the problem either.

chipdude

5/16/2011 11:12 AM EDT

Perhaps 3D IC technology will improve the productivity, reduce costs, and still allow for high levels of functionality. It looks very promising.

Raul Lopez

5/16/2011 12:15 PM EDT

I agree with Ron in the decrease of SoC tapeouts. In the video ASIC industry there is a strong consolidation going on that is going to increase as Intel, AMD and NVIDIA add more HW-accelerated support for video codecs and video processing.

rickclucas

5/16/2011 6:54 PM EDT

Another major factor is that SOCs have not really been complete Systems, only large chunks, as time moves on we are seeing higher levels of integration therfore reducing the number of SOCs in an actual system, eventually we will have only one per system with as much of the other componets part of it as well.

In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...
The Elephant in the Corner Why do so many IC design teams commit to development...

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

The Politics of Productivity

Ron Collett — Wed, 30 Mar 2011 22:22:25 +0000

Politics and productivity seem to go hand-in-hand in semiconductor R&D organizations. Perhaps it’s natural. No manager or project team wants the low productivity Scarlet Letter. So it’s hardly surprising that ostensibly poor performers use politics to avoid scrutiny.

But are these so-called low productivity projects really poor performers? In fact, many are not. Quite the opposite in fact—they often have high productivity (although insufficient throughput) but are mistakenly pigeonholed because their crime was a missed schedule. Moreover, schedule overrun usually is not due to low productivity.

Instead, it usually stems from an unrealistic project plan—one in which the allocated staffing is not commensurate with the chip’s design complexity, project schedule constraints, and project uncertainties such as spec stability, new mfg. process, EDA tools, etc.

In my experience, unrealistic plans trace their roots to the organization’s executive ranks. Senior management promotes a culture of over-commitment in which R&D takes on significantly more projects than it realistically can handle. The consequence is obvious and ubiquitous: most projects in the portfolio are resource-starved.

It’s an all-too-familiar story: Projects are inadequately resourced, whereupon they miss schedule, senior management thinks the culprit was low productivity, the team runs for cover. Sound familiar? Of course, executive management has no proof to support its (often unspoken but implied) “lousy team” hypothesis, but likewise the team has few facts and little data to defend itself. Who wins that battle? As the story repeats, the organization gets steeped in the art of productivity politics, including subterfuge, avoidance of scrutiny and measurement, and internecine feuds that stems from finger-pointing.

The great irony is that measuring productivity preempts much of its politics. That’s because measurement gives project managers the data they need to prove projects are woefully understaffed and is the root cause of schedule slip, not poor productivity. When managers argue cases using facts and data, they can do so persuasively, often receiving additional resources for their trouble—at least enough to give them a fighting chance to finish within tight schedule targets. They rarely get all the resources they need, forcing them to boost productivity by ten percent or even more. But they’re motivated to go the extra mile—doesn’t management want that?

Executives win when they make wise staffing decisions—they get dramatically improved on-time schedule performance. Likewise, measuring productivity ensures R&D performance improves at a competitive rate. It also yields the facts and data to ensure future projects get staffed (reasonably) properly, and this preempts or at least mitigates the politics of productivity.

Originally published at http://www.eetimes.com/electronics-blogs/other/4214604/The-politics-of-productivity

No related posts.

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

R&D Predictability: The Path to Profitability

Ron Collett — Wed, 26 Jan 2011 19:32:32 +0000

Poor schedule predictability of IC development projects is the Achilles heel of semiconductor companies. It manifests itself as high schedule slip and is among the most important R&D metrics, measuring how well project schedules reflect reality. Most don’t.

Companies traditionally view schedule slip not as a result of faulty project plans, but rather as a consequence of unforeseeable perturbations occurring during the development process. The picture is incomplete and inaccurate. Slip must also be viewed through the project planning lens, because many events labeled as unforeseeable can be fully contemplated in the project plan with proper modeling. The payoff is big—reliable plans, which is the path to profitability.

Predictability and schedule slip are two sides of the same coin. Schedule predictability measures schedule overrun by comparing a project’s original planned duration to its actual duration, expressing the difference as a percentage of the original. The original planned schedule is the first one formally defined and officially disseminated.

What qualifies as low versus high slip in the semiconductor industry? Low is 10 percent or less. High is more than 25 percent.

Poor schedule predictability is an insidious problem that eats away at a company’s competitiveness, especially when it becomes fully baked into the organization’s culture as a tolerated practice. At that point, it’s just a matter of time before the company or business line disintegrates. Today many semiconductor organizations are taking action to vanquish slip. Those ignoring it do so at their peril. I doubt they’ll be around five years from now.

Excuses abound during post mortem assessments of projects that slip schedule. Naturally, the usual culprits are speciously defended as wholly unforeseeable. They include spec changes, EDA tool and library problems, IP and software delays, personnel issues, etc. But what project doesn’t encounter some or perhaps all of these and more? It’s disingenuous to expect that any particular project will escape the stochastic nature of chip development, so therefore it must be built into the plan—without the use of schedule buffers at every turn.

I reject the notion that IC projects are predictably unpredictable. I can point to myriad organizations that have excellent predictability. These groups deploy best practices and tools that use facts and data to ensure project plans fully contemplate the stochastic nature of IC development and “unforeseeable” events.

Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4212477/R-D-predictability–The-path-to-profitability

Comments

Dan Patterson

1/25/2011 9:46 AM EST

Great article. CPM schedules are inherently challenging as the forecasting tool of choice for development type projects. Due to the high degree of uncertainty and iterative work/re-work, traditional CPM Gantt chart type forecasting rarely gives an accurate picture – hence the frequent perception that the project finished late – i would suggest that instead, we simply didn’t plan accurately enough. Worse, given projects teams are aware of this shortcoming, the original ‘plan on the wall’ simply becomes a static picture that doesn’t reflect the latest updates, changes and impacts due to risk. An alternate approach is to create a risk-adjusted schedule using a combination of a CPM schedule (e.g. MS Project) combined with a project’s risk register and model the impact of the latter on the former using Monte Carlo analysis. Not only does this approach give more realistic forecasts, it is also a means of getting team buy-in into the agreed upon plan. I agree with the author that these projects are indeed predictable; we simply need to do a better job of including the non-deterministic work/outcomes in the original plan/schedule. More thoughts on this at http://goo.gl/KQTuz

markgrizz

1/25/2011 12:18 PM EST

You’ve stated the obvious, this reads like an advertisement.

RCollett

1/25/2011 9:37 PM EST

@Markgrizz,

It is definitely obvious — but remarkably, a great many semiconductor organizations don’t understand it. As for an advertisement, you are again correct — it is an advertisement to think differently about schedule predictability.

Rgds,

Ron

RCollett

1/25/2011 9:56 PM EST

@new2coding,

Well stated — it is all about company culture. Politics and project planning often go hand-in-hand, because the project planning phase is when funding decisions are made. It is almost axiomatic that money begets politics. In my experience, the most effective and efficient way to cut through politics is with facts/data, which incidentally has a tremendously positive impact on culture. Once established, a fact/data-driven culture can persist for a long time, which is a key ingredient for sustaining competitive advantage.

Thanks for the comment.

Ron

Robotics Developer

1/25/2011 11:44 PM EST

An interesting article, I have worked in the semi industry for more than 15 years and never found a schedule realistic. Too often the designers presented a real schedule to the management and it was tweaked to meet some arbitrary set of deadlines. This is oftentimes the real cause of “schedule slip” it is non-realistic schedules being adopted as real. Specs do change, resources do disappear, software has issues these are not unexpected and should be accounted for but as I stated the real schedule does not meet the management’s target dates. Until that is addressed, development will always be “late”.

RCollett

1/28/2011 7:53 PM EST

Robotics Developer,

Management thrives on data — it makes decision-making so much easier, because it takes some of the risk out of the equation. Hard facts and data are therefore a powerful tool for persuading management that a project’s schedule is wholly unrealistic. The data must unequivocally show that even if the team acheived best-in-class productivity, the schedule is still not achievable because the staffing allocated to the project is not communsurate with the design’s complexity and the schedule constraint.

When presented with this, management has little choice but to reduce the scope of the project, relax the schedule constraint, add more resources and/or reblance the project portfolio (i.e. reduce the number of projects).

Thanks for the comment.

Ron

The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...
Death of the SoC Rumors of the SoC’s impending death have been popping...
The Elephant in the Corner Why do so many IC design teams commit to development...

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

Facts and Data vs Heuristics and Hope

Numetrics — Sat, 20 Nov 2010 13:01:20 +0000

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?

Persistently missed product development schedules—poor schedule predictability—is the culprit and bane of semiconductor companies. It is a pervasive problem in an industry whose R&D stakes are now excruciatingly high. Typical SoC development costs, for example, range from $50 million to $100 million (from design concept to release-to-production). With a target return of 5X to 10X and a narrow market window, a mere three-month slip can dramatically reduce revenue and profitability. No surprise.

Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs. Absence of a reliable estimation process is the crux of the problem. Curiously, many semiconductor executives have been blind to the issue, and yet it is the key failure mechanism of their businesses because it goes to the heart of their product development engine. Go figure.

Accurately calculating design difficulty—the prerequisite to reliably estimating resources and schedules—demands quantitative methods that measure the intrinsic difficulty of designing an ICs logic, circuitry, packaging, etc. However, it must also take into account the sizable stochastic footprint of chip development.

Some executives fail to recognize the stochastic aspect of IC development has a far greater impact than ever before—a consequence of soaring development costs, inexorable competition and the limited size of each market opportunity. Resource and schedule planning therefore demands a stochastic model, which contemplates events that projects routinely encounter. Examples include spec changes, EDA tool issues, IP quality, project management, organizational issues, etc. It’s not exceptionally hard to model the development process, but it does require a good deal of industry data.

Project and program managers typically rely on experience and intuition to create project plans. Not a bad start, but the approach is light on facts and data and heavy on heuristics and hope. IC development has both a deterministic and stochastic component, and they are inextricably intertwined. Most project plans contemplate only the deterministic aspect of complexity, which is why they are flawed from the start. Not addressing the “stochastic problem” will almost certainly translate into reduced shareholder value and lost jobs.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4210716/Facts-and-data-versus-heuristics-and-hope-

Comments

iniewski

11/19/2010 6:45 PM EST

Ronald, you write “Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs” but my experience on many IC projects has been that all projects miss schedule because they are designed to do so! As one executive explained to me, “if I make a realistic schedule we will be late to market by one year, but if I shorten it unrealistically we might be only 6 months late”…has anyone worked on an IC design project that met teh deadline and was on budget??? Kris

RCollett

11/29/2010 6:54 PM EST

Kris,

My observation is that giving a team an unrealistic schedule is usually counter-productive b/c it is a demotivator. Far better is to give a team a very aggressive — but achievable — schedule. When I say “very aggressive,” I mean a schedule that assumes the development team’s prodcutivity will be best-in-class. In other words, in order to achieve the target schedule, the team must perform at or near best-in-class. The result (based on tracking this phenomenon on hundreds of projects across the industry) is that the productivity of those teams are far above norm — and the projects are are on schedule (slip is less than 10%) and come in within tolerable budget margins.

Thanks for your comment.

Rgds,

Ron

Robotics Developer

11/20/2010 9:35 PM EST

I could only dream to be on ANY project that was on time, on budget, and up to full performance. I (when I was young and naive) would give realistic schedule estimates to my boss; he would double or triple it and give it the the VP; the VP would talk with marketing and come back with a schedule that was 75 to 80% of my original one. There is always pressure to shorten the proposed schedules either by the boss or higher ups. What usually happens is the engineering staff gets hammered and is blamed for the slipping schedules. NO-ONE remembers the original schedule, its just a fact. Until companies realize that the designs will take just so much time / resources and make the appropriate trade-offs UPFRONT they are bound to lose market share or fail. I might suggest a sliding schedule analysis that provides the cost verses time to market trade-offs balancing shorter/more costly development with earlier/more profitable releases. Anyone know a company doing this?

RCollett

11/29/2010 6:44 PM EST

@Robotics Developer,

There are definitely companies making appropriate up-front tradeoffs — Intel for example. Here is an abstract of a paper presented by Intel at an industry conference held earlier this year devoted to project planning strategies:

“Effective planning for complex design projects requires understanding the tradeoffs between resources, complexity, schedule, and risk. Resource decisions are based on a particular project’s priorities, which may impact team productivity [because team size might need to be increased to hit target schedules, and increased team size will reduce productivity -- but increase throughput], and hence are important to comprehend in any systematic approach to benchmarking or planning. An empierial model for silicon design is built from available data: both from internal and external sources. This mdoel can be used to understand reslationships between team size and productivity, complexity and duration, risk and performance to schedule. Use of the model to predict organizational limits for complexity is discussed along with how key trends like reuse and modularity are unavoidable responses to current trends. This model is used throughout Intel to help make silicon design resourcing decisions . . . .”

In light of the above, perhaps it’s not surprising that Intel’s financial performance continues to be exceptionally strong.

Rgds,

Ron

iniewski

11/29/2010 7:40 PM EST

thank you Ron, agreed…pls pass the info on to executives

Death of the SoC Rumors of the SoC’s impending death have been popping...
The Elephant in the Corner Why do so many IC design teams commit to development...
In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...

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

The Ripple Effect

Ron Collett — Thu, 12 Aug 2010 15:00:23 +0000

As a senior product-development manager, you’ve no doubt seen the ripple effect: Your project is humming along and it’s time to add engineers on a crucial part of the design. But wait! The engineers you need are tied up on another project whose schedule has slipped, and they can’t be moved over to yours. What’s worse is when the manager on that project is not sure when they’ll be free.

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.

Overcoming the challenges of design reuse: A Webinar

Numetrics — Fri, 15 Jan 2010 23:32:13 +0000

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!

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.

Why Most Semiconductor Design Projects Slip Schedule

Numetrics — Mon, 19 Oct 2009 19:45:39 +0000

(Summary: More than 80 percent of semiconductor projects slip schedule, but we can change this costly reality by introducing a fact-based planning methodology into semiconductor product-development organizations).

By Ron Collett

The increase in semiconductor design complexity never slows. This reality always reinforces itself when I look at the agenda of a given week’s technology event. This week’s headliner is ARM Techcon3 in Santa Clara.

Here’s a sampling of the presentations:

“How Software and Hardware Can Cooperate To Manage Power Consumption in ARM-based Systems”
“Fireside Chat: Enabling Internet Eveywhere and Advancing Next-Generation Designs”
“Energy Efficient Design at 65nm – What Really Works!”

And the list goes on—challenging design issues at complex technology nodes everywhere you look. It’s little wonder then that most semiconductor design projects slip schedule (see chart).

Old habits in a mature industry die hard. Engineers have built products in more or less the same way for 40 years, and they’ve had tremendous market success. So why change? Engineering intuition always seems to work, and a bottom-up approach to project staffing is the way we’ve always done things. No reason to change, right?

Wrong.

Projects slip for a number of reasons:

We’re human. Who can predict when or if a spec change might occur or the flu takes out a few key engineers for a week?
We often lack the context to make fact-based decisions for dizzingly complex designs. For example, if you’ve spread a design over three locations in different time zones, using a newly-acquired team designing to a new process, you’re trying to extrapolate the effect of those factors based on your experience. But you probably have never experienced those factors before because each design is different.
Projects are late often because they are under-scoped. The schedule for the new project is based largely on the post-mortem of the last project, with the conclusion that none of the things that went wrong last time will be allowed to go wrong this time (and no other major new challenges will be allowed to creep in!).

Typical bottom-up reactions to managing such complexity tend to fall into two categories:

Boost staff to hit schedule. This generally creates either a low-productivity, low-throughput situation or a high-throughput, low-productivity environment. Teams might hit schedule but will blow out the budget.
Leverage a small, skilled team of engineers and drive it hard. This can marshal costs and improve decision-making, but a small team can produce only so much in a given period of time, even if it’s highly productive. Too much pressure to hit an unrealistic schedule also kills morale.

Sharp engineering managers can achieve best in class and cut or eliminate schedule slip by adopting a top-down approach that complements their traditional bottom-up planning. The top-down methodology uses:

Quantified estimates of the chip’s complexity
The team’s productivity
A model of the rate at which effort will be expended on the project.

With the proper infrastructure in place, schedule estimates can be generated within just a few hours. At this point you can benchmark against your own experience or against the industry’s experience and make fact-based what-if tradeoffs to boost your schedule predictability and design ROI.

More than 80 percent of semiconductor projects slip schedule. But we can change this reality. You wouldn’t expect this from your foundry, would you? Your foundry partner gives you a precise estimate of yield on your chip based on its models and its vast experiences with similar projects. You should expect the same predictability from your product-development organization.

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.

IC Teams Tend to Underestimate SOC Development Costs

Numetrics — Sat, 26 Sep 2009 00:18:53 +0000

By Ron Collett

Underestimating the complexity of an SOC semiconductor design project is a growing problem in our industry. In an era where SOC projects cost tens of millions of dollars to complete, a week of schedule slip means $1 million or more in lost revenue potential. That’s unacceptable.

That was my main point last week during a panel I participated on that was part of the EE Times SOC Virtual Conference.

Former EE Times EDA Editor Richard Goering, now blogging for Cadence, captured the panel well in a post this week (Are SoC Development Costs Significantly Underestimated?).

To justify the investment in an SoC, Collett said, the available revenue stream must be 10X the development costs. Thus, if an SoC has a $500 million market opportunity, development costs should not exceed $50 million. Today, however, development costs can easily reach $40 to $80 million. Collett noted that 60 percent of this cost is labor and that the major part of the overall development cost is verification.

Richard, with a great comparison, went on to write:

Anyone who has ever been involved in a home remodeling project knows how hard it is to get a reliable estimate up front of how long it will take and how much it will cost. Underestimating time and cost is commonplace. A large SoC design project is far more complex, with many more stakeholders. There is no simple answer to the question of how development costs can be accurately predicted. But there are some ideas about how to lower development costs.

Tensilica CTO Grant Martin weighed in from the IP perspective, Xilinx VP of Product Development Steve Douglass offered the FPGA perspective, and ASIC designer Sven Andersson from Realtime Embedded AB talked about the value of verified IP blocks. It was a great conversation, and you can hear it in archived form by registering for the event.

There’s some additional information about the panel (we tweeted some highlights during the panel) that have been cataloged under the hash tag #eetsoc.And we’ve published a helpful white paper on how to measure IC development productivity in our online library.

Time really is money in the semiconductor industry, and quantifying schedule risk is an excellent way to maximize your engineering investments.

Are SoC Development Costs Significantly Underestimated?

End of the Free Ride According to Pagemill Partners, a well-known Silicon Valley venture capital...
Death of the SoC Rumors of the SoC’s impending death have been popping...

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