Posts Tagged ‘custom design’
Tuesday, September 20th, 2016
In the blog ‘Custom Compiler In-Design Assistants (Part 2)’, I outlined how we can use StarRC to report capacitances on critical nets in the layout even when the design is still in flux and not completely LVS-clean. In addition to capacitance reports, we also showed resistance reporting which is critical for FinFET-based layouts. At advanced nodes, the impact of parasitics, electromigration (EM) and restricted design rules drive critical layout choices. Interconnect that does not meet resistance, or EM criteria and unbalanced capacitances on matched nets, can and often does adversely impact layout schedules. So the earlier in the layout phase the layout engineer can address these issues, the sooner he or she can close the design.
EM in particular is a notorious problem in the FinFET process due to the high drive of the transistors and thin metals. So let’s say, for example, the layout engineer has to route a critical net which could be susceptible to the impact of EM. This is a non-trivial task that could be quite challenging. However, if you use Custom Compiler, there are some very cool capabilities that make laying out interconnect that meets EM criteria very quick and very easy.
Tuesday, May 10th, 2016
Over the last series of blogs we have looked at which tools the layout engineer has available to him/her to help deal with the complexity of doing layout with FinFETs. Even though there are tools that help, the fact is there is still a productivity hit when comparing the time it takes to do a FinFET-based layout vs. a planar CMOS layout. When I asked my layout colleagues “How much longer does it take to do a FinFET-based design vs. planar CMOS?”, they said it takes 2-3X longer.
So, if we are to recoup layout productivity when doing a FinFET-based design, which areas should we focus on? Well, let’s start at the very beginning, which, according to Julie Andrews in The Sound of Music, is a very good place to start. The task of generating the devices and placing them such that they meet all the design rules and will produce a robust working design is about 30% of the layout time. So if we can speed up this task then we will gain back some of the productivity we lost due to the complexity of the FinFET process.
Friday, April 29th, 2016
What is electromigration (EM) and why is it something we should care about?
Here’s the definition of electromigration from Wikipedia: “Electromigration is the transport of material caused by the gradual movement of the ions in a conductor due to the momentum transfer between conducting electrons and diffusing metal atoms.”
Put simply, when the current density gets too high for a given wire width, you get problems. These problems manifest themselves in two ways, either a void in the metal wire that creates an open circuit or a hillock that creates a short to another wire. Either way your chip fails. Electromigration is made worse by temperature and mechanical stresses.
Electromigration in the FinFET process is now a first-order effect and has a huge impact on the Mean Time To Failure (MTTF) of a metal wire. So, as you can imagine, to ensure you have a robust design that will last, great care has to be taken when choosing wire widths for interconnect and power grids.
Wednesday, March 30th, 2016
Over the last few blogs I have outlined some of the productivity challenges that the FinFET process brings with respect to custom layout. Today Synopsys unveiled Custom Compiler and ushered in a new era of visually-assisted automation. Custom Compiler has all the good stuff I’ve been saying is needed in earlier posts: a new custom design solution that closes the FinFET productivity gap by shortening custom design tasks from days to hours.
This is not a revamp of the old constraint-based legacy approach, it’s a fresh approach to custom design that employs visually-assisted automation technologies to speed up common design tasks, reduce iterations and enable reuse.
What’s visually-assisted automation, you may ask?
Monday, March 28th, 2016
What tools do we have in our FinFET toolbox that can help layout engineers manage the complexity that FinFETs inherently bring?
Well for my money, the best and most powerful tool we have to tackle FinFET complexity is the good old parameterized cell or PCell. PCells are not new, they have been around since the CALMA GDS days and along with Schematic-Driven Layout, have been instrumental in boosting layout productivity, as I have mentioned in my previous posts. PCells have typically been used to generate physical layout of pretty much all the devices needed for custom layout, from resistors to inductors, capacitors and, of course, the transistor. That is still the case for FinFET designs; however the role of the PCell has now been expanded to include the schematic PCell.
So what’s the big deal about a schematic PCell, you might ask? And why didn’t we have them before?
Well, some companies did use schematic PCells, but mainly to generate symbols. With FinFET there are many more reasons that a schematic PCell should be used. It boils down to three things: complexity, aesthetics, and productivity.
Wednesday, March 9th, 2016
So, FinFETs rule! They give the designer so much flexibility in trading off power and performance that it should be a no-brainer to adopt the technology–right?
Well, every silver lining has to have a cloud, and in the case of FinFETs there are quite a few.
I polled a number of layout designers who have first-hand experience of laying out FinFET designs and asked them “What’s the impact of FinFET?”. Here’s what they told me requires them to do extra work:
- First off is the sheer number of rules that they have to be conscious of. The number of rules has more than doubled compared to a 40-nm process. Of special concern are some of the density rules that now have to be applied to a lot more layers.
- Another area you have to pay particular attention to is maximum diffusion space. This forces devices to have guardrings around them so that you do not have too large a diffusion space. The diffusion in the guardring essentially breaks the space check. So you either have to have devices very close together or spaced by guardrings.
- Process restrictions require that every fin has to have an equal height. In addition there are strict limitations on the sizes of “W” and “L” that can be used. As a result a device that requires a large “W” (width) has to be quantized into multiple fin units that utilize the acceptable “W” and “L”.
What this means in practice is that an innocent-looking single device in the schematic can be 100 devices in the physical layout! Add to that the fact that fins have to snap to specific grids and you have a massive layout challenge for even a simple circuit.
Wednesday, February 24th, 2016
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.
Monday, February 15th, 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.
Thursday, February 4th, 2016
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.