IC EDA tools

[Special K]

Why do EDA tools for integrated circuits have such horrible GUIs, and why are they so prone to crashing? I am in a VLSI design class and am using tools from Cadence, Mentor, and Synopsys, and these tools seem to have the ugliest and most confusing interfaces I have ever seen. Most settings can't even be changed in the GUI, you have to create scripts. In addition, these programs seem to crash even more than win9x ever did. Also why don't any of these tools support winNT/XP? They also never seem to be capable of displaying layout graphics correctly. There are always colors that cannot be displayed, blocks that are mysteriously invisible and cannot be viewed, etc.

I would think that these tools could be created with user friendly interfaces that don't crash all the time, because I have used FPGA design software under windows that does essentially the same thing as synthesis and place+route tools do for ICs.

In short, EDA tools seem like they were patched together in a short period of time and rushed out the door with little debugging. Does anyone else have any thoughts on this?

This topic isn't strictly technical but I figured all of the people who have experience with these tools probably hang out in here.

 

[djhuber82]

Hmm... I use cadence IC design tools at school and they don't crash that often, but they do crash. If you're seeing lots of crashes it might have something to do with the system setup. I agree the GUIs are definately craptastic though. From what I here many designers in industry don't even use the GUIs because they loath them so; they script everything like you mentioned. As for displaying layout, I've seen people have problems with this but it usually seems related to video drivers or improper settings. A lot of things get blamed on improper settings, and it's not like you can go to Tools->Settings to fix it, you have to track down a dotfile somewhere and fiddle with envoronment variables. But this is the UNIX way. I don't know why they don't make this stuff for Windows, but my first guess would be licsensing. UNIX is good at multiple users, so you can have fewer machines running the design software than if you were running windows.

 

[RaynorWolfcastle]

Originally posted by: djhuber82
Hmm... I use cadence IC design tools at school and they don't crash that often, but they do crash. If you're seeing lots of crashes it might have something to do with the system setup. I agree the GUIs are definately craptastic though. From what I here many designers in industry don't even use the GUIs because they loath them so; they script everything like you mentioned. As for displaying layout, I've seen people have problems with this but it usually seems related to video drivers or improper settings. A lot of things get blamed on improper settings, and it's not like you can go to Tools->Settings to fix it, you have to track down a dotfile somewhere and fiddle with envoronment variables. But this is the UNIX way. I don't know why they don't make this stuff for Windows, but my first guess would be licsensing. UNIX is good at multiple users, so you can have fewer machines running the design software than if you were running windows.

Licensing is probably why they don't make Windows versions of these tools. I'm not sure of the exact cost of running Cadence or Mentor, but I am quite sure it costs a mint. When I was using Cadence Virtuoso last semester, they had everything running from Solaris servers that and we had to SSH into them to use them.

Also, I don't know if you've ever seen the models they use for deep-submicron transistors these days but with the number of parameters for each transistor, I'm surprised this software doesn't crash more often. Seriously, try reading through the BSIM3 model of a transistor, it's an absolute mess.

 

[helpme]

The look and feel of the applications are the way they are because it's an Xwindows application (That's just the way they look and feel). I doubt the companies have a reason to port to windows since the software 'works' fine on Linux/Solaris.

 

[pm]

As a long-time user of EDA tools for IC design, I have a couple of comments. First, the EDA tools that I use and have used in the recent past, don't crash - pretty much absolutely never unless I'm doing something really weird or stupid - like trying to pull up the layout design for several million transistors completely flat, or running some recursive macro that I didn't think through thoroughly. In my experience, barring the occassional mistake by the develops where they release a poorly validated release, they don't have graphical problems, they don't leave things out. They are mostly designed in-house, or designed by a vendor and then supported locally.

Then we move on to my personal preferences, but I think that a lot of the long-time engineers think like I do... certainly the ones that I work with share my preferences.

I don't like complex or pretty GUI's for IC design. They are good for approachability, but once you know the system, people rapidly move on to more productive ways to access functions. Navigating a menu tree is nowhere near as efficient as an arcane key combination, or a custom-created macro, or even mouse-based gestures. In fact, I mostly use Perl (or Python) scripts to generate schematic hierarchy automatically and then make minor changes using the GUI. It's hard to learn this kind of stuff - it makes it really hard to ramp newhires up - but it's vastly more productive. For me, a GUI should graphically show me what I'm working on and then avoid interfering with me as much as possible. I want speed to draw large complex objects and allow me to pan and zoom extremely quickly, a large working area, minimal intrusion by the GUI itself. I want the interface to be easily extensible, easily customizable, easily macro'able, and to write and read data in both a highly compressed format as well as an easily modifyable ASCII format. I want to be able to write highly complex scripts to automate tasks and be able to easily integrate them into the GUI with little to no pain.

