( ESNUG 503 Item 4 ) -------------------------------------------- [05/04/12]
From: Mike Kappes <kappes=user domain=iqanalog got calm>
Subject: A hands-on analog designer defends Analog Rails to its critics
Hi, John,
I enjoy your posts but after reading ESNUG 494 #3 about Analog Rails
from [ The Cheshire Cat ], I felt a rebuttal was in order to defend what
WE like about the tool.
But first let me tell you where I come from.
Our company (IQ-Analog) is perhaps not a typical user. We are hardcore
analog designers. We develop cutting edge analog technology in advanced
CMOS processes. We are concerned about every facet of our development
methodology:
device models, extraction, simulator accuracy, etc.
We have always done our own layout.
Our view of Analog Rails is that it is the future of analog design. We
want to worry about topologies, not device sizing and not layout polygons.
The existing extraction and simulation tools can handle the verification
of automated layout placement and device optimization.
Removing the custom hand layout effort is a huge time-saver.
Because we already trust our existing extraction and simulation tools,
we can be sure the Analog Rails generated layout is sound. If we find
issues, we add constraints to the router (allowed IR drop is X, etc.)
and let the Analog Rails' optimizer update the layout. Instead of doing
all the manual work, we want to impart our knowledge into the tool. This
pays off when there are subtle changes to the design - a new process, a
different performance target, etc.
I have more comments below:
> The Analog Rails tool presented at DAC 2011 is their first version where
> everything finally works, the placer and the router.
>
> This is not a tool for an average user, and not one for "architecture
> exploration" either. Due to the fact that it's "correct-by-construction"
> PnR for devices, all is controlled by Cliff's opinion about how things
> have to be.
>
> - [ The Cheshire Cat ]
> http://www.deepchip.com/items/0494-03.html
In general, we've found that Cliff's assumptions and considerations are
usually quite accurate. When we have disagreed and effectively argued our
position, Cliff's team listened and applied updates in line with our needs.
> The user has no power to alter any layout after the fact, within the
> Analog Rails environment. If you take it out to modify it, all liaison
> between schematic, simulation and layout is gone.
True - but the constraints in Analog Rails can be modified so custom
modification should not be needed. The tool is great at core designs.
It can use hard macros of, say, a VCO or amplifier. You don't need to
automate everything if you don't want to.
> In Analog Rails you can play in schematics but not in layout. Pretty much
> the same concept as the original GDT from Mentor Graphics, 20 years ago.
As a user of GDT, I can attest that comparing GDT to Analog Rails is like
comparing FORTRAN to modern C++ or Java. There is a lot more intelligence
built into modern languages, the same is true of Analog Rails.
> (For some of you old enough to remember this is "single pass design", as
> advertised a few years ago by a company called Monterey. They developed
> the concept for digital. Analog Rails is the analog version.)
If only analog design could be as simple as digital and just have to worry
about timing. Analog design is always a multi-dimensional optimization
effort, gain, linearity, bandwidth, etc. across PVT etc. is a much toughe
problem.
> You enter the inputs and the Analog Rail tool decides for you everything
> else. The placer is a topological implementation of the schematic, so if
> your box has a different shape in layout, tough luck!
We have used Analog Rails to constrain a layout within a specified LEF.
This is a key feature that enables top level floorplanning. The nice thing
about AR is that the floorplan can be modified and layouts regenerated
without complaint.
> The router is GRIDDED but not at process level (e.g. 0.1 microns), but an
> arbitrary grid to make the routes far away and non-interfering to each
> other... Even if wrong, the user cannot modify it. No real process
> knowledge, if you do 0.25, 0.18 or 40 nm, the routes will look and feel
> the same... No electromigration or IR drop knowledge, but it can be
> driven from schematics as WIDTHS.
The handling of wire widths for electromigration is automatically managed
through DC sims which calculate DC currents. Additionally, allowed IR drops
can be pre-set so the router will optimize the metalization without waste.
It's common to always stuff extra metal for supplies "just in case", because
it "can't hurt". This is overdesign. If you believe the extraction and the
simulator - you can trust Analog Rail's layout placement is OK.
> Also, it doesn't read process constraints from a PDK.
The PSK development is a service the Analog Rails team provides on request.
I believe they have many of the mainstream processes covered already.
> Until the Analog Rails tool allows users to make total or incremental
> changes at device placement level, routing level, and ECO level; it is
> not a main stream tool to use.
Automation is the future. It will enable huge productivity gains. Why not
embrace this and support the tools development? Our U.S. job future is
dependent on creative minds. We can't "out-crank" other engineering teams
that outnumber us 10-1. Analog Rails is a game changer that levels the
playing field for U.S. engineers. We (all of US) need the innovation
resulting from the hard work of companies like Analog Rails. Let's just
hope Analog Rails has no intention of selling this to our Taiwan/China/India
counterparts.
I write this rebuttal as a hands-on analog designer.
- Mike Kappes
IQ-Analog Corp. San Diego, CA
Join
Index
Next->Item
|
|
