Monday, July 21, 2008

Analog Rails - Thoughts from a Cad Manager

Analog Rails


Last week myself and a senior member of my staff were invited to a hands-on look of Analog Rails. Analog Rails is company whose focus is to "create the best analog and RF environment for the IC circuit designer". The system is built upon Open Access and gives an analog design engineer the complete ability to do both schematic capture, simulation and layout. It nicely automates the more tedious aspects of analog layout while giving the design engineer the complete flexibilty. For example the process of both matching (common-centroid anyone) and wire-widening (based on via size) is done in very automated push button method.






























In the last several months Analog Rails have really stepped up the development by starting to integrate with outside tools. For example they now integrated in Veritools into the design framework. This is a big step because it implies that they designed a flexible subsystem which is critical - there is no single solution in IC Design. I would like to see spectre ( -turbo of course ) and calibre integrated but it's not there yet.

Throughout the discussion / demo I began to understand the impact of this. Of course it's built on OA and will nicely integrate with Cadence and many many others, but something more interesting is afoot. This tool represents a clear methodology shift.. ..The demise of the block level analog layout engineer. Why? First as I said earlier, the layout automation piece is very intuitive and friendly. Plus the smaller technology geometries that analog design is pushing into (<90nm) is forcing simulation earlier (using Cadence) to account for device parasitics (LOD). So the analog engineer is already doing a fair amount of the placement and letting the layout guy clean up the work. But this tool is correct by construction and so the layout is clean from the get-go. So involving a layout person to "clean it up" isn't necessary. There will still need to be layout for macro / chip level integration but block level layout could (will) be going the way of hand-LVS.

There are areas which need to be better defined. From a cad managers perspective - I look at flexibility and integration. The flexibility to align the tool to corporate goals and strategy, and the hooks necessary to integrate it into my existing flow, and (perhaps) migration to this tool.

The flexibility of the tool is fundamentally there but needs better definition. For example: If the company has it's own fab, and the strategy is to use its own fab, how will this tool which claims to not need a PDK get the design constraints from my foundry into their system? The converse is also true - I am a fabless company with a strategy to tape-out to the lowest cost foundry - how do I ensure that the constraints from Dongbu will work with my design. The point is while Analog Rails clearly has the framework so support this, they need to have a clear methodology for how to implement design constraints which the customer may use or opt to use the defaults from Analog Rails.

[UPDATE]: I did receive a bunch of documentation on the methodology for creating these techfiles. It is pretty straight forward and not as difficult as I had imagined.

From the integration side it was better defined but still lacks the clarity for migration. Because the tool can work on OA it should "just work". But how does this system work when an existing layout done in Virtuoso or Laker which doesn't or isn't correct by construction adapt itself? We spoke of the "dummy mode" but I think a bit more clarity on this would be helpful. I not sure this is show stopper - because it would depend on the use model. If you define your flow/methodology such that this is the sole block level tool for a project it could work. If you want to do a mix - well that would have to be tested.

Overall I was very impressed. The tool has certainly matured over the last year. It's flexible sub-system and the ability to tie into other tools gives me reason to want to look further at the tool. It will be a real test to see this tool integrate with the work horses of the IC Design tools, and how easy it is to define a methodology around the tool. Again this tool has some really cool technology under the hood and should make for a fun evaluation. My concern (as any cad manager has) is that our designers are going to eat this up and really want it. That's a good problem to have.

10 comments:

Marketing EDA said...

I've been watching Analog Rails for over a year, so it was interesting to read your review. I'm curious if the promised productivity improvement is enough to justify buying a copy and placing it in your analog flow.

Anonymous said...

Unfortunately, manager of Analog Rails underestimates the complexity of the design rule problem. Analog Rails implemented only few simplest design rules in the product - just a small fraction of what Calibre can check for. They hope to satisfy any advanced design rools by setting additional margin for simple rules and their point was that nobody really use advanced design rules, implemented in Calibre. I worked in design rule area for the Ciranova and I am sure that the design rule approach of Analog Rails will not work well - design rules really are very complicated issue.