The systems that I like for schematic capture and layout design (polygon pushing) tend towards the very ugly-looking - minimal colors, very high speed, with a small command set that can be used to build very complex macro systems. I really liked the version of PIGLET that I used a few years back - link to a Linux port of Piglet. Most people would look at it and wrinkle their nose and say, "ugh, that's awful. That looks like something from the early 80's." But Piglet is a good example of what I prefer in a GUI. Note the size of the interface panel (not visible in most shots), the lack of colors, line-based... it's fast. Super fast. If you are loading up the top level clock distribution route for a monster chip like Montecito, you want something that's screaming fast. The original Piglet that I used was highly integratable with Perl. If you hypothetically needed to go through 8 levels of hierarchy and 50 schematics total and change 128 signal names from a name starting with "fpu" and change them all to start with "idp" because someone decided that your FPU circuit needs to be ported to the IDP, that's all of about 2 minutes (including coding, writing, and executing) for an experienced Perl/Piglet user. Now that's efficient and highly productive. I've seen CAD tools, where you need to click each signal individually, right-click, choose "rename", type the new name in and move on. That could take literally days. And if you want to automate it, you need to write, compile and debug a LISP or MainSail program to do it for you. I've seen people who like LISP (although I have yet to see someone who likes Mailsail ), but even they would concede that Perl is a vastly better choice for a one-off task like this.

I do not like working under Windows - I don't like the way scripting is handled, I don't like the security of the file system, I don't like the inability to easily batch jobs off, I don't like the overhead that the OS seems to add to things. Loading Cygwin onto Windows helps with many of my complaints, but then leaves me wondering why we don't just run Unix instead. For example, you are working in the GUI and you want to run a mammoth full runset DRC (design rule check) job on everything that you've done to check for subtle mistakes. This is likely to take a while and chew on a lot of resources, so you don't want to run it on your machine. You think, I'll run it on my friend Joe's box because he's off skiing today. Under Linux this takes all of one command line - probably alias'd up except for the machine name - and takes less time to kick off the script to execute the job than it takes to figure out a good machine to run it on. I still haven't found a good way to do something like this in Windows. I'd have to rdesktop in, log in, wait for the OS to log me in and mount my drives, wait some more, pull up the command line, and type out a long command line to execute the command.

Several times there have been pushes to get the engineers at Intel to migrate to Windows for CAD work. They file us all into a large conference room and show us the "next generation EDA tools" in some glorious Powerpoint slideset and then at the end someone asks "That looks like Windows XP? This will all be available under Linux?" and if the answer is "no" then it's time to break out the bodyguards and the asbestos flamesuit. Still, I am seeing a gradual, slow and grudging migration towards Windows by EDA tools. Mostly fought "tooth and nail" by the vast majority of the engineers.

Patrick Mahoney
Microprocessor Design Engineer
Intel Corp.
Fort Collins, CO

 

[SamurAchzar]

Most software has evolved over the years. Now, most consumer software has the same look and feel, with similar layout. That is, in essence, what you call "intuitive".

The strictly professional tools, however, follow a different path. It's not a software you use occasionally, it's a tool, and as such, you have to learn how to use it, but when you do, it's much more powerful than normal software. Not always more convenient, though.

A good example I have is Lauterbach debugging tools. They are a very well known German company building software debuggers for embedded targets as well as the accompanying software for a long time now.

My company has universally adopted their suites, despite their high price.
Their software is very well evolved and has every feature you can possibly think of, but the GUI feels like it's stuck in the Windows 3.1 days, it's far from intuitive and very script-oriented. I can't stand it, but there are certain things in very high scale projects you just can't accomplish with lesser - yet prettier, easier, sleeker - tools.

Another case is software build environments. Most large projects use a combination of several command line tools for compilation, not just one IDE (such as Visual Studio).
Clumsy, yea, difficult to learn, sure, but there are things you just can't... and so on

That's a repeating theme you'll find with any professional tool, not just EDA.

 

[Special K]

Thanks for the info pm. I guess it's just hard for me to see those advantages right now probably because the designs we are working with just aren't big enough to take advantage of the scripting capabilities of the tools. We were basically given barebones scripts at the beginning of the class and really haven't had to modify them too much for our projects, so from my perspective the scripts are a pain and the GUI is severely lacking. Although lately as we have been running DRC/LVS, there is a very specific flow to this procedure and it gets annoying when someone makes a minor change to the design, then I have to export file A, export file B, load the DRC tool, configure the options, run it, repeat for LVS, etc. I figure there must be a way to automate that sort of thing, since the commands never change from one run to the next.

 

