Get email delivery of the Cadence blog featured here
A lunch panel at the recent Design Automation Conference
provided an inside look at Silicon Realization challenges from a foundry, IP
provider, EDA supplier, and EDA user perspective. The panel, moderated by
Cadence CMO John Bruggeman, focused heavily on mixed-signal design issues and
A reminder: As described in the EDA360 vision paper, Silicon
Realization includes everything it takes to get a design into silicon, be it an
SoC or an IP block. Since essentially all SoCs are mixed-signal, Silicon
Realization encompasses both analog and digital design. As described in a recent
Q&A interview, Silicon Realization is about 1) unified design intent,
2) raising the abstraction level, and 3) convergence of top-down and bottom-up
Panelists were as follows, as shown from left to right in
Following are some of the answers to questions asked by
Q: What challenges
are you encountering at lower process nodes?
Kengen: The number
of applications is really growing and is driving the product definition, and to
an extent is driving the process node. The product life is getting shorter but
development cycles are getting longer than the product life itself. I really
see this as a major challenge.
Rael: Each time
we move to a new node they expect the whole chip will shrink, resulting in
lower cost and more functionality. But, while it's obvious the digital will
scale, it's not obvious analog and RF will scale. For example, we have inductors,
capacitors, and filters, and those don't scale. We've found that 65 nm is the
best process to support RF and analog. Smaller technologies have smaller
dimensions, but we don't get the high speeds. We have to re-architect our
entire circuit to bring in more digital calibration and clock generation.
IP designers are faced with huge problems as people move to new process nodes,
because of the granularity and the limitations of the devices we can use.
Unless you capture the physical aspects of the design up front, the cycle
between up-front design and physical implementation will turn into a vicious
impact on EDA is substantial [lower process nodes]. At advanced nodes, the
interaction of a number of issues can cause failure, and many issues need to be
verified. It's not just functional verification; it's electrical and physical
verification. Power intent needs to be looked at from the system architectural
You can't have a siloed approach where design, verification
and implementation are separate and you just throw it over the wall. There
needs to be a communication of design intent and an ability to abstract the
design behavior across different phases of the design.
Q: How do you balance
time, cost, and quality as you go to lower process nodes?
Jones: First we
have to define what quality is. Quality is sending the first sample to the
customer, and having them be able to power up their system. From the
analog/mixed-signal side, the way we establish quality is very similar to
what's talked about in the digital world - you have to verify the device before
you ship to the customer. Getting rid of every bug through very, very thorough
verification testing is the key to quality.
It's also the key to reducing cost. The best way to reduce
development cost is to not do respins.
Q: A study shows that
25% of the cost at 65 nm is IP qualification. How can you help design teams
think more effectively about IP qualification?
Jones: We want to
do IC design once, along with IP qualification. If you do a respin you have to
do re-qualification. This really boils down to a way to start verification
early. If you can start running a full device-level simulation before the
analog designers release their designs, you are ahead. To help crunch the
development cycle, we use behavioral modeling for analog.
Q: How do you qualify
and verify IP for mixed-signal SoCs?
Real: We have to
work with both [analog and digital] teams to make sure they verify everything
properly and that functionality is what they expected. Doing straightforward
simulation is not practical, because analog tends to be small and really fast,
while digital tends to be big and slow. We get around this by using simple
behavioral digital models. This allows us to verify connections and
functionality. We have found a number of subtle bugs.
Q: How can EDA help
with IP integration?
Cadence, we approach it at two levels. We recently announced our Open Integration
Platform strategy, where we are working with vendors like Rapid Bridge
to enable the availability of integration-optimized IP. The other level is
enabling IP creation for our customers.
Q: What are you doing
to address power challenges?
Kengen: From the
process point of view, there's a lot of work going on. From an enablement point
of view, we're looking at multiple innovations. One involves design solutions
for minimizing power. We are looking at design solutions that are, in part,
connected to the process, such as channel length optimization. In the next
couple of months we will announce power enablement solutions.
Power optimization is critical at every step. From an EDA perspective, we can
provide a unified representation with a common power intent format. This not
only lets you optimize power, it also enables power verification in a
Jones: The most
difficult thing about power is that the most common low-power technique is to
shut down portions of the digital circuitry. You have power modes. If you're
running full device simulation you have to implement [power] supply awareness.
Digital simulators typically don't do that.
A Parting Comment
Benny Malek-Khosravi said something that caught my
attention. "There's talk of boundaries between analog and digital, but those boundaries
are made by us by looking at and categorizing the circuits. There's a huge
amount of analog knowledge that nobody has implemented in the digital world,
and vice versa." He went on to mention a closed-loop compensation approach that
Rapid Bridge uses to minimize power
in both analog and digital circuitry.
Have we created, through our terminology and innate desire
to order and categorize everything, a more rigid boundary between "analog" and
"digital" than there really needs to be?