Last week I had the pleasure of
attending a DV Club lunch presentation from Dr. Henry Chang of Designers' Guide
Consulting on "What
the Digital Verification Engineer Needs to Know about Analog Verification".
The talk was very engaging, where Dr. Chang's comments on the relatively
primitive state of analog verification confirmed my observations in talking
with customers and Trailblazer partners. Specifically:
1 - In the eyes of digital verification
people, analog verification looks like digital verification circa 1990.
This isn't meant as a criticism of analog developers -- Dr.
Chang reviewed the many reasons why this gap exists, and why they
will likely persist for years into the future. For example, in order to
effectively support the hierarchical circuit construction methodologies
commonly used in the digital world, depending on the type circuit you are
simulating analog simulators would have to become literally 1,000,000 times
faster than they are today.
2 - Dr. Chang noted that very trivial,
functional A-D interface errors are depressingly common in mixed signal
designs. Even worse: such bugs are typically catastrophic (i.e. the chip
is dead-on-arrival from the fab)
3 - The level of automation vs.
the digital world is very low. Despite the growing complexity
of pure analog blocks, most design entry is still done with schematic capture
and not high-level design languages (although this is slowly changing).
Debug? It's all about eyeballing golden waveforms.
There was much more to the talk, but these three highlights stood out in my
mind because myself and my fellow Trailblazers have also seen 1, 2, and 3 in
our customer base. As such, I was "relieved" (in an ironic,
negative sense) to hear that an expert like Dr. Chang is seeing the same things
too. Do you out there in the blogsphere see all this too? Have you
seen any analog users overcome 1, 2, or 3?
In a vaguely related note:
Driving back to my office from the talk, I was also struck by an analogy to the
hardware/software co-verification space, where verification in this mixed
domain is also relatively primitive compared to pure digital
RTL verification. My colleague Jason
Andrews captures this issue nicely in his recent post "Is
anybody out there a Software Verification Engineer?"
In conclusion, I'd argue that at the 50,000ft level, issues 1 and 2 are factors
in both the AMS and HW/SW domains (and for issue 3, you have to admit there is
a lot of "bad" automation in the HW/SW domain; but that's the subject
of another blog post). The silver lining in these clouds is that the
hunger for automated, metric-driven solutions in the AMS space is growing, and
thus the EDA business has some future opportunities here whatever doldrums the
economy might be in today.
P.S. If you haven't been to one of these "DV Club" events, you are
really missing out. The format is typically an in depth talk on some
design or verification topic given over lunch, and the speakers have
always been very informative. These events also draw a good sized
audience (I've never seen less than 50 people at the Silicon
Valley area events I go to), so the networking is great.
Note that in addition to Silicon Valley, they hold these "lunch &
learns" in Austin, Bangalore,
Boston, Bristol UK, Dallas, RTP,
and San Diego.
Here is the DV Club events calendar for more info:
http://www.dvclub.org