[pm]

Originally posted by: Special K
Thanks for the info pm. I guess it's just hard for me to see those advantages right now probably because the designs we are working with just aren't big enough to take advantage of the scripting capabilities of the tools. We were basically given barebones scripts at the beginning of the class and really haven't had to modify them too much for our projects, so from my perspective the scripts are a pain and the GUI is severely lacking. Although lately as we have been running DRC/LVS, there is a very specific flow to this procedure and it gets annoying when someone makes a minor change to the design, then I have to export file A, export file B, load the DRC tool, configure the options, run it, repeat for LVS, etc. I figure there must be a way to automate that sort of thing, since the commands never change from one run to the next.

To some extent it's preference. I know what I like - and to each his/her own.

But yeah, in something like Piglet, you'd just add something like:
MACRO DRC= {
export file A;
export file B;
run the DRC command from a massive Unix command line with switches;
repeat for LVS;
}

And then go into the piglet_menu.ini file and add a line for a DRC button, and then exit piglet and reload and there's your new DRC command. And if you didn't want to click on the interface for your new command, you could type it in the command line. And if you didn't want to type out three letters (and a semicolon) and hit return because that would take too long, you could assign a key combo to it and hit control-alt-D. And if you didn't want to have to memorize that you coud hold down the middle mouse button and draw something akin to a letter "D" with the mouse over the top of the GUI and it would interpret this hand-written "gesture" letter as a DRC command and run it.

It's hard to fall in love with a GUI so ugly, but it didn't take me long before I saw how awesome this system was.

I could give so many examples of so many things that I remember automating that would have been so many days of tedious work, and instead was a somewhat fun couple of hours figuring out a script to do the work for me. I'd rather wrack my brains trying to cleverly write a script to do something than monotonously click-click-click on the GUI all day.

But this all departs from your original point. In my opinion, you are just using the wrong CAD software. Although I'm not sure that something that is really used for IC design would make the right impression on college students. They'd either be disgusted with the apparent primativeness of it, or intimidated by the flexibility once they dove a little deeper.

 

[Special K]

Originally posted by: pm

Originally posted by: Special K
Thanks for the info pm. I guess it's just hard for me to see those advantages right now probably because the designs we are working with just aren't big enough to take advantage of the scripting capabilities of the tools. We were basically given barebones scripts at the beginning of the class and really haven't had to modify them too much for our projects, so from my perspective the scripts are a pain and the GUI is severely lacking. Although lately as we have been running DRC/LVS, there is a very specific flow to this procedure and it gets annoying when someone makes a minor change to the design, then I have to export file A, export file B, load the DRC tool, configure the options, run it, repeat for LVS, etc. I figure there must be a way to automate that sort of thing, since the commands never change from one run to the next.

To some extent it's preference. I know what I like - and to each his/her own.

But yeah, in something like Piglet, you'd just add something like:
MACRO DRC= {
export file A;
export file B;
run the DRC command from a massive Unix command line with switches;
repeat for LVS;
}

And then go into the piglet_menu.ini file and add a line for a DRC button, and then exit piglet and reload and there's your new DRC command. And if you didn't want to click on the interface for your new command, you could type it in the command line. And if you didn't want to type out three letters (and a semicolon) and hit return because that would take too long, you could assign a key combo to it and hit control-alt-D. And if you didn't want to have to memorize that you coud hold down the middle mouse button and draw something akin to a letter "D" with the mouse over the top of the GUI and it would interpret this hand-written "gesture" letter as a DRC command and run it.

It's hard to fall in love with a GUI so ugly, but it didn't take me long before I saw how awesome this system was.

I could give so many examples of so many things that I remember automating that would have been so many days of tedious work, and instead was a somewhat fun couple of hours figuring out a script to do the work for me. I'd rather wrack my brains trying to cleverly write a script to do something than monotonously click-click-click on the GUI all day.

But this all departs from your original point. In my opinion, you are just using the wrong CAD software. Although I'm not sure that something that is really used for IC design would make the right impression on college students. They'd either be disgusted with the apparent primativeness of it, or intimidated by the flexibility once they dove a little deeper.

So other than Piglet, what design tools are commonly used at Intel? Do you use any of the tools from the biggest companies like Cadence, Mentor, Synopsys, etc.?

 

[CTho9305]

Do you use any of the tools from the biggest companies like Cadence, Mentor, Synopsys, etc/?

AMD uses tools from those companies (plus a bunch of in-house tools).