The Java Electric CAD Tool

Print-friendly Version

After spending 21 years developing his Electric VLSI (Very Large Scale Integration) Design System (known as Electric) in C, Sun Microsystems Distinguished Engineer Steven M. Rubin decided to translate his creation into the Java language, starting in September 2003. The results are impressive. Java Electric is more stable, has a better user interface, and is in many ways faster than Electric in C.

We met with him to explore the challenges and rewards of converting Electric into Java code.

What were the big lessons you learned in translating Electric?

I was simultaneously learning the Java language and translating Electric, so I learned some lessons the hard way. I tried to learn as much as I could up front, and read Joshua Bloch's Effective Java to get the big concepts. It was very helpful. Bloch explained various ways to do things and why some made more sense than others. Nevertheless, it was inevitable that some early code would need to be rebuilt later. In any first implementation in any language you tend to make sloppy programming decisions.

"I was surprised that I could go beyond the functionality that I had in the C code because the Java language let me play around with the code much more easily than C ever did."

One example is the Design Rule Checker. I ported this code early on, and later realized that I had, in effect, created "C" code in the Java language, with many uses of "static" and little recognition of the power of objects. This was fairly easy to fix. By simply removing the keyword "static" from my classes and variables, I was able to make the Design Rule Checker into a self-contained object. Such an object could be instantiated multiple times to allow multiple checking threads to run at the same time.

We have used multi-threading quite extensively in Java Electric. In fact, every user's task runs in a separate thread. This not only promises a greater degree of parallelism, but also isolates code failures from affecting the overall system. Now, when an experimental piece of code crashes, only that thread dies, and the overall system continues to run. This has given even the early versions of Java Electric a level of stability that was never available in the C code.

Were there any big surprises?

Code Reduction The translation of Electric from C to Java code resulted in a substantial reduction from 366,683 lines in C, to 244,769 in Java code. While difficult to determine, the compression appears to be uniform. Rubin engaged in ad hoc processes to find out what he needed in Java libraries. The two most common were: (1) Gatekeepers -- asking Java experts and, (2) Web search -- typing the desired function into Google and getting the Java class name. Rubin confirmed that a function was correct simply by reading its documentation in the Javadoc. One important lesson Rubin was taught early on: Don't optimize. Just write the Java code, and optimize later if it becomes important.

I was surprised that I could go beyond the functionality that I had in the C code because the Java language let me play around with the code much more easily than C ever did. I didn't know that you could refactor and reorganize large chunks of code in the Java language. I was pretty much at or just a little behind C in my optimizations after a week. I had gone as far as I would normally have gone in any other language. If I had translated Electric from C to Bliss or to PL/1 or something similar, then I would have optimized, then optimized again, to get it to the point where it was more or less competitive with the old implementation. In Java Electric, however, I was able to put in new algorithms and ideas that had been difficult to do in C, and would have been difficult in any of these other languages. They would have required reorganizing the code massively, obtaining unusual access to the operating system, and moving bits around on the display.

The Java language helps you develop in so many ways. The Java virtual machine (JVM) technology, for instance, is right there to stop you when you make pointer and indexing mistakes, and errors like that. I was impressed by the quick compile-and-execute turnaround, since the JVM lets you test and refine and test and refine in a much faster loop than in C. [Note: The terms "Java Virtual Machine" and "JVM" mean a Virtual Machine for the Java platform.]

All of the packages were so helpful. At the beginning, I said to myself, "I am not going to reinvent all of the stuff that's in C Electric. I'm going to try to use as many things that are part of the basic Java software offering as possible." So, when I needed a transformation, I looked through the Java libraries. I found that indeed there is something called the AffineTransform, and I said, "I'm going to use this object. It's got to be the right way to do it." By using as much of the Java libraries as possible, I was also able to get the code up and running very quickly.

We began translating in September of 2003, with me, Dmitry Nadezhin, Jonathan Gainsley, and Russell Kao, at first, and then Gilda Garretón (who we hired later) working on it. It has been amazing. In one year, we've created a Java language version of Electric that is far superior to the old C version. By June of 2004, after 10 months, we had released an Open Source version of the GNU Electric, the Java Electric. The version we released in June is available now at the Free Software Foundation, free of charge on the web.

Downloading Electric VLSI Electric can be downloaded from gnu.org. Learn about Electric VLSI at staticfreesoft.com. Learn about the Electric VLSI Java language reimplementation.

In addition, before we started to recode Electric, back when it was just a C program, Mike Wessler of Sun Labs added a second database in Electric. Inside every running program is a database storing all of the information—the symbols, the wires, and so on. Mike wrote a second database in the C Electric code that actually is a Java virtual machine, a Java platform version of all these data structures. He was the first person to think about how Electric might look in Java code. He spent some time with us learning about Electric's data structures, and then built a data structure, which was the seed of Java Electric.

During the summer, the people in our group at Sun Labs converted from using C code to Java code so that, by September, they weren't using C any more. Enough of it is translated for the chip designers in our group to use it to actually design a chip. By the end of September, they completed a chip and sent it for fabrication. After one year, Java Electric has been used to successfully produce an integrated circuit. Translating Electric was a kind of test to see whether the concern that the Java language is less efficient than other languages is true. We're happy to report that it's not true.

