Known Problems and Solutions in Design Data Translators
This document describes the known issues with Design Data Translators on OpenAccess and suggests the workarounds for these issues. Each issue is identified by a Cadence Change Request (CCR) number.
This document contains the following sections:
Related Topics
Design Data Translators SKILL Reference
CCR 1177790: Perform "unlockAll" on each hierarchy of the layout does not cleanly erase color locking
Description: Removed color locked shapes may still exists in the GDS after XStream Out. In some cases, the data that has gone through mptUpdate may contain “lock override” anchors created using ICADV12.1 ISR3 or prior. The 'Lock override prohibition' option in ICADV12.1ISR4 prevents “unlockall” operation to remove the “lock override” anchors during descending and edit from top to bottom. As a result, color locking is not removed completely in the layout prior to XStream Out. You may observe undesirable color locked shapes in the gds after XStream Out.
Solution: To ensure that the color locked shapes remove properly, you have to unlock all from bottom to top hierarchy.
CCR 1175605: Variant is not generated for instance marked by ocalocking during 1-1 color mapping (Anchor in full-color for ISDA)
Description: A limitation prevents XStream Out to translate the color defined by the coloring engine into the output GDSII.
Solution: There is no workaround available.
CCR 734056: PVS LVS mismatch on using gds created from Pcell layout in IC61, OK within DFII
Description: As per the following code, users may not get the correct value of bBox after the master cellView is closed.
devId = dbOpenCellViewByType("VIP50CLZ3" "NPN" "layout")
obj = dbCreateParamInst(pcCellView devId nil 0+spacing:0 "R180" 1 list("Nb" "string" NumBase))
dbClose(devId)
rs_LL = car(obj~>bBox)
rs_UR = cadr(obj~>bBox)
rs_LL and rs_UR may not have correct values as master cellView has closed before calling obj~>bBox.
Solution: To get the correct value of bBox, users need to keep cellView open till it queries for bBox, as mentioned in the code below:
devId = dbOpenCellViewByType("VIP50CLZ3" "NPN" "layout") obj = dbCreateParamInst(pcCellView devId nil 0+spacing:0 "R180" 1 list("Nb" "string" NumBase)) rs_LL = car(obj~>bBox) rs_UR = cadr(obj~>bBox) dbClose(devId) <----- move here in the end
CCR 488466: Object map is not loaded correctly during strmout
Description: When loading an object map file in the Objects tab of Stream Out GUI, the form should be populated with object name and other relevant data. However, in this release, the object name field is not displayed in the GUI.
Solution: Suggest using the strmout command with -objectMap command line option.
CCR 415118: XStream template file should be loaded if lib name not set
Description: Currently there is no possibility to initialize the XSTREAM IN and OUT forms skill as it was possible with PIPO (PCR 908046). This is done through automatically loading a template file.
While loading the template file, it is mandatory to include the stream file name (strmFile) and the library name (library)in the template file. In case the names are not included, first a popup window shows up with the message that the strmFile name and the library name is required and then the template file loading is aborted.
Solution: Suggest either removing the option ‘library’ or option ‘strmFile’ from the template file or have a dummy library name in the template file.
CCR 277193: Two different binaries for msgHelp exist in IC5141USR3
Description: The message help system for XSTREAM can be accessed through a binary called msgHelp located in the directory $CDS/tools/dfII/bin/msgHelp. In the release IC 6.1.0, a new binary with the same name exists in the directory $CDS/tools/bin.
Solution: Create an alias for the XSTREAM message help system to point to the correct msgHelp utility.
In the following example, an alias named xstreamMsgHelp is created to point to the correct msgHelp directory.
alias xstreamMsgHelp "$CDS/tools/dfII/bin/msgHelp"
CCR 442828: SpiceIn should not try to map model names to schematic components
Description:SpiceIn parses the model path and tries to map model names found in the library sections to cell names in the reference libraries. This should not be the case since these representations doesn’t exist in the DFII library and only exists in simulation models files.
Solution: There is no workaround available.
CCR 278800: nino cdlin postfix illegal character to subtype string
Description: The value of the subtype property created in the database might contain illegal characters. This might happen due to the uninitialization of the variable used to create this property by CDL In.
Solution: There is no workaround available.
CCR 83875 LEF In does not accept LEF file generated by CDBA LEF Out
Problem: If the macro pin names contain hierarchy delimiter characters, CDBA LEF Out, while writing out the macro pin information, does not escape the hierarchy delimiters.
When you create a technology library using OpenAccess LEF In from this output file, the file is not read and the translation fails.
Solution: The LEF file should be manually edited so that if pin names contain hierarchy delimiters, these should be escaped.
CCR 53381: Routesaspaths makes NETS vias written in SPECIALNETS.
Problem: If a net in the design consists of disassembled routes (paths and vias) and you perform DEF Out of that design, it does not write the geometries associated with the net.
Solution: To write all the geometries associated with the net consisting of a disassembled routes (paths and vias), first assemble paths and vias to routes.
Allegro Translator (IC23.1 Virtuoso MultiTech Framework Only)
CCR: 1777824 SIP_OA:Design with TILP's crashes while exercising DEF/STREAM
Problem: Designs with technology independent layout Pcells (TILP), created when package layout from Allegro is imported into Virtuoso, crash during XStream or DEF translation.
Solution: XStream and DEF translators do not support translation of package design components. There is no workaround available.
CCR: 1715599 SIP_OA: RatsNest /TPoint are not translated to OA
Problem: The following components of Allegro package design cannot be imported into Virtuoso using the Allegro Import translator:
- Ratsnest intersection, which is the point where three paths intersect.
- Tpoint or a ratsnest T, which is a point in the physical layout of a net that indicates the signal path splits into multiple paths.
Solution: Allegro Import translator does not support translation of Allegro package layout components, RatsNest intersections and Tpoint.
Return to top