Archive for January, 2009

Planet Analog recently published their list of the most popular articles of 2008 on the Design Center website. I’m not sure if the list is in order of popularity, but it is interesting to see “Opportunities in Analog Verification” right up there with all the digital stuff. The article was written by Saranyan Vigraham of Qualcomm, and the discussion thread which followed is also worth checking out.

One of the comments that stood out for me was Saranyan’s statement that

“the present EDA tools do not focus on methodologies.

Actually, it is not about the EDA companies, analog designers and chip leads have to bring a methodical approach to verifying their chips”

This goes to the point of my recent post on AMS Verification at ICCAD, and the comments that followed. I have said that EDA companies focus way too much on individual tools to the detriment of the complete flows required, especially in the analog/mixed-signal realm. But I also agree totally with Saranyan’s point that the expertise required resides more in the design teams themselves. Vendors and semiconductor companies alike would be more successful by establishing collaborative efforts to make the task of AMS verification less difficult. This is woefully lacking.

I was just listening in on the continuing Accellera AMS discussions for analog assertions this past Tuesday. When time came to ask for volunteers to develop a requirements document, the silence was near deafening. This committee is seriously lacking in a diversity of customer participation, but the EDA representatives were also reluctant to step forward. Everyone can make a case for the tough economic environment, but isn’t that the best reason of all to work closer together?  Or, should we just conclude that analog assertions aren’t that important?

If you don’t believe that, and you have something to say about what EDA vendors are or are not doing for you, then quit your bitching (hey it’s on m-w.com) and join the discussion. You can catch up on the past meetings by going to the Twiki at http://www.eda.org/twiki/bin/view.cgi/VerilogAMS/AmsAssertions.

-Mike

AMS verification
assertions
Accellera

Hello Everyone,

Time to kick things off with my first post of 2009. Excuse me for being a little late coming off the holidays, and from time spent on my (ongoing) search for new career opportunities. I hope that we all will share in a much better New Year!

This should be a good time to say “Out with the old… and in with the new”, and I can see from comments on my last post of 2008 (More comments on AMS Verification at ICCAD: modeling parasitic effects) that the “old” problem of handling parasitics in AMS designs may still be a critical area calling for new solutions. At least it warrants more discussion here.

In his recent comments, Dave Reynolds said:

“Mike, when I look at the parasitic problem, it seems that the analog portion of the mixed signal world is missing the flow that digital has. The digital guy gets rough estimates (think wireload models or equiv) and he can know very quickly if his design is likely to work when it gets to layout…. where is the equivelent on the analog side?”

Once the digital designer starts down the physical path, every tool he uses from a floor-planner to placer to router can all give him quick feedback about parasitics with increasing levels of accuracy and how they affect his design…. where is the equivalent flow on the analog side?

If the goal is to send up with a chip that works in a resource limited company (time is limited, $ are limited, people are limited) then to me the best answer is to work smarter and have a flow that gives you information as you go along, rather than the “the layout passes LVS, now you can back annotate and start running sims to see what happens”

Well Dave, you probably know how much I enjoy using digital as a benchmark for solving analog problems, but let’s look at how the two worlds compare here. Outside of hand-crafted custom digital, floor planning and place & route are standard components of digital implementation flows. In analog… not so much. Though I did read an interesting article just yesterday on SCD Source, from Scott Sandler of SpringSoft (Custom IC design automation – it’s time to get practical), in which he said:

“…transistor-level routing, floorplanning, and custom placement techniques are available and deployed“

An early view of wire-length estimates from floor planners provides the information needed for delay calculators in digital flows. There is no reason that length calculations can’t also be used to provide a lumped RC estimate for use in analog simulations. But, as is usually the case, the analog problem is much more complex. For digital – delay calculation may suffice, possibly with the addition of IR drop estimates on the power/ground buses. In analog, you still need to do the simulations with the estimated parasitics, since verifying circuit behavior has many more dimensions and numerous performance specifications beyond simply estimating delay.

I think it is critical to always have algorithmic device parasitic estimates in your SPICE .MODEL library for pre-layout simulations. In my experience, companies with well-established CAD flows do this as a matter of routine and/or the foundries add this information to their PDKs. Layout solutions such as Cadence’s Virtuoso also have parasitic estimators. (I’m not sure if this capability is in Synopsys’ Custom Designer at this point). But I have still seen too many designers doing meaningless ideal simulations with all their AD/AS/PD/PS parameters set to the zero default value. Why would you EVER waste time doing do a simulation that bears absolutely no semblance to reality?

So… my answer to “where is the equivalent on the analog side” is that some underutilized capabilities exist, and I agree with you that users need a rigorous methodology and flow, particularly to apply parasitics starting from the pre-layout phase of an AMS design. Nothing though, in my opinion, will ever make it as easy as digital because…. well… Because digital design is so easy! and Analog design is NOT black magic… but it is VERY hard.

Dave concluded his comments with:

Mike, what do you think is needed to enable the mixed signal community to have a flow that manages parastics rather than reacts to them?

I feel something like a broken record on this one, but my challenge to all EDA companies and the user community together is to look at the broader scope of the problem that needs to be solved, rather than focusing on individual tools. Neither party can create meaningful flows on their own.

I called for…

an initiative to create a verification equivalent to the OpenAccess Interoperable PDK Library industry alliance…

in my post on AMS Verification at ICCAD that started this discussion. But the problem is larger than that, because there is no holistic view in any EDA company: analog is separated from digital, verification is separated from implementation, extraction is separated from simulation, etc…

Long long ago (hence “Auld Lang Syne”?), there was no EDA industry. To be successful a semiconductor company had to develop its own flows and often develop their own tools as well. This was not efficient, but it was singularly focused on the job at hand… producing working silicon.

Eventually, Moore’s Law provided the opportunity for bigger, more complex designs. The challenges to develop tools that could support what silicon had enabled grew exponentially as a result. (Remember when the hot topic of discussion was… “what will we do with all those transistors“?). Economies of scale dictated that CAD solutions had a greater value in serving an entire industry, rather than one company. CAD was essentially outsourced and EDA was born!

But now, things have swung too far in the opposite direction, and there are too many silos within EDA companies. Where a semiconductor company in the old days had one CAD department and one flow, EDA companies have multiple business units and isolated product lines. Who can tie it all together?

To be clear, as I have said before, the EDA companies are not solely responsible for this state of affairs. Customers are just as responsible for not working with the EDA companies to develop holistic flows. It’s a tough problem. Nobody wants to let their proprietary designs out the door. I’ve been in the situation many times… how to debug a problem when the customer won’t give you the test case? EDA companies are made up of computer scientists, don’t expect the knowledge to develop a complex design or create a flow to reside there.

Can we make it better? I may be idealistic, but I believe we (tools users and vendors) can together; through collaboration based on recognition of the mutual benefits to be derived. But I’m not so naive as to expect this will happen anytime soon, especially in this economic environment.

As always.. I welcome your thoughts, suggestions, comments…

Here’s to 2009. Change is good!

-Mike

AMS verification
parasitics
design flows
EDA