Density and the Analog Cell
Analog design is a very sensitive business. Unlike the digital world, where circuits are on or off, and have built in hysteresis to prevent inadvertent toggling, analog circuitry is intentionally designed to respond to minor fluctuations in the signal. As a result, analog layout is riskier than digital. To prevent race conditions, or minor (yet potentially catastrophic) fluctuations in signal to more than one device, analog cells are constructed in a way that requires very precise geometric matching and symmetry between devices.
So what?, you say. Analog designers have successfully dealt with these issues for years. Unfortunately, when you take that carefully designed analog IP and place it in an SoC design, there is one threat that can undo all of that detailed layout: dummy fill insertion. The typical metal fill flow checks the full-chip density. Wherever regions are found that violate the density requirements, metal fill is inserted. Unfortunately, this fill approach is woefully ignorant when it comes to the matching and symmetry requirements of analog circuitry. As a result, if a full-chip density violation overlaps the placement of an analog cell, metal fill may be applied willy-nilly, likely throwing off the cell’s expected behavior.
Again, so what?, you say. You may be thinking that, as long as the analog cell itself passes density, there is no possibility that it will generate a density violation when placed into context, right? Unfortunately, that is not the case. There are a couple of reasons why an analog cell that passed density checking in isolation may be associated with density violations when placed into a larger design. The first is the surrounding context. If an analog cell that passes density is placed into a low density region, then the density violations may extend into the extent of the analog cell. In fact, if the analog cell is smaller than the density checking window size, the density violation may actually cover the entire cell.
Another, less obvious, reason why the analog cell may pass when run in isolation, but fail in the full chip, is due to the nature of density checking itself. In density checking, a window of predefined area is stepped, with a pre-defined step size, across a design or region. The windows that happen to fail are output as errors. This approach, by its definition, requires some implied starting point for the density windows. For example, with Calibre DRC, the first density window starts at the lower leftmost corner of the extent of the design.
Imagine a case where density is run on an analog cell. The first window checked is in its lower leftmost corner. The next window checked is shifted by the step size, and so on. Let’s assume this cell passes density by itself. Now let’s put the analog cell into the context of a larger design, as shown in the figure below. In this case, the first window checked is in the lower leftmost corner of the larger design. As the density window is stepped across the design, there is no guarantee, and in fact, little likelihood, that the density window locations from the full-chip run will align with the density windows checked when the cell was in isolation. There is a very real possibility that, because the density windows are now in a new location, the analog geometries within the new window will now fail density. This is actually a real error. Unfortunately, it is one that could not be found or corrected when the analog cell itself was created. Now we have a real challenge.
Figure 1. Due to the mis-alignment of the cell origins at chip-level versus cell level, it is possible to identify an error at the chip that is not found on the cell itself.
So, what can we do about this issue? The good news is that there are some solutions. The bad news is that they all have some limitations. Let’s take a look…
First, we can do a better job detecting these errors within the analog block. For a shifted density window at full-chip level to flag an error not found at the cell level, the original density windows run on the analog cell must have been close to the limit, because there is not much room for variation in the geometries under the window. One commonly used approach is to apply a more restrictive checking requirement to the analog block, but this approach does have some challenges. First, it requires modifying the golden rule file during the analog cell run, which is generally considered taboo. Second, even if you do modify the rule, you need to know how much to modify the constraint by. This is not trivial. To know the correct adjustment, you need to know how much the window will shift when the cell is placed into context, which of course, you don’t. To determine the worst case scenario, you’d have to imagine that the region in the analog cell that is now not checked was 100% covered from a density perspective, and that the new region being checked is 0% density compliant. From this situation, the worst case situation would occur when this delta is completely devoid of polygons for the layer being checked in the density rule.
Figure 2. Overlapping density windows.
Let’s take an example. Assume that the upper right window from Figure 2 is the window used when calculating the density at the analog block level. Further assume that the lower left window in Figure 2 is the window used when calculating the density at the full-chip. The inverted-L shape in the upper right, representing the portion of the window from the analog block not checked in the window at full-chip is exactly equal to the L-shaped region on the lower-left, representing the new portion of the design that was not checked (not known) when we checked the analog block. In the worst-case scenario, inverted-L in the upper right is completely full of whatever geometry we are checking for in the density calculation, and the L-shape in the lower-left is completely devoid of that geometry and each has a width exactly equal to one step size. In this case, for the analog cell to be assured of passing anywhere it is placed into the design, at the cell-level, it must meet a density requirement of [(100*100)-2*(10*10 + 10*9)]/100 = 96.2% of the original density constraint. The larger the step size, the greater this difference will be.
Another approach that does not require such complex algebra is to simply decrease the step size of the density window when running the analog block, thereby increasing the coverage of the density checking. To assure 100% coverage, this step would have to be the smallest step as defined by the process. This approach requires longer runtimes and potentially much larger result databases. It also requires detailed analysis of the results to determine the best fix. In Calibre, multiple methods can be used to help with this analysis, including the use of histograms and color-maps, or the use of automated averaging and combining of window results.
Figure 3. Density window histograms and color map enable fast identification of the min and max density windows within a block.
Of course, both of these approaches only solve part of the problem. Finding all possible density violations in an analog cell does not ensure that the cell can be modified to be 100% density-compliant in all cases. It also does not help in the case of pre-existing analog IP that cannot be modified.
One last method tries to ignore these errors at the chip-level. Historically, users tried to ignore these errors by limiting the areas where the density windows are and are not checked. Unfortunately, this approach also falls short. Density windows are square by default. It is possible that, in context, multiple analog cells line up in a manner that forms non-square regions. In these situations, it is not always possible to check everywhere outside of the analog cells while not checking anywhere inside the cells. Consider, for example, a “doughnut” ring made of analog cells surrounding some digital area. The doughnut “hole” in this case is not checked. Another common problem happens when the sections to check have regions narrower than the density window. How do you check only part of a density window?
Figure 4. Complex keep-out regions for the analog portion of the density, may not be easily partitioned by a square density window.
There is an alternative that can be used with this approach. In this alternative, the full-chip density windows are checked everywhere. Those windows that have a user-defined percentage of their area covered by an analog cell are simply ignored. This approach, unfortunately, also requires non-trivial modification of the density check in the golden rule file. The exact details of how to do the necessary coding can be seen in the Calibre Solutions Manual under the Density Checking chapter.
However, I’m not going to leave you with incomplete and unsatisfactory solutions. I’m just not that kind of guy.
To remove the need to modify the rules, a new method of DRC waiving, specific to density checking at the chip-level, is available. With this approach, the user specifies the check name and the percent area of a density window that must be covered by the analog region for it to be waived. The analog region may be identified by cell name, by a drawn marker layer in the layout, or by some previously identified density results. With this approach, density windows that have enough of their area covered by the analog keep-out region are waived. All other windows are checked as normal. Unlike the existing DRC waiving approach of Calibre Auto-Waivers, this waiving is done window by window as opposed to by merged results. Those density windows that are waived output to a separate database for user review, with details of their measured density and the percent of window area covered by the analog region. This is all done without any user modification to the golden rule file.
Figure 5. Calibre RVE displaying both the density errors and the waived density errors for check “met1_density”. The results database shows the calculated density value as well as measured areas of the metal and the keep-out region. These can be used for sorting or filtering.
With the combination of the techniques described to try to assure that analog blocks will meet density regardless of context, and the ability to automatically waive violating density windows interacting with the analog cell, users now have much safer and automated solutions to a problem that has vexed the SoC design community for several years. Solving the analog IP density issue helps prevent the inadvertent destruction of analog circuitry via non-optimal metal fill placement, and saves significant time by automating the previously tedious manual approaches used to identify and remove those metal fill geometries from the analog regions. For more details, feel free to ping me directly.