|
|
Magic Mailing List |
|
From: D.Jeff Dionne (jeff AT uClinux DOT org) Date: Fri Sep 05 2003 - 16:11:22 EDT
On Friday, September 5, 2003, at 02:30 PM, Jeff Sondeen wrote: > Philippe Pouliquen writes: >> Tim, >> >>> I suggest that you write CIF or GDS, then read it back in, and >>> confirm >>> that the auto-generated wells comply with the DRC rules (they >>> should). A quick test shows that it does in fact make something that passes DRC. I'll have to look more closely to see if the result would actually work. >> >> I don't think that the auto-generated wells are guaranteed to pass >> DRC. >> Maybe Jeff Sondeen can confirm this, but I think that when you have >> two N >> wells that are near one-another but not fully aligned, so that the >> overlap >> is less than the minimum well width, the bloat-shrink operation that >> is >> supposed to fill in the gap actually creates a narrow bridge. > > yeah this is especially true for 'cater-corner' cases. historically > it has been ignored, and your chip probably isn't at too much risk in > the case of selects (which also have the problem), but i think it's > safest to always draw both wells (since capactitance extraction > (ie. shielding) only works right if both wells are drawn anyway). If an export to CIF, import, extract and conversion to spice works ok, would one therefore still have to consider the capacitances wrong (or the results inconclusive) because only one of the wells are generated into the CIF file? > the .cifcheck techfiles use the (very slow) cif checking rules to > check for this, but the solution to any problems it shows is to draw > the wells. so just draw them! > > i think the original question also wondered about the risk that layout > conforming to old rules would have if fabbed nowadays after rules have > changed. the answer to that is, it depends, but it's quite possible > that results will be fatal (0 yield) with no recourse (since rules > were violated). it's even possible that the current techfiles > (getting dated now) aren't up-to-date... i hope to check them soon. That's concerning. Is SCNA.80.tech27 useful, or should we consider things that pass DRC with it still suspect? Cheers, Jeff. > > /jeff > >> >> I don't know of any solution to this problem, because widening the >> bridge >> can cause a DRV to neighboring N diffusion. The design rules would >> need >> to be modified to preclude the N diffusion from being too close to the >> non-existent N well bridge, and then the CIF rules would need to be >> modified to create a wide-enough bridge. >> >> Here is an example magic file using the SCMOS design rules (the >> layout if >> for Magic 6) which exemplifies the problem: >> >> magic >> tech scmos >> timestamp 1062782013 >> << ndiffusion >> >> rect 11 19 15 23 >> rect 19 2 23 6 >> << pdiffusion >> >> rect 25 16 29 20 >> rect 5 5 9 9 >> << end >> >> >> Just write CIF and read it back in. >> >> Philippe >> >
|
|
|
|