Archive → March, 2010
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.
Explore a Focus Group Approach for Difficulties with Requirements
If new product requirements are a challenge for your team, and they are for many, it may time to consider a focus group or workshop type approach. Most of the problems I see with requirements are related to a lack in focus across the multiple levels of requirements needed for a new product. During this process there tends to be a lot of waiting going on, either for another level to be completed or a decision to be made.
A focus group approach brings all those concerned into a planned and well-facilitated set of requirements sessions. The sole purpose of the group is reaching consensus on a suite of requirements for a new product. You’re thinking that this sounds like a lot of work, aren’t you? In reality it’s not much more work for the team itself; actually it could be less due to improved preparation and focus. Only the person responsible for making the workshop happen will be burdened with extra work.
The alternative to this approach is to continue dealing with the disruptions caused by confusion, poor quality and frequent changes. I might suggest putting a price tag on the present, unfocused effort as a justification for exploring this alternative. You will be surprised to find how much requirements confusion costs in rework and delays.
Below are some considerations for utilizing a focus group approach to create the proper emphasis on requirements. Planning is critical for success and will typically consume 3-4x as much time as the workshop sessions, if done properly.
#1 Objectives
The first place to start a successful workshop is at the beginning – objectives. What is the purpose and charter of the focus group? Identify the scope to be one or multiples of system, engineering, module level, test or customer requirements. Also make sure to identify a sponsor, one who has authority to engage the team members for the workshop.
#2 Ground Rules
Separating a mediocre outcome from a clear success comes down to establishing rules of engagement. The ground rules establish how the team will operate and engage others during the workshop. The group will be a democracy and will need some laws to govern themselves.
- How will decisions be made where the team gets locked up?
- How will a troubling personality be dealt with?
- What about attendance issues?
- How will acceptable look?
- And so on…
It’s important there is guidance in place for situations before the group needs them. Reach agreement and post ALL ground rules.
#3 Inputs
This is the information and materials that are the inputs to the focus group sessions. It includes items such as an agenda, homework assignments, requirements quality checklist, templates, output expectations, existing specifications, business case, ground rules, visual aids and so on. The intent of the inputs is that they provide deliverables that the workshop will consume. Ideally the inputs should be prepared to a through enough degree to prevent the focus group from waiting for further information.
#4 The Main Event – The Focus Group
This is the actual workshop itself. The group will follow the agreed agenda and break up into smaller working groups as necessary to resolve requirements. Employ the agreed decision process when the team hits gridlock and leverage the agreed ground rules where necessary. Facilitation of this process is crucial to keep things moving forward. If the first three steps were done well, this main even should flow favorably; don’t skimp on preparation.
#5 Deliverables
Once consensus is reached it’s time to create specific workshop deliverables such as timing diagrams, models, electrical tables, block diagrams, descriptions and so on. Set actions in place to do this and set the team free. Once completed, pull the focus group back together for final review and acceptance. Depending on complexity there may need to be multiple iterations through focus group (#4) and deliverable generation steps (#5). Don’t get hung up on word for word review of requirements, focus on specific data (diagrams, tables, models). Once this process is complete the detailed requirements documents can be created.
#6 Closure
Hold a post mortem to learn and evolve the requirements focus group process for the next project. Generate specific, traceable actions for any remaining issues, including a follow-up plan to track through closure. Review the decisions that were made.
And so it goes…
If requirements are a battle, and I am sure they are, why not try something different? This approach is not magic; it’s really just about informed focus and will not work by breezing through the first three items to get to the main event. If you’re not willing to invest in the first three steps then don’t bother proceeding with this approach. A meager effort will waste time, provide dismal results and tarnish the reputation of this process.
Go forth and focus on early requirements, but prepare first!
What is NPD Management?
I am a newcomer to the blog ranks here at Extension Media and I wanted to say hello and introduce you to the topic of New Product Development (NPD) management. This is my passion and a broad area that I will regularly post about here.
NPD Management is not tools or project management. Nor is it design techniques or circuit descriptions. More than anything it is about enabling a new product team to be the absolute best at producing new product revenue. Enablers such as crisp requirements closure, internal IP reuse, and clarity of individual expectations are a few examples of NPD Managements focus areas.
Generally, there is always something beyond tools that is inhibiting optimal project execution. The key to continuous improvement will be in uncovering these barriers, developing a solution and rolling out a change in the development process that removes them as an issue. This is what NPD Management is all about.
Thanks for stopping by and stay tuned for tips, ideas and concepts that will help you in your quest to deliver products that produce target revenue quicker and with higher quality. I want to close with a quote on ownership that we must consider as we set our vision on being better.
“If it’s never our fault, we can’t take responsibility for it. If we can’t take responsibility for it, we’ll always be its victim.” –Richard Bach