Give us some background about Electric.

There are two interesting ideas in Electric. One is somewhat common, and the other is surprisingly uncommon. The common idea in Electric is that of constraint. When you draw wires on a board, you might put down an inverter gate—a little gate, a little symbol, and then another symbol somewhere else, and then run a wire between the two of them. This is a standard circuit design operation, a kind of schematic drawing, with symbols connected by wires that show how everything is held together. And what if you grab one of the symbols that have been wired and move it? The wire should adjust, shouldn't it? You wouldn't want the wire to stay floating out in space as if it wasn't really attached to that symbol. You want it to go with you.

"Translating Electric was a kind of test to see whether the concern that the Java language is less efficient than other languages is true. We're happy to report that it's not true."

There are many CAD system rules for constraining the drawing so that the drawing stays sensible while changes are being made. Electric not only has such a constraint system, but it is user programmable. It is a full constraint language that enables users to put properties on the wire, and say how they want these wires to hold their symbols together, and the circuit changes can apply up and down the hierarchy in far more areas of the circuit than is normally the case in other CAD systems. It has a number of other features like that. So, there's a powerful constraint system.

The second thing that Electric does, which other systems still don't do, is apply this notion of constraints to the actual integrated circuit layout. Here's the tricky part. When somebody draws schematics, they put a symbol here and a symbol there with wires and it looks like stick figures. But if you were to look at the actual integrated circuit, there are no symbols, and it doesn't look anything like stick figures. Instead, there's a piece of polysilicon with a certain width and height. And crossing it is a big piece of diffusion material and some metal and then some contact material. When you look at these integrated circuits on the CAD system screens, they're very colorful, because each layer is given a different color so that it's easily identifiable. And there are layers piled upon layers, with lots of colors and pretty patterns.

But a typical CAD system thinks of this as just paint. You actually have to sit and draw a rectangle and fill it in with one color and draw another rectangle of another color. If you were to take a component—let's say that you have a combination of three layers together on a transistor—it has one crossing another and something else right in the center where they cross to make a transistor. To the person using the CAD system (drawing an integrated circuit), it is three materials crossing each other. If you were to delete one of the materials, it would still look mostly the same. But it would not be a transistor when turned into a chip, because a layer would be missing.

Electric deals in high-level integrated circuit components that are actual symbols. We have a transistor symbol that has all three layers in it. You can't pull a layer off of that symbol. It is part of a single object that the user puts down on the screen. And the wires that connect these symbols have the same constraining rules. So, if I move the transistor, the wires go with it. Now, of course, these wires are big, fat areas of metal. Nevertheless, Electric handles that and makes drawing of the integrated circuit just as powerful as drawing on a schematic. That's what makes Electric interesting even today.

A test chip to extract wire models, designed by the Asynchronous Design Group of Sun Microsystems.

I understand that you decided to do the translation reluctantly.

I was pressured and persuaded to convert Electric to Java code. I wasn't convinced it was the thing to do, and I didn't become convinced until I began to use it. It was hard to justify translating a stable, 20-year-old large pile of code into a new language. But many people insisted that Electric could be much better in the Java language. It took a while before I finally realized that there would be some use in translating it.

"In one year we've created a Java language version of Electric that is far superior to the old C version."

Electric in C was portable and could run on any platform, similar to Java technology's "Write Once, Run Anywhere" feature. This was possible because I wrote separate operating system interface modules for all of the different operating systems: Macintosh OS 9.0, Windows MFC, and UNIX. On UNIX, there were three different worlds: Athena, Motif, and Qt widgets. Widget packages in UNIX are ways of interacting with the screen and the mouse, pulldown menus, and all those elements. I had basically a plug-in for any world that you wanted.

Then Apple released OS 10 and I needed to build a sixth interface module. That pushed me away from doing C. But, in addition, the display optimization—the thing that I got this incredible speed-up from—was something that would have been low level in these individual modules. In other words, I would have had to have written it five times. And I just couldn't face writing this software five times and debugging it on five different operating systems. Whereas I only had to do it once in Java code.

What were you initially concerned about?

I feared that Java Electric would be larger, slower, and less efficient than it was in C. The problem is that integrated circuit CAD systems make huge demands on your computer. We often use computer farms of many multiprocessors to run integrated circuit analysis jobs. It can take hours or days to do certain operations on these very large integrated circuits. If the program slows, it becomes even more unappealing if you are already annoyed with the CAD tools in the first place. So, it was essential that the Java code version not be slower than in C.

Where is Java Electric headed?

Rebuilding Electric in Java code offers two great opportunities. First, we can take the 20-year-old base of code and update it for modern chips. Many of the pieces in C Electric were outdated so, as we translate them, it gives us the opportunity to repair them. Second, we can grow Electric much faster now that it is coded in the Java language. This gives us the chance to make Electric much more powerful, and to make it an important tool for the next 20 years.

See Also

• Steven M. Rubin's Home Page
• Using the VLSI Design system
• Frequently Asked Questions: Getting to Know Electric
• Learn about Electric VLSI
• Learn about the Electric VLSI Java Language Reimplementation
• Download Electric