Reading Sherry Hess’s blog got me to thinking about Paul Harvey and “the rest of the story.”  For those of you who haven’t lived in the U.S. Heartland or don’t listen to AM radio much anymore, Harvey made a career out of the kind of human interest stories, historical vignettes, or short biographies that are out of fashion today by feeding you an anonymous, out of context story-line only to reveal “the rest of the story” later in the program to make a point, teach you some history, or touch your heart.  Sherry’s discussion of productivity makes me think of the rest of the story:  the technical side and where some people are on the design “productivity curve”.

There are two halves to measuring productivity or cycle time.  First, how long does it take you to get one prototype into manufacturing.  Second, how many prototypes, or iterations, does it take to get your design into production manufacturing.   You can imagine that to some extent one can be traded off with the other, but given the way that a team designs, the design tools they may use, and a whole host of other factors, the idea of improving design productivity can become an engineering discipline unto itself.
Engineers using new technology have longer cycle times as they debug the technology with more prototypes.  Conversely, in mature technologies, you would expect that everyone optimizes their design process, taking advantage of all the EDA out there, to have minimum design cycle times and iterations.  But not everyone takes advantage of what’s out there and all designers don’t design using the same process.  For guys getting less than two spins per design on average, there just isn’t a lot of room to  eek out even more productivity.

For some folks, there’s still a whole lot of EDA to take advantage of to “ride” the productivity curve
Case in point, back before LVS and DRC (everyone out there is using them now, right?) you could pretty much count on getting nipped by these, even with a squad of diligent designers, a scaled ruler, and a light table.  Implementing DRC alone might save you a couple of spins and make a huge impact on your productivity. After getting DRC done, LVS is a little more challenging and costs slightly more but maybe now you are down around 3 spins per design and getting a full spin out of your productivity is a one-third reduction. 

So where are you on the design productivity curve and, to Sherry’s point, is the economic downturn a time to regroup and improve or scale back and let others take the lead?  What are you doing in terms of new tools or even just better utilizing the EDA, measurement, and modeling resources you already own?  Is it just a matter of taking a finer or holistic view of your flow, or starting from scratch?

I worked with one MMIC design house that is known for its leading-edge design abilities where they actually approached us and said, “this is where we see EDA needing to be in 1 year, 3 years, and 5 years.”   Oddly enough, they had been using DRC and LVS for more than a decade, but they had targeted this as a critical step in their flow that they felt was costing them.  Before I got to hear “the rest of the story”, I thought to myself, “how is that possible given that they have been using DRC/LVS tools longer than most?”  The answer is that they took a step back and didn’t just look at DRC and LVS, but they looked at how DRC/LVS evolved from and integrated with the rest of the flow.  They saw that their DRC layout and LVS schematic where not originating from the same design tools—they actually re-entered the LVS schematic by hand and apart from the DC/RF simulatable schematic,the layout was a flattened design in a layout system separate from their RF design tools.  The solution we came up with for them was to shift their layout designers to doing the layout in the same tool as the RF guys and adding some features which allow the same AWR schematic to be used for circuit simulation, system verification, and LVS.  The result – cutting their verification time by more than 50%.  While I’m not giving details of exactly who this customer is, you can validate my claims by reading one of the many AWR customer success story up on the website (link here).

Second point.  One thing I have been guilty of, and a host of my EDA brethren as well, is remembering that everything that is designed and fabbed needs to be measured.  For sure, you need to measure it make sure that performance can be understood and compared to simulation.  After all, the proof is in the pudding.  But if you look at the design flow—the critical path of getting from design concept to volume manufacturing—how, when, and why is measurement being done.  I had one design manager tell me that it was critical that engineers got on the bench; no argument here! Sole reliance on EDA software in RF/microwave design is a fool’s game, in my experience.  But then he followed it up with the “rest of the story”.  He wants his engineers to do almost no design and get out to the bench and start measuring since they found years ago that the sooner engineers were measuring circuits, the sooner the design got out the door.  If that sounds to you like throwing the baby out with the bath water, you’re in good company.  Unlike my friends revisiting DRC/LVS, this manager has not looked at how good and timely design makes for a more efficient and effective time in measurement. 

Conversely, I’ve had other managers with similar experience tell me they are down to 1.7 or so spins per design and the limiting factor is measurement as part of the design process…..sounds to me like an opportunity to start another “rest of the story”…..

So  where are you in terms of your productivity “story”?  Blog back to me about your vision and efforts to write “the rest of the story!”