Is there anything in VLSI layout other than “pushing polygons”?

Variation-Aware Design: A Hands-on Field Guide-calma-s140-gifAs I travel a lot in the last 15 years and visited customers as well as friends I was many times invited to talk to the Layout teams. The main purpose is always to encourage automation. So I developed a presentation related to market trend, technology trends, and latest tools advancements. In many cases I present updates from DAC (Design Automation Conference), to which I am a big fan participating for more than 20 years. From Memory to Analog and Digital Place & Route in all cases the first question was:

Is there anything else we can do other than just layout? What is my future? What can I do to grow faster? What did you do?

Everybody is afraid that there is nothing else but schematic to layout or Netlist to P&R and their life will be as monotone as a production line work. Nothing more wrong to think about.

In the last 3 years I decided to add an answer to this question and everywhere I talk to layout and design teams I reveal this in a last 20 minutes. So I decided this time to share this is with all of you so you will be able to act before I come to visit your company and present. Will write a series of articles describing the tools in which I was involved as a Layout Designer, from internal to external. Will use approximate timeframe, as some happen 30 years ago, and will provide some context of the condition that enabled such involvement. Will add names of people who actually did the work, or managed it as I was only the instigator, advisor, or tester in many cases.

There are a few condition that favorited my involvement in these developments:

  • The Layout team encounters always the challenge of being the last in the chip design flow – so everything that is late or missed ahead in the design flow, falls on the layout team to "save the day". If and when the Management analyses the full flow it is obvious that the biggest issue is not layout creation but the ECO (Engineering Change Order) or changes to post layout simulations. So only when somebody looks at the full flow can understand that the sooner you bring layout (physical information) into circuit simulations the faster and more predictable gets the flow. From floorplan to placement, from routing to final layout clean from verification, layout is always "somehow" in the hot seat. So if you want change something work on the FLOW.
  • I was a lucky guy to start working in MSIL (Motorola Semiconductor Israel). Our CEO at that time Zvi Soha cared only about tapeout (and at that time this meant a real tape 19 inch diameter going out with the final chip GDSII). He wanted MSIL to be the best site within Motorola Semiconductor, so he enabled internal cooperation between teams and supported any new tools development that can support his plan, even so sometimes against the corporate “policies”. Not too many companies even today, have meetings between CAD, Circuit Design, Layout Design, etc., to enable flow automation as a whole not only as a section of it. PMC Sierra with Norbert Diesing Mixed Signal CAD had a "cooperation group" for support and roadmaps, but no resources to build new tools.
  • The hardware and software were all over the map. The front end design was divided in 2 sections: the system and functional simulations were done on IBM mainframe (cooled with water in a climate controlled room) and the circuit design was done on Daisy machines and software. The layout was done on Calma, a computer made by Data General (mainframe) with 4 terminals, each with 2 monitors, one text and one graphics. We did not have a mouse with 3 functions but a pen and a menu on the screen (taking very valuable visual rea). The pictures attached show a terminal of S-140 machine taken from the web.
  • The verification was done on the IBM using a software called MASKAP, for which Motorola had the source code. So you had to write a tape from Calma and load onto IBM to run verification then write the results on tape and upload into Calma. We had a parser for the DRC images (errors polygons) on Calma screen and a printed error file to identify what is actually the error. A very tedious work I may say...
  • I was a new immigrant to Israel and had problems with Hebrew. All the technology was in English so I focused on getting better at that, as this was a familiar language from my school days. The only way to move ahead was to add value to my knowledge, to be better at something that for others may not be of interest. Calma needed a workstation in the “cold room” the one with the server, so coming from Romania I was the most acclimatized to use it. We had shifts as we had 4 terminals and 8 people but if you used the cold room terminal you can stay longer without bothering others. So I started to read all Calma manuals, in 3 months I knew enough to be "dangerous".


Read More




Addressing Clock Tree Synthesis Challenges
Dan Clein's status of Virtuoso, Custom Compiler, and Pulsic tools