WordPress.com has been a great service.

In the graph below we’ve calculated the derate for 4 cells at various load/slew points. The colors are darkest approaching 1 and brighter as the derate value moves away from 1. The + symbols show the library’s load/slew points.

Besides being fast, the latest version of Amber Path FX supports saving all derate calculations and results to a database.  You can now change the load/slew selection criteria and generate new derate tables in seconds.  We are adding the ability to mine this data and perform variance checks to ensure your design is operating as you expect. We are just now learning how useful this information might be – not only to improve timing results but also to make optimization choices.

The other thing that these graphs show is how unsafe using a few cherry-picked load/slew points can be.  That’s the methodology some have suggested in order to make generating AOCV tables more palatable with other SPICE tools.

With Amber Path FX you don’t have to make those choices up front. You can generate an SBOCV database with a large range of load/slew points (the full set from the library or based on your design rules) and then refine based on how the cells are actually used.

We’ll have a lot more to say about this at the TSMC Technology Symposium in a few weeks but if you have questions now feel free to get in touch.

I’ll explain what this is in another post but here is a hint. It has to do with our work with SBOCV/AOCV.

Last fall I mentioned that we made performance improvements to AOCV table generation.  At the time we sped up the simulation for complex cells and added the ability to distribute the characterization across multiple machines.

In the last month we’ve improved the performance again – getting a 2x boost across the board regardless of whether the work is on a single machine or distributed on your server farm.  We’ve got another 30% improvement in the short term pipeline and more ideas that we’ve just started looking at in detail.  With more and more back end tools adding AOCV support we are excited to be able to help design teams create tables faster than ever before.

On the Cadence blog there is a fairly comprehensive overview of OCV methodologies and the benefits of different approaches.  (Update: Having spent more time considering Cadence’s approach, we think it isn’t the right way to find design specific derate values. We’ll outline why in a future post.)

http://www.cadence.com/Community/blogs/ii/archive/2010/08/26/ocv-webinar-statistical-timing-finds-a-niche.aspx

Synopsys makes the case for AOCV on the PrimeTime Advanced OCV technology page.

http://www.synopsys.com/Tools/Implementation/SignOff/PrimeTime/Pages/PT-OCVTech.aspx

Of course, Amber Path FX, creates AOCV tables that can be used along with these tools. (Cadence requires some minor format changes in the AOCV file.) We use design specific statistical information as well as location and cell specific derating factors in our variance engine to build the tables.

We’ve been working closely with TSMC for a while now to provide a very fast solution for SBOCV table generation.  Earlier this year, TSMC told us it took them 3 weeks to create  tables for 30 simple cells using a commercial version of SPICE.  That wasn’t 1 copy of SPICE – it was 120. The looming problem is that some of the more complex cells in the TSMC libraries have as many transistors as the 30 simple cells combined.  As the complexity and transistor count of cells increases so does the simulation time.

Clearly, TSMC and our other customers want to generate tables for more than a small subset of the cells in their libraries. When compared to SPICE, Amber Path FX is blazingly fast.  However, our own testing and feedback from TSMC was that finishing a whole library with Amber Path FX was still taking too long.

So how did we make table generation 100x faster than our June release?  We’ll we broke the problem in to two different questions. How can we make our fast transistor simulation even faster? And how can we take advantage of the commodity hardware we have at our disposal?

The answer to the first question was mainly solved with good old fashioned software engineering – profiling, testing, optimization, and plenty of trial and error.  Throw in some heuristics for good measure and we were able to reduce the simulation time for complex cells by an order of magnitude. That’s a tremendous improvement but still not enough to get the kind of turnaround times we were looking for. The benefit of this work is that we now have a great set of data to continue to improve performance in the coming months.

The answer to the 2nd question seems obvious now but it took a little while for us to realize how well it would turn out.  Amber Path FX was already multi-threaded.  We have a bunch of 4 and 8 CPU machines in our server farm and a few 16 CPU machines.  The software scales nicely on a single machine.  But what would happen if we could get more than 1 machine working on the problem at a time?  It turns out that making the software multi-threaded to start with had laid a good foundation for distributed computing as well.

We turned the distributed version of Amber Path FX SBOCV table generator loose over the weekend using 15 of our 8 CPU machines (120 total CPUS).  The results: total run time of 3 hours, 50 mins, and 7 seconds for 852 cells.

We think that Amber Path FX is going to be a great answer to the “Where doe we get AOCV tables?” question.  If you are seriously looking at adding SBOCV/AOCV to your static timing flow we’d love to share our results with you.

He is right that the big EDA companies seem to be mostly watching from the sidelines.  It is the small EDA companies that are pushing forward with innovations around variation.  Ed asserts that it’s “difficult stuff”.  We agree; especially if you are trying to deliver practical solutions.

For example, we have worked closely with TSMC for more than 2 years building a high accuracy static timing tool based upon transistor level models and a very novel, high performance approach to statistical calculations.  Think accuracy of Monte Carlo SPICE but with hundreds of thousands of paths per hour.

The result of that collaboration - Amber Path FX – was just announced this spring.

We’ve just introduced something that does just that.  Amber Path FX is a new take on statistical STA.  It’s the first practical tool for getting SPICE accurate timing results at 40nm and below.  It’s not quite report_timing -with_spice_accuracy -and_statistical -fast, but it’s close.

What did we do differently than everyone else?

Well, first, we decided that rather than trying to replace your static timing environment we’d simply enhance it.  You still run PrimeTime (or whatever) to find your critical paths.

Then you source a simple Tcl script and run an extra command – still within your STA flow.  The new command passes the critical paths to Amber Path FX for a detailed analysis.  Once the analysis is complete you get SDF and timing reports that reflect the new, more accurate delays.

Second, we use a fast transistor level model of the cells used in your design and do a novel statistical analysis on each path. This is like running Monte Carlo SPICE on all your critical paths without the hassle of setting up the SPICE simulations.

Finally, we do all of this using our fast, multi-threaded, static timing engine, so that we can handle hundreds of thousands of paths per hour. Monte Carlo SPICE is accurate but it isn’t practical for more than a handful of critical paths.  With Amber Path FX you can pick out thousands or even hundreds of thousands of paths to look at.

We invite you to check out more of Amber Path FX at clkda.com and download a free evaluation.

Digital engineers working in the world of 40nm and below are focused on quality and productivity like never before, but truth be told there’s more to be done. Because of the inherent process variation in 40nm, designers are sacrificing performance, area and power.

Traditional corner based static timing methods are too conservative, and existing statistical solutions like Monte Carlo SPICE are so painfully slow that only a small number of timing violations or power saving methods can be evaluated.

As a result, engineers are not realizing the full benefit of TSMC’s manufacturing capabilities. Some estimate that 20% or more of a 40nm design’s performance is never utilized by using corner based approaches.

If SPICE accuracy delay and variance analysis is important to your digital product’s future, I invite you to try Amber Path FX by signing up for our free 30-day trial. Meanwhile, I am pleased to announce that we’ll be at DAC (Design Automation Conference) this June, and I invite you to visit with us in booth #373. We look forward to showing you what a difference speed can make in your own product’s design.