In my last post, I said: “A hurricane has made landfall and its name is FinFET”. OK, it’s a little corny, but it was not meant to convey a sense of impending doom for custom layout productivity. No question that hurricanes are disruptive, but humans can adapt to even the worst nature can bring. And FinFETs bring tremendous benefits along with the disruption.FinFETs are without doubt the most radical shift in semiconductor technology in decades, but moving to FinFETs is absolutely necessary. As feature sizes became finer, high leakage current due to short-channel effects threatened to put the brakes on scaling. FinFETs address the leakage issue and give Moore’s Law a new lease of life.Today the bulk of design starts are at the established nodes above 28 nm, so not everyone doing custom layout has experience with FinFETs. For those who have not yet felt the ‘winds of change’ that FinFETs bring, here is a brief primer.
Archive for February, 2016
I left off in part 2 of this blog asking the question: “Have we exhausted all avenues in our search for layout productivity?”
Although there has been no revolutionary technology as with the initial CALMA systems, there have been some incremental improvements that help oil the gears when doing layout.
On-line DRC has been one such improvement. Having the ability to check the layout for design rule violations incrementally, as you complete more and more of the design, made it easier to implement changes. Violations were displayed in the layout, making it easy to find and fix them. However, checking the layout connectivity versus the schematic was still a batch task that could only be run when the design was fully implemented. The connectivity of the physical layout had to be extracted in order to compare against the logical connectivity.
As EDA marched on, with each new crop of more powerful workstations came the next generation of interactive tools. If you could compute the design rule checks fast enough, why not show them dynamically as layout geometries were being created? And so Design-Rule-Driven (DRD) layout was born.
If I say ‘sticks’ to you, what comes to mind? Well, you could reply with “bits of wood” or “an American rock band from the 70’s” or “a river in Hades” and you would be correct. However, when you ask the question in the context of EDA, well, that’s a different story.
‘STICKS’ or ‘stick diagrams’ refers to a technology called symbolic layout. My first introduction to symbolic layout was the CALMA STICKS package that emerged around 1983.
STICKS was a netlist-driven symbolic design package that produced correct-by-construction physical layout directly from the logical netlist. Although a great concept, it never really took off. The effort to bring the logical connectivity into the layout by means of a netlist did not deliver a high-enough ROI in the eyes of the layout community.
It’s amazing what you find when you clean out your garage. I came across some old photographs of the first CALMA systems I worked on. Boy, have we come a long way since those days!
Those early CALMA Graphic Data Station (GDS) systems that I worked on back in the late 1970s were considered revolutionary. Why revolutionary? Well before they came along, making the masks for an IC was a real pain. Here’s a brief recap of what you had to do to:
Before GDS, the IC layout engineer would have to draw the circuits on large sheets of grid paper, using a different color for each layer of the circuit. Then they would produce a mask of each layer by cutting the shapes into a peel coat material such as Rubylith. To get a rectangle for example you would cut the four edges that made up the rectangle through the top layer of the Rubylith but not through the base layer. The peel coat material would be removed, leaving the rectangle exposed. The sheets were then photographically reduced to the real size of the IC. A stepper was then used to produce the physical masks by replicating the sheets as many times as would fit on a mask that was the real size of the wafer. Typical wafer sizes back then were around 4 inches. As you can imagine, this was very time consuming and very error-prone.