Articles
Infrastructure for Design Reuse
Solve Timing and Signal Integrity Problems
An Effective Way of Design Reuse

Success Stories
Alpha CPU goes 0.13 Micron
Synopsys chooses Rubicad's LADEE for layout migration of 0.13-micron memory compilers
Peregrine cuts design time and costs
IMI increases performance
OKI reuses Hard IP
Philips migrates microprocessor core
Qualcomm optimizes Standard Cell Libraries
Xilinx migrates FPGA

Apha CPU goes 0.13 Micron with the Help of Rubicad

The following is an interview by Rubicad with Christian Herdt, former Microprocessor Project Manager, Compaq Computer Corporation,
now Engineering Manager, Massachusterrs Microprocessor Design Center, Intel Corporation that describes Compaq’s use of Rubicad’s software during the Alpha EV69 conversion project.

???  Can you tell us more about the migration project?
The EV69 microprocessor was the last generation of the Alpha EV6 architecture slated for 0.13-micron lithography in silicon-on-insulator (SOI) technology. The goal was to accomplish it in the simplest possible migration, consuming a minimum amount of resources and time. This demanded a novel approach to a traditionally resource-intensive project. 
The EV69 database is very large, about two gigabytes. Its transistor count is over 15 million. The database had been migrated a number of times before from the original 0.25-micron EV6 design in bulk CMOS technology. As a result, its hierarchy was no longer in the best of shape. All of that presented a number of additional challenges.

???  Why did the traditional linear shrink not work for this project?
We could have done a traditional linear shrink had we accepted its performance implications. But we were going from a 0.18-micron bulk process to a 0.13-micron SOI process, and we wanted to get as close as possible to the associated 50% area shrink for performance and cost reasons. By doing a straight “dumb” linear shrink, we could have achieved only a part of the speed and die size benefits of that process, because not all design rules decreased by the same amount. Since the design rules shrank by different proportions, in order to get the maximum benefits of both speed and cost we looked into different ways of doing a non-linear shrink. The dominant design rules contracted by the traditional 0.7 shrink factor linearly, but there were a number that did not, and a few shrank even more. For example, in the 0.18-micron technology there was an addition of local interconnect that had not been taken advantage of fully in the previous migration, and which therefore presented some opportunities for additional shrink in this 0.13-micron project.
There were a lot of opportunities to improve the performance and decrease the die size that could have not have been taken advantage of by a traditional shrink. We worked very hard to come up with an alternative, and we came up with all sorts of creative ideas, some involving the mask maker, others our internal CAD group. But for one reason or another these ideas were not deemed to be either cost-effective or schedule-sensitive, so we ended up working with Rubicad and achieved the ideal 50% area shrink.

???  What was the challenge in moving to 0.13-micron technology?
For one thing, the shrink was no longer linear, and even though that was true for earlier generations, the percentage loss became unacceptably high. So we had to come up with a new, more intelligent shrink flow. 
Some issues were particular frustrating. For example, the poly overlap of transistor gate, also known as endcap, did not shrink at all in real silicon dimensions, so we had to push interconnect poly away from the endcap. We had millions of transistors, and of course this caused millions of design rule violations. There were other issues particular to our target technology, such as the partially depleted SOI whose leakage in certain dynamic circuit configurations was too high. To address this issue, we introduced additional masking layers in those predictable areas that could be identified in an automated fashion, and in some special cases identified by hand, as well. We needed a time-efficient method for implementing design changes associated with the additional masking layers. Doing all that all by hand was not an appealing choice.
We would not have gone ahead with the project if we had had to fix all of the design rules manually. It wouldn’t have been cost-effective, or reached the market in time.

???  What were your criteria for using Rubicad’s service?
One of the important criteria when you migrate a database that you intend to sell as a product is making sure that the design database is in fact maintainable, because the migration will not be perfect. So you have to have a plan to begin with and flexibility before you go to mask production. And you want to make some adjustments and tweaks as time goes on. So you need to end up with a database that is manageable and that engineers can work with efficiently. One of my critical requirements was that the hierarchy of the database be preserved, because if you lose the hierarchy you lose the ability to make modifications efficiently. The hierarchy is there so that you can make an adjustment in one cell and correct it wherever it is instantiated. That was a very important criterion.
Another critical criterion was the ability to work with a very large database, which, frankly, eliminated most vendors. 
A third criterion was a vendor with a team that was willing to drive the implementation of its product on the first project using their software at Compaq, because schedule was critical and I could not foresee being able to ramp up on a new CAD tool in the time frame we had available. The package deal that I was looking for included a serious input from the CAD vendor and also flexibility with the actual project definition, because any large microprocessor design project is going to evolve problems that cannot be foreseen at the beginning. Some CAD vendors do not appreciate that, so it was important that we could find someone who could understand that if things came up, we would have to deal with them in a data-oriented and reasonable fashion, as opposed to by the letter of the contract. In some cases, we asked Rubicadto do additional things and in other cases fewer things; it was a back and forth that was very important to the success of the project.

???  What layout quality requirements did you have for the automatic correction?
I liked the fact that the artwork looked like artwork, as opposed to automatically generated layout. In general, the corrected database was very close to what a human being would do manually.
One criterion we used in this specific design to reduce our risk was that we did not touch the metal. We kept all the cell origins unmoved and we kept all the metal unchanged. There was a lot of history embedded in the metal and we did not want it to be modified.
As a result, Rubicad could not repair all design rule violations because the cells could not be grown. It took us some time to come up with an acceptable number of design rule violations. The small team we had was able to fix the remaining errors in a few months as opposed to a few years. In fact, we would never have undertaken the project in the traditional fashion.

???  Can you tell us about the benefits of automatic correction?
One of the benefits was time and the other was money. As I said, we looked at a number of different solutions, both internally and externally. We had a considerable amount of CAD resources at Compaq’s Alpha group. We worked with a number of different vendors and with our foundry to figure out how best to approach this project. There was no doubt that we would only go ahead with a more efficient flow than the traditional linear shrink that was associated with fixing masses of design rule violations. 
Quality was important, but it was not primary: if you could only do a quality job but it would take 10 years, that would not have been relevant. 

???  How did you learn about Rubicad’s technology and capabilities?
I was chasing around looking for CAD vendors, and I heard from a colleague who had learned about your technology during his employment at SGI. I obviously called the other compactor companies, but they were not able to handle the database size or the hierarchy. I was not interested in automated correction of a database that was not maintainable. For that I had to go with Rubicad.

???  What clinched the deal to work with Rubicad?
Basically we came to visit Rubicad to kick the tires. I was looking for a product that could perform a non-linear shrink without messing with my metals, but that would also preserve the hierarchy. In order to do that, a vendor had to be able to handle huge portions of the database at once. Rubicad was also willing to make modifications to their underlying code in order to implement exactly what I had defined before I met Rubicad. Your company’s willingness to contribute some R&D to my R&D effort, combined with your existing technology, was what made the difference. 

Back to Top