Recently one of our new SKILL programmers (lets call him Obi Wan ) discovered a way to update a pcell such that it streams out "successfully" (i.e. 0 errors), but the resulting GDS cannot be opened by Calibre DRC/DRV. (I did not attempt to stream it back in to Virtuoso, but presumably that would have failed as well.) After careful debugging, he narrowed the problem down to this line: dbCreateParamInst( pcCellView cvDbShapeStaggered nil origin "R0" 2 pcellParamList ) Obi Wan had copied this pcell code from another pcell so that he could make a small change. In the original pcell (which streams out without issue), the corresponding line is the same, save for one tiny detail: dbCreateParamInst( pcCellView cvDbShapeStaggered nil origin "R0" 1 pcellParamList ) I.e. the "numInst" parameter was 1 in the working pcell, and accidentally setting it to 2 broke streamout! That mysterious " numInst " parameter to dbCreateInst , dbCreateParamInst , etc. has always bothered me. What does it do, exactly? Apparently, if you dare to set it to something other than 1, it silently corrupts your GDS! :P The documentation doesn't say what's supposed to happen when numInst > 1 (do I get two instances on top of each other?), but it does say it works with the instance name (e.g. " I3 "), so I'm guessing this parameter is meaningful for schematics, but not for layouts? Anyway, it's troubling that XStreamOut generated a garbage GDS without throwing an error, or even a warning about it! Can anyone from Cadence reproduce this on their end, or would you like a testcase?
↧