From b39a45a7001ee9a2243d147d2687f3377820db33 Mon Sep 17 00:00:00 2001 From: Tim Edwards Date: Wed, 17 Jun 2020 12:14:41 -0400 Subject: [PATCH] Further refined the layers used in hierarchical GDS generation to exclude layers created using the "boundary" or "bbox" operators, since they only exist in specific levels of the hierarchy. Pretty much by definition they should not be used in a way that requires additional geometry to be added to the parent cell. This greatly reduces parent-vs.-child disagreements (and the corresponding error messages), but does not entirely eliminate them. --- cif/CIFtech.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/cif/CIFtech.c b/cif/CIFtech.c index 8a55c73d..d7a310cf 100644 --- a/cif/CIFtech.c +++ b/cif/CIFtech.c @@ -1960,6 +1960,27 @@ CIFTechFinal() TTMaskSetType(&style->cs_hierLayers, i); } + /* Added by Tim, 6/17/20: Do not set dependencies of BOUNDARY */ + /* or BBOX because these are unable to be represented in a */ + /* hierarchy without producing conflicting parent/child mask */ + /* geometry. Generally, BOUNDARY and BBOX operations are */ + /* intended to be restricted to the child cell and should not */ + /* interact hierarchically. Possibly it would be useful to */ + /* provide some method to preserve the bounding box information */ + /* when flattening? */ + + for (i = 0; i < style->cs_nLayers; i++) + { + for (op = style->cs_layers[i]->cl_ops; op != NULL; op = op->co_next) + { + if (op->co_opcode == CIFOP_BOUNDARY || op->co_opcode == CIFOP_BBOX) + { + TTMaskClearType(&style->cs_hierLayers, i); + break; + } + } + } + /* Added by Tim, 10/18/04 */ /* Go through the layer operators looking for those that */