• The login component features highly-secure protection measures to safeguard your personal information. Your login credentials are transmitted securely using SSL protocol encryption. This is true even though you do not see "https" in the URL, or a lock icon on the bottom of the browser window. If you require additional assistance, please email us at info@numetrics.com

    Numetrics application is temporarily unavailable due to system maintenance.
    Normal operations will be restored by 10:20 PM PST 02-Mar-10.
     
    Enter your personal login to access Numetrics' customer area*
     
       
    * Login name and Passwords are case sensitive
    Forgot your password Security Concerns?
    Don't have a login name? Contact Us
    • Home
    •  
    • Solutions
    •  
    • Products
    •  
    • Services
    •  
    • Consulting
    •  
    • About Us
    •  
    • Library
    • Feedback

    Categories

    • Best Practices
    • Case Studies
    • Customer Testimonials
    • Industry Database
    • News
    • Productivity
    • Products
    • Project Planning
    • Risk Analysis
    • Schedule Predictability

    Recent Articles

    • How productive is your R&D organization?
    • The Brewing Innovation Storm
    • Doing Moore with Less
    • Sleepless in San Jose
    • DVCon and the Design Productivity Crisis
    • Lessons from The Checklist Manifesto

    Archive

    • June 2010
    • May 2010
    • April 2010
    • March 2010
    • February 2010
    • January 2010
    • December 2009
    • November 2009
    • October 2009
    • September 2009
    • August 2009
    • June 2009
    • May 2009
    • April 2009
    • March 2009
    • February 2009
    • January 2009

    Tags

      cores design reuse EDA EE Times ERP software fact-based planning IC development productivity ip ip cores Jasper Design Automation Kathryn Kranen new product development Numetrics Planning planning software product development Productivity project management software Risk Analysis risk assessment risk management Ron Collett Schedule Schedule Predictability semiconductor semiconductor design semiconductors SOC software design system-on-chip

    Blogroll

    • A Conversation on Innovation (Sanjay Srivastava)
    • Daniel Nenni's Silicon Valley Blog
    • EE Times News
    • Harry the ASIC Guy (Harry Gries)
    • Industry Insights (Richard Goering)
    • JB's Circuit (John Blyler)
    • Leibson's Law (Steve Leibson)
    • Low-power Design.com (John Donovan)
    • Practical Chip Design (Ron Wilson)
    • The World is Analog (Mike Demler)

    Project Planning

    The Importance of Capital Efficiency

    by Numetrics | January 27, 2010 | In Best Practices, Productivity, Project Planning | No Comments

    VC Funding Chart 2007-2009 copy

    By Ron Collett

    The latest venture capital investment figures are out from PricewaterhouseCoopers’ MoneyTree and the National Venture Capital Association (NVCA). They’re not pretty.

    VCs spent just $17.7 billion on 2,795 deals last year. That’s down 36 percent from $27.9 billion in 2008, and it represents the lowest dollar amount and number of investments since 1997.

    The chart I pulled together above, based on that data, shows the quarterly VC investment trends for semiconductor companies in just the past three years. Not an encouraging trend line. Total VC investment last year in our industry was $771 million, compared with a peak of $3.4 billion in 2000. What a difference a decade makes.

    This realignment of dollars has brought about new expectations from investors and from semiconductor vendors.

    Speaking to The Wall Street Journal last week, Bob Ackerman, a venture capitalist at Allegis Capital in Palo Alto, said:

    We’re preoccupied by capital efficiency.

    Those two words, “capital efficiency,” speak directly to the semiconductor industry’s challenge. This focus on capital efficiency is why semiconductor vendors should be increasingly preoccupied with boosting engineering productivity to get the most from their R&D budget. Lacking an internal fab for differentiation in the fabless era, companies are looking for new ways to gain competitive advantage, and they’re training their sights on their R&D organizations.

    The industry’s best-in-class semiconductor IDMs in fact have jumped on this imperative, especially as many of them have shed the last of their owned fabs and now need to compete with fabless companies.

    But it works the other way too: Long-time fabless players suddenly find big new competitors that have shed their fabs. They too are looking to boost product-development productivity to stay one step ahead of their new competition.

    It’s clear the days of big-time investment are a thing of the past. Today, good companies are those with innovative product ideas; great companies are those that also drive highly productive R&D organizations to get those products completed on predictable schedules and to market ahead of the competition to realize higher returns.

    Design Reuse: It’s Harder Than it Looks

    by Numetrics | December 3, 2009 | In Best Practices, Productivity, Project Planning | 1 Comment

    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).

    Productivity, Predictability and other Burning Questions

    by Numetrics | November 4, 2009 | In Best Practices, Productivity, Project Planning | No Comments

    By Alex Silbey

    (Summary: We inevitably get questions about Numetrics’ technology after webinars or live event presentations, and we’d like to share some of them in the spirit of helping you understand more about our products and solutions. Here are answers to several recent questions in the virtual mail bag).

    Q: How do you define productivity?

    A: We calculate complexity of the project and we divide the complexity units by total number of person weeks required to get that product out to volume production. That quotient gives you the productivity number. The typical range is 500 on the low end for a large team to 3000 for a small team.

    There’s another measure, which is throughput, and throughput is complexity units per week. That’s a measure of normalized cycle team. Productivity is efficiency of the team and higher number is better.

    Q: I’ve heard that in some sectors productivity decreases as team size increases. Is this true in semiconductor product development?

    A: It’s a universal effect across pretty much any activity that has to do with building things. When you build larger teams, each person is doing a smaller and smaller slice of the overall work. More work has to be split apart and then put back together. Bigger teams equal more meetings and more management required. It’s universal and it’s inevitable. With the Numetrics approach, you can minimize this effect—decreasing productivity curve is flatter than it would otherwise be.

    Q: It’s impossible to predict in a design project how many times customer requirements will change, when your EDA tools go buggy or if a key contributor leaves the team. So how do you quantify schedule risk with so many unpredictable variables?

    A: The simple answer is our tools don’t predict things. You have a draw a line between statistical analysis and a crystal ball.

    What Numetrics’ tools do is take your inputs of design parameters and measure them against the history of more than 1,500 design projects over eight generations of technology evolution (here’s a link to a demo of our tools). Using the data from those hundreds and hundreds of designs, this builds in realistic effort required to deal with those issues. It’s a way of contingency planning.

    Think of it like yield modeling. You know that on each wafer a certain number of dice will fall out. Yield modeling doesn’t tell you which particle is going to hit which die and where. But they give you an accurate assessment of how your design will yield. Numetrics is like a yield model for project plans. It’s saying there’s a certain probability that if you’re going to try to achieve these targets, given what you’ve input you’re going to fail.

    It allows you to make a quantitative assessments. It’s a probability model. It’s not a crystal ball.

    Q: How does the complexity calculation model handle predictions for newer nodes, such as 45 and 32nm?

    A: Numetrics’ IC Industry Database has collected information for eight technology generations. The technology shifts from one generation to another have been observed before. And what we’ve observed is that early users of technology nodes face considerably more complexity than later users of the same node, once the models and such are more stable. The equation has calibrated this effect which repeats from generation to generation. We’ve been able to model what the effect of the extra technology of a new node will be on a new design.

    Q: Can your tools get data from existing sources or do I have to input it manually?

    A: We’re dealing with milestones, staffing information and complexity information. Typically this information is copy-pasted from existing sources or customers are using XML import to get data into our tools.

    (Alex is Numetrics’ director of professional services).

    Why Most Semiconductor Design Projects Slip Schedule

    by Numetrics | October 19, 2009 | In Productivity, Project Planning, Schedule Predictability | No Comments

    (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).

    Schedule Slip Bar Graph

    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.

    For Semiconductor Companies, a New Focus on Differentiation

    by Numetrics | October 5, 2009 | In Best Practices, Productivity, Products, Project Planning | No Comments


    (Summary: For semiconductor companies, differentiation has shifted from manufacturing to improving productivity in new-product development. That realization is the easy part; getting there requires help.)

    By Ron Collett

    I’m always impressed with the level of optimism I find at semiconductor industry events around the world. There may be pockets of gloom about the state of the semiconductor industry, but executives certainly don’t share it. Yes, it’s not the same industry it was 10 years ago, but, no, it’s not doomed. Far from it: The dynamics are just different.

    That was my message when I presented last week at Malcolm Penn’s International Electronics Forum in Geneva. Here’s why the dynamics are different:

    • The industry head count has shrunk 30 percent this decade
    • Industry consolidation has picked up pace
    • Cost-cutting is rampant
    • There’s more pressure than ever on design teams to get great products out the door on time and on budget

    Here’s how the dynamics are different: Differentiation has shifted as industry disaggregation has reached an end state. There was a time when a semiconductor company differentiated itself through manufacturing and process technology (or way back when, through making its own steppers!) No longer.

    So where’s the differentiation? It’s not in cost-cutting. Everyone’s doing that.

    Differentiation has shifted to the heart of the semiconductor company’s value proposition: its new-product development.

    Electronics Weekly’s David Manners, in his coverage of IEF last week (“What’s the Answers to the Chip Industry’s Problems? Ask IEF”), touched on how profound this can be. He quoted Alain Dutheil, CEO of ST-Ericsson, as saying 85 percent of his 8,000 employees are in R&D.

    The other part of the story, which we’ve blogged about, is that most SOC projects slip schedule and most IC teams tend to underestimate their product R&D costs.

    That brings me back to our IEF presentation (“Raising the Bar on Semiconductor R&D Management, Execution, and ROI”), which we created in partnership with PRTM, one of the world’s premier operational strategy consulting firms (with deep ties to the IC industry).

    Our three take-aways were:

    • The bar is being significantly raised on semiconductor R&D management, execution, and achieving ROI
    • Companies must continuously progress through the stages of maturity to thrive (functional, project, portfolio, and cross-enterprise excellence)
    • Fact-based planning is a critical foundation for ongoing NPD success

    Anyone can cut costs in challenging times but winning companies find news ways to differentiate themselves, and they are the companies that come out of recessions stronger than their competition.

    IC Teams Tend to Underestimate SOC Development Costs

    by Numetrics | September 25, 2009 | In Best Practices, Productivity, Project Planning, Schedule Predictability | No Comments

    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?

    Talking Schedule Predictability with EE Times

    by Numetrics | September 17, 2009 | In Productivity, Project Planning, Schedule Predictability | No Comments

    By Ron Collett

    I had the pleasure of participating in a great online panel yesterday that was part of the EE Times SOC Virtual Conference, attended live by more than 1,500 people. CTO Grant Martin with Tensilica, product-development Vice President Steve Douglass with Xilinx and ASIC and FPGA designer Sven Andersson of Realtime Embedded AB all contributed to robust discussion of where next-generation design is headed.

    I encourage you to listen to panel, which is now archived for the next six months.

    My point was pretty straight forward:

    • If you misunderstand your semiconductor design project’s true cost, your SOC may be doomed.

    Think about it: An SOC design today needs to return 10x its investment. There aren’t a lot of huge end markets that justify SOC projects where the costs and schedule aren’t carefully managed. If the design costs $50 million to $80 million to develop, and there’s only a $200 million market, then the design can’t be justified.

    So getting your arms around true development cost is what SOC development is all about.

    Re-Planning semiconductor design projects effectively

    by Numetrics | August 3, 2009 | In Best Practices, Products, Project Planning, Risk Analysis | No Comments

    Summary: Re-planning a semiconductor design project is often inevitable as the program is underway. The key to effective, productive re-planning lies in understanding complexity, schedule and resources.

    Change is inevitable. Economic factors, mergers and acquisitions, customer specification changes, management and strategy changes all affect project planning and execution. These factors create a need for re-planning IC projects while they are ongoing.

    The key to re-planning is the same as for the original planning process: an understanding of complexity, schedule and resources. Numetrics’ NMX-ERP can capture not only the starting characteristics of your design, but also updates as work is completed. This means that at any point during the design, you can calculate the work remaining and the resource and/or schedule implications of that.

    Re-planning is simply a process of updating the assumptions based on new information. From there it is a simple process to re-run the analysis, and to generate a new plan. This is easy not only because there is explicit support in the tools for re-planning and the management of multiple scenarios for a single design, but also because there is no need for data re-entry. Everything is built from the original plan, saving a great deal of time for your planners.

    Schedule Risk Analyzer generates a comprehensive set of reports that quantitatively assess the underlying schedule risk, given the design’s complexity, staffing assigned to the project and target cycle-time.

    Schedule Risk Analyzer generates a comprehensive set of reports that quantitatively assess the underlying schedule risk, given the design’s complexity, staffing assigned to the project and target cycle-time.

    The real implication of the re-planning capability is that when a change is proposed, you can quickly determine feasibility. For example, if marketing comes to you and says, “We need samples six weeks early for a key customer,” you can rapidly tell them what that means for resources. If additional resources are not available, you might consider scaling back product features to meet the new schedule. Alternatively, you may be forced to complete the design with fewer engineers than you had originally planned for. In such a case, you can quickly determine the best way to meet your business objectives with the new constraint—either reducing the feature set, or planning for a managed schedule slip.

    The net benefit of Numetrics’ re-planning tools is fact-based decision-making in a time of stress. Fact-based planning improves the quality of internal decisions, leading to a healthier business and happier employees. And that can’t be bad.

    How to minimize IC development schedule risk

    by Numetrics | May 5, 2009 | In Best Practices, Project Planning, Risk Analysis, Schedule Predictability | No Comments

    Summary: Risk to IC development schedules can be minimized by comparing design plan assumptions with a database of historical industry designs and your company’s own history of completed projects to help you determine tradeoffs.

    Simply put, schedule risk is the difference between the planned schedule, and the lessons of history. If you plan to finish a design with 20 engineers in 25 weeks, yet industry and corporate comparisons indicate that you need either 27 engineers or to lengthen the schedule to 34 weeks, you have identified schedule risk.

    The Numetrics tools can compare your design plan assumptions with all designs in the industry database, or with a subset based on powerful filters, or most powerfully with your own company’s history of completed design projects. If your plan is more aggressive than the results achieved historically, then you risk missing your schedule. High levels of schedule risk disempower your engineers, because the plan feels unrealistic to them. It also creates business risk, especially if schedule is critical. It doesn’t make sense to agree to a plan that requires productivity much greater than you have historically been able to deliver.

    On the other hand, it is reasonable to set a stretch goal that is a little better than your historical performance or the industry averages. That’s a stretch goal, and if the team believes it’s feasible, they will work hard to achieve it. This is a point where risk is managed, and the goals are achievable. Everyone likes to outperform their peers, but no one wants to be set up for failure.

    By using Numetrics’ tools to analyze schedule risk, you can create a plan that is aggressive, but not so aggressive that it is doomed to fail. Such a plan is good for your team, and good for your business.

    Ensuring schedule predictability for IC designs

    by Numetrics | April 3, 2009 | In Best Practices, Project Planning, Risk Analysis, Schedule Predictability | No Comments


    Summary: Schedule predictability is the art and science of determining the completion date for your semiconductor IC project, based on a statistical model, validated across multiple designs.

    When you plan a project, you are working with incomplete information. Organizational changes, specification changes, technical challenges and more conspire to make it difficult to accurately predict when your new product will be ready.

    Schedule predictability is the art and science of determining the completion date for your project, based on a statistical model, validated across multiple designs. The key ingredients are your design’s complexity, coupled with your resource plan. With these two inputs, Numetrics can significantly improve the accuracy of your schedule predictions. One customer went from consistent overruns to accuracy within a few percent on the first designs they modeled in the Numetrics toolset.

    How is this possible? The core is the Numetrics ability:

    • To understand which factors drive complexity
    • To create a normalized characterization of your design that allows comparison with others.

    When we compare your proposed design with historical productivity and schedule information, we can statistically determine the expected schedule for your new project. The accuracy of the model is enhanced by our industry database of over 1200 designs, coupled with specific information from your company’s historical project record.

    The result is a robust, realistic prediction of the schedule, based on

    • Complexity
    • Resource availability and
    • Historical data.

    The value is a greatly enhanced ability to meet your market windows, time and time again.

     
  • Copyright © 2010 Numetrics Management Systems, Inc. All rights reserved