Analog Rail product produce design for which simple design rules are satisfied. Unfortunately, below 90 nanometers this might not be enough.

If you are planning to evaluate Analog Rail product, compare it with Ciranova Helix first, which do not take simplified uproach to design rule problem.

Cliff Wiener said...

Alexey

How do you know what we are doing? You have never evaluated our tool. You interviewed with us for 1 HOUR over a year ago (near the beginning of our editor implementation) and you have no idea how we are doing the design rules. Of course we handle the design rules.

You do not even understand the basic usage of our tools. Analog Rails is an automated and semi-automated tool, NOT a polygon pushing tool. That is how we do correct-by construction. The user is not allowed to make 11 degree angles for example, so we don't have to worry about that rule. It is not possible to get caught into a situation of an Nth order rule. The editor forces correct by construction layouts.

Does Ciranova have routers? We have both grid and offgrid.
Does Ciranova have a schematic capture tool?
Does Ciranova have a simulation environment?
Does Ciranova use simulation information for sizing of the wires?
Does Ciranova have digital place and route?
Does Ciranova have a push button complete automated layout?
Does Ciranova have build in pcells and differential pcells that don't require scripting?
Does Ciranova have a complete layout editor?
Does Ciranova have parasitic extraction?
Does Ciranova have optimization?

Your information is coming out of your ass. You are throwing out FUD and have no clue as to what we have and what we are doing.

We understand the complexity of the design rules and we thus simplified the problem with our correct by construction tool. This is exactly why we did what we did. Just because YOU were unable to grasp the design rules and simplify doesn't mean it cannot be done. KISS: Keep it simple, stupid.

Cliff Wiener
"Manager"
Analog Rails / Get2spec, Inc.

Cliff Wiener said...

Sometimes the situation is only a problem because it is looked at in a certain way. Looked at in another way, the right course of action may be so obvious that the problem no longer exists.--Edward de Bono

Steffi said...

Thank you for posting such a useful, impressive and a wicked article./Wow.. looking good!



Construction Tool

Whitchurch said...
This comment has been removed by the author.
Chuck said...

Analog Rails is built around automation. We have a very powerful manual editor built into it, but we do not allow users to break the automation and synchronization. What would the point of that be unless you wanted another system that takes months to build analog blocks instead of days - like our system provides.

I challenge your remarks on vaporware. The results of our tool worked on silicon. I also challenge your remarks on not being able to migrate to newer technologies faster. The user can put the layers and distances into the tech file without having to write thousands of lines of code to control the pcells.

Oh yea...we are also working with the OA database natively.

Chuck Wiener, Business Development, Analog Rails.

intercad said...

what are the most used CAD programs used in the architectural/civil fields?

Solidworks Course

Unknown said...

Very useful for CAD Community.Chip level training in hyderabad

Unknown said...

Cliff Wiener stiffed me out of my last ten days pay.

Perhaps I should have been more wary when his very first email to me, before I hired on, was "Don't worry about the lawsuits". This because he'd ripped off Zeni 4 from its developers in China, reverse-engineered its license server, yet somehow got the Chinese to agree to a contract which gave him the legal right to do that.

My own job was at first to write the physical design tool, but after working on that for a few days, he instead asked me to reverse engineer the Zeni 4 design files, which are very complex binary documents.

He had the idea that one could reverse engineer the Zeni 4 docs "with ten lines of Perl". I worked twenty hours of per day for a solid month, and succeeded in documenting all but the flight lines of the Zeni 4 physical design - by writing thousands of lines of C++.

Every single day, he'd give me grief for not having just written those ten lines of Perl. Clearly Cliff does not know how file format reverse engineering is actually accomplished. I myself have quite a lot of experience with just that.

Had he not been such an overbearing, micromanaging "manager", the product would have shipped by 2006.

He also would not have needed to finance his company by writing software for travel agents. He would not even have needed investment.