Category → Tools
The Emerging NPD Resource Model
The sourcing of New Product Development (NPD) efforts is heading for a change, a transformation that will be enabled purely by business necessity. It will happen and we can either prepare and embrace it or be left to play catch-up, wondering why the signs of change were ignored.
Reflect on the progression of the FAB model over the last 15 years. During this period there has been a significant reduction in captive FAB ownership and a much greater use of an outsourcing model for the fabrication of silicon devices. Today there are far less capacity utilization issues, more competitive technology development and a greater ability to “shop around” for pricing. In the old captive FAB model some new product projects would actually be approved to “fill the FAB”, a financially ridiculous reason that was commonly used to justify weak margin product development efforts.
Now let’s take a look at the classic chip design model in use today. By and large the design resources for new products are “owned” and need to be kept busy to justify their fixed costs. This means there is a motivation to move forward on a project to utilize resources, even when the biz case may be questionable. How many of us have worked on new products that were production ready and lacked expected revenue? Was the project easier to justify because of underutilized resources that were in need of a project? Sure! Just like the old FAB model, the concept of utilizing a design team for a questionable new product based on filling resource capacity is just as crazy.
What really are the motivations for captive (business unit owned) new product teams to become more effective at what they do? There are really not any; the incentive for truly making a positive change is nearly non-existent. We expect NPD efficiency improvements by demanding them and pleading with the team to get better. However, things stay just about the same for months and even years. There really is no incentive because the current resource model does not provide one, and never will.
The two primary enablers of mediocre new product efficiency are forced utilization and the lack of incentives for improvement. Let’s look back again at the FAB model of today. Utilization has become far less of an issue because the FAB is a broadly shared resource. Similarly the efficiency and quality of FABs has improved because of the competitive pressures brought about by having multiple sources to choose from. The truth is that competition stimulates excellence.
Although IP reuse is in its infancy, it is a quiet catalyst of a new way of handling product development. Similar to the outsourced FAB model, there will be a migration towards increasingly outsourced chip development efforts. This transformation will be driven by businesses demands for cycle time and product success improvements that the current captive resource model is in fact unable to provide.
Businesses demand superior new product efforts. I predict this requirement will be increasingly satisfied through a growing ability to “shop around” to find development teams whose very survival rests on “being the best”. The next generation NPD model will be one of decreasing captive resources and more utilization of internal sourcing pools and greater outsourcing. This will be good for business and excellent for efficiency. Be ready!
EDA360 – A Silicon System Vision we must Build Upon
Cadence began publicizing the EDA360 vision back in April of this year and since that time there has been a fair share of discussion, both negative and positive comments; and certainly some confusion. I was definitely a member of the confused and negative camp; that is until I spent enough time to really research and understand what this vision was trying to tell us.
EDA360 is not a tool roadmap… at least not today, it is purely a vision based on the enlightenment of John Bruggeman, Cadence CMO and his team. They have seen the light, understand the pain of putting together an embedded system today and have identified a vision of where EDA needs to be in order to significantly remove that pain and increase productivity in embedded system solutions. It’s not the end, barely even the beginning, but it is a vision suitable for developing a strategy from, and that my fellow designers has significant value.
Over the last week I have been studying the EDA360 vision document and have extracted my perceptions of what was being said, merged in with my history in design along with my biases, and created a picture of the EDA360 vision. I am a visual kind of person, so for me to fully digest the scope of EDA360 I needed to turn it into a diagram. Below you can see a depiction of EDA360, “as Jeff sees it”.
Jeffs View of the EDA 360 Vision
From my perspective there were three significant takeaways from the vision:
- Product realization must start with the end applications; actual hardware design needs to move much further down the development pipe than it is today. We are designing complete application enabled systems, not just chips.
- An all-encompassing verification platform is one of the most critical barriers to realization of this vision and is the key to stitching all the abstraction levels together. This platform must cover full applications running at an early 100% TLM level through the same applications running in a mix of abstraction levels that include RTL, gate, transistor level as well as TLM. The verification bench must also include hooks into the physical end user world such as keyboards and displays. A tall order indeed, however a pivotal requirement nonetheless.
- A common “system” database that allows downstream access to design history as the system migrates towards finer levels of abstraction. Data should never be lost or regenerated. Leveraging historic development data is crucial for both quality and productivity.
It would be difficult to argue that this vision, as a beginning, is not where we need to be headed in the semi industry. As John points out in the vision paper, realization of this ideal system development environment will not happen within one EDA supplier. There are many pieces to solving the systems puzzle and many companies have something to offer towards this ultimate goal. I am curious what inputs Synopsys or Mentor have on the EDA360 vision? Achievement of this game changing visualization will require multi-company structure, organization, planning, execution and funding. Sounds like a consortium, maybe the Silicon System Crusaders (SSC). Let’s start talking and provide a cure for “Terminal Sameness” in embedded systems.
Is the EDA Support Model Working?
When thinking of EDA, there are generally two areas that come to mind. The first is the design tool suppliers and the second is the internal support for customization. I also view a third being the end user, the design community itself. Tools are purchased from the supplier, customized and supported by internal EDA support and then are made available to the design community.
This is a traditional approach to EDA and one that is utilized broadly across most companies in the semiconductor industry. It’s historic, bureaucratic and I believe it’s lacking the productivity benefits the industry needs. Why? Simply because the design community does not have a full voting rights seat at the EDA table. This is partly of the designer’s own doing and in part because of organizational structure. How many designers attend the coveted Design Automation Conference?
The EDA support model is rather incestuous, isn’t it? Maybe we need more designer genes mixed into to the pool to provide proper balance and direction. I am curious what the design community has to say on the subject.
Here’s a question for all those designers out there – how’s the EDA support model working from your perspective? EDA types, please be very quiet whilst we here from the design community. They don’t speak very load, especially the analog designers, so we need to keep the volume low so we can here from them.
Designers – stand up and be heard by leaving a comment on your view of the situation. We are quietly waiting to hear from you.
Flow Customization is not Winning the Time to Revenue Battle
What’s the first thing that happens when a new tool becomes available, or even a new major revision is in the works? The discussion about how to “integrate” it into the way we do things commences – customization begins. Is there really only one right way for a tool flow and everyone else chooses the wrong way? I need a really good reason why we are unable to expect a tool to be ready for use out of the box? Why must everyone monkey with tool customizations to make it more right? What we need is freedom from customization!
Think about how much time is spent and wasted on chasing the ultimate, best in class super duper Pcell? There are two things that matter in chip development: 1) Designers must not be battling with tools and 2) The tools need to provide an answer that is good enough to prevent a silicon spin. It’s really pretty simple. If you can build a case for positive time to revenue impact based on diddling with design environment customizations, I would like to hear it. I maintain that tool flow customization negatively impacts time to revenue.
What tends to happen is all this customizing that goes on chasing the ultimate environment creates a maintenance nightmare. The need to make it better has created a headache for both the users and those doing the customization. The biggest complaint I hear from designers is that the tool flow often breaks unexpectedly. If they worked yesterday, why don’t they work today? Something changed, and that change was most likely precipitated by a need to be better somewhere along the flow.
Here’s what we should be able to do. Buy a copy of someone’s design tools, get the PDK from our FAB of choice, design without a hitch, tapeout and get silicon back that behaves the same as we verified in the tools, period; end of story. If that’s not happening there are only two things that could be broken, the tools you bought or the PDK. Get them fixed at the source! If you buy a new car do you hire a team of mechanics to make it better, more like the ultimate car you envision? So why do development teams believe the expensive investment they made in tools needs improvement?
The reality is that there are a huge number of right ways to approach design, not just one. Improved time to Revenue will result from consistency in approach, essentially alignment to a single approach/choice for all steps in the flow. Everyone has an opinion and firmly believes in their right choice and will fight for their cause, disrupting the much-needed consistency. We allow it, we condone it and we whine about it. The truth is tool flow customization is wreaking havoc with new product development efforts. Freedom from choice will positively impact time to revenue!
What’s Analog Rails all About?
Last week I had the opportunity to visit with Get2spec CEO Cliff Wiener and we discussed the upcoming release of their Analog Rails product, advertised to leapfrog past the Cadence Virtuoso suite. Cliff is definitely passionate about the needs of the designer; an area he maintains has not been serviced well by the current EDA suppliers. The following is a summary of the discussion I had with Cliff following a demonstration of the Analog Rails suite.
What is your background in the semiconductor industry?
I have spent 28 years in the business to date. The first 10 years was doing analog design with pen and paper followed by 5 years learning and designing with CAD tools. From there I moved into driving analog and RF design methodologies for 7 years at National Semiconductor, and Motorola Semiconductor prior to starting Get2spec / Analog Rails over 6 years ago.
What motivated you to develop the Analog Rails suite of tools?
There were really two reasons: 1) Frustration with CAD vendors, and 2) I knew how to automate analog. Let me expand. The leading vendor relied on enormous CAD teams, and the tool was overly complex and very generic. There was no built-in intelligence to the tool. I decided to make an analog expert system where no brainers are automatically put into the tool, and all the tools work together through the entire flow. An example of tool intelligence is a simulator that provides information to the placer and the router. Properly using this information, coupled with adhering to analog and RF design methodologies, allows automation to occur.
What sets the Analog Rails suite apart from the others?
The other EDA companies in analog are focused on verification and we are focused on creation. We believe in a correct by construction approach. We automate, they iterate. This is especially important at smaller feature sizes, where the STI effects are more severe. The circuit designer needs the parasitic information right away. We also believe that time to market is everything! Very few new topologies are being created in analog nowadays. The key differentiator today is who can produce the chip according to specification first – first in wins.
Do you have a proudest moment in the development effort that you could share?
Automating switched cap ADC’s (Cyclic, Pipeline, etc). The analog switches are a pain in the butt, but we have the technique down pat. I heard that analog automation is impossible, so doing the impossible is something to be proud of.
Ask me when we release our “design while you sleep” mode. It will optimize, place, route, RC extract and then re-optimize. It’s like the lady from easy-off stating that she is cleaning her oven…while she sleeps. We have the equivalent…for geeks.
What is the expected availability?
April 12th, 2010. We are actively demonstrating the product today.