info-vlsi@ucbvax.ARPA (08/16/85)
From: wss@ucbkim (Walter S. Scott)
Magic Bug Report #1
April 24, 1985
Symptoms:
Spurious design-rule violations involving interactions between
cells. Occurs primarily in the CMOS process, and results in
error messages of the form "can't overlap those layers" even
though the overlap is valid.
Fix:
Go to the file src/drc/DRCtech.c and find the procedure DRCTechInit.
Locate the piece of code that corresponds to the fragment below, and
replace it with the fragment below.
for (plane = 0; plane < DBNumPlanes; plane++)
{
/* printf("Plane is %s.\n", DBPlaneLongName(plane)); */
for (i = 0; i < DBNumTypes; i++)
for (j = 0; j < DBNumTypes; j++)
{
PaintResultType result = DBPaintResultTbl[plane][i][j];
if ((i == TT_ERROR_S) || (j == TT_ERROR_S))
DRCPaintTable[plane][i][j] = TT_ERROR_S;
else if ((i == TT_SPACE) || (j == TT_SPACE)
|| (DBPlane(j) != plane)
|| !DBPaintOnPlane(i, DBPlane(j)))
DRCPaintTable[plane][i][j] = result;
else if ((!TTMaskHasType(&DBLayerTypeMaskTbl[i], result)
&& !TTMaskHasType(&DBLayerTypeMaskTbl[j], result))
|| ((result != DBPaintResultTbl[plane][j][i])
&& (DBPlane(i) == plane)
&& DBPaintOnPlane(j, DBPlane(i))))
{
DRCPaintTable[plane][i][j] = TT_ERROR_S;
/* printf("Error: %s on %s, was %s\n", DBTypeShortName(i),
DBTypeShortName(j), DBTypeShortName(result)); */
}
else
DRCPaintTable[plane][i][j] = result;
}
}
Magic Bug Report #2
May 21, 1985
Symptoms:
Problems in generating hierarchical CIF are not being reported.
There may also be problems in actually generating the CIF, for
some technology files. Doesn't appear to be a problem with the
current nMOS or CMOS technologies (?).
Fix:
Go to the file src/cif/CIFhier.c and find the procedure
CIFGenSubcells, about line 565. Add the line:
CIFErrorDef = def;
before the line:
cifCheckAndErase(CIFCurStyle);
to get:
CIFErrorDef = def;
cifCheckAndErase(CIFCurStyle);
Also, go to the file src/cif/CIFtech.c, at about line 800. Replace
the code fragment:
if (op->co_bloats[j] != op->co_bloats[TT_SPACE])
TTMaskSetType(&ourYank, j);
with:
if (op->co_bloats[j] != op->co_bloats[TT_SPACE])
{
/* Careful! For contact images, must yank
* the MASTER image.
*/
if (j < DBNumUserLayers)
TTMaskSetType(&ourYank, j);
else
{
int k;
for (k = TT_TECHDEPBASE;
k < DBNumUserLayers; k += 1)
{
if (TTMaskHasType(
&DBLayerTypeMaskTbl[k], j))
TTMaskSetType(&ourYank, k);
}
}
}
Magic Bug Report #3
June 7, 1984
Symptoms:
CIF reader core dumps when reading labels (CIF "94" statements)
that do not indicate explicit layers. First noticed when Magic
core dumped trying to read in label file generated by ext2sim.
Fix:
Go to the procedure cifParseUser94 in src/cif/CIFreadcell.c.
Find the lines that look like
else type = cifCurReadStyle->crs_labelLayer[layer];
}
(void) DBPutLabel(cifReadCellDef, &rectangle, -1, name, type);
Add a new line before the DBPutLabel call to produce the following
result:
else type = cifCurReadStyle->crs_labelLayer[layer];
}
else type = TT_SPACE;
(void) DBPutLabel(cifReadCellDef, &rectangle, -1, name, type);
Magic Bug Report #4
June 8, 1985
Symptoms:
Ext2sim may dump core when flattening large designs.
Fix:
The node_conns field was not being initialized. Go to
the procedure efDefNew() in src/ext2sim/EFdef.c.
Find the line that looks like
newdef->def_conns = (Connection *) NULL;
and add the following line
newdef->def_caps = (Connection *) NULL;
Magic Bug Report #5
June 8, 1985
Symptoms:
Ext2sim only outputs very large internodal coupling capacitances,
and these are incorrectly reduced by a factor of 1000.
Fix:
Go to the procedure efReadDef() in src/ext2sim/EFread.c.
Find the lines that look like
/* cap node1 node2 capacitance */
case CAP:
efBuildCap(def, argv[1], argv[2], atoi(argv[3]));
break;
Change the efBuildCap line as follows:
efBuildCap(def, argv[1], argv[2], cscale*atoi(argv[3]));
Magic Bug Report #6
June 9, 1985
Symptoms:
The extractor will sometimes output lines that look something
like the following example:
merge "5_526_408#" "foo/bar/bletch" 0 0
when there is no mask material in the cell being extracted.
Ext2sim will then complain "no such node 5_526_408#".
The problem is that the extractor was yanking both node names
and attributes during hierarchical extraction. If a node in a subcell
contained attributes (e.g, "Cr:In$" or "bletch@"), but no ordinary name
labels, the code for determining its node name would fail.
Fix:
Look at the file src/extract/ExtYank.c in the procedure extHierLabelFunc():
Change the following code:
if (label->lab_type == TT_SPACE)
return (0);
to read:
if (label->lab_type == TT_SPACE)
return (0);
/* Reject if not a node label */
if (!extLabType(label->lab_text, LABTYPE_NAME))
return (0);
Magic Bug Report #7
July 20, 1985
Symptoms:
CIF wires aren't being read in properly by Magic.
Fix:
Go to the procedure CIFParseWire in src/cif/CIFreadpaint.c. Find
the lines:
segment.r_xbot = (xmin - halfwidth)/2;
segment.r_ybot = (ymin - halfwidth)/2;
segment.r_xtop = (xmax + halfwidth)/2;
segment.r_ytop = (ymax + halfwidth)/2;
Change them to be:
segment.r_xbot = xmin - halfwidth/2;
segment.r_ybot = ymin - halfwidth/2;
segment.r_xtop = xmax + halfwidth/2;
segment.r_ytop = ymax + halfwidth/2;
Magic Bug Report #8
July 20, 1985
Symptoms:
With certain technology files (particularly the MOSIS SCMOS
technology), Magic complains about non-Manhattan direction
vectors when reading CIF files.
Fix:
Go to the procedure CIFParseTransform in cif/CIFreadutils.c.
At about line 726, find the lines
case 'R':
TAKE();
if (!CIFParsePoint(&point))
{
CIFReadError("rotation, but no direction.\n");
CIFSkipToSemi();
return FALSE;
}
Replace the CIFParsePoint call as shown below:
case 'R':
TAKE();
if (!CIFParseSInteger(&point.p_x) ||
!CIFParseSInteger(&point.p_y))
{
CIFReadError("rotation, but no direction.\n");
CIFSkipToSemi();
return FALSE;
}