H

---

Troubleshooting

---

This appendix describes problems you might encounter while using ROD functionality and suggests how to solve them. The problems are divided into two categories:

• Warnings in the CIW
• Dialog Box Messages

Warnings in the CIW

Template templateName is replacing an existing template by the same name

Creating instance forces unname of ROD object

ROD object ID changes after Undo

Template templateName is replacing an existing template by the same name

When you load an ASCII MPP template file, the system checks the names of the MPP templates in the ASCII file against the names of MPP templates that already exist in the technology file in virtual memory. If there is a name conflict, the system displays a warning in the CIW saying that an MPP template in the ASCII file is replacing an existing MPP template. The existing template in the technology file in Virtual Memory is overwritten.

Solution:

If you do not want to overwrite the original MPP template in your binary technology library on disk, then do not save changes to the technology file. You can also avoid overwriting existing templates by changing the duplicate names in your ASCII file to unique template names.

If you want to change the names of the MPP templates in your ASCII file right away, or you want to be able to save other changes to your technology library on disk without overwriting the original template, you need to:

1. Exit the layout software without saving technology file changes.
2. Edit your ASCII file to change template names.
3. Restart the layout software.
4. Reload your ASCII MPP template file.

Creating instance forces unname of ROD object

WARNING* rodiFigTriggerFunc: Creating instance named instance_name
forced unname of ROD shape_type to avoid name conflict. 
*WARNING* You might want to use Undo now.

If you create an instance using the dbCreateInst function in the CIW and a ROD shape already exists with the same name in the same cellview as the instance you are creating, the warning above appears in the CIW.

If you do not do an undo, the system unnames the ROD object, turning it into an ordinary shape without any ROD attributes.

Solution:

Immediately do an undo. Avoid using dbCreateInst to create instances that have the same name as ROD objects in the same cellview.

ROD object ID changes after Undo

When you do an Undo in a cellview with the hiUndo function or Edit – Undo, the system restores the previous version of the cellview. Variables that used to contain ROD object IDs no longer do so. If you do a Redo with the hiRedo function or Edit – Redo, the system restores the “undone” cellview, but assigns new ROD object IDs to all ROD objects in the cellview. Therefore, you need to reset your variables for ROD objects.

For example, if a layout cellview is open for editing and you type the following statement in the CIW:

rect = rodCreateRect(    ?cvId geGetEditCellView() 
                         ?name "myRect" ?layer "poly" )

the system responds by creating the rectangle in the cellview and displaying its ROD object ID in the CIW as follows:

rodObj:22032408

If you do an Undo at any time during the same editing session, the system restores the previous version of the cellview. The rect variable no longer points to a valid ROD object. When you test rect after an Undo, the system displays the following:

rect
rod:invalid

rodIsObj( rect )
nil

If you follow an Undo with a Redo (with the hiRedo function or Edit – Redo), the system restores the cellview. However, the system assigns the rectangle a new ROD object ID, so the rect variable remains invalid, as it still contains the old ROD Object ID.

rect
rod:invalid

rodIsObj( rect )
nil

Solution:

To update the rect variable to the new ROD object ID for the rectangle, use a statement similar to this:

rect = rodGetObj( "myRect" geGetEditCellView() )

Now when you query the variable rect, the system responds with the current ROD object ID, as follows:

rect
rodObj:22032420

rodIsObj( rect )
t

Dialog Box Messages

Why is a dialog box asking about saving the technology file?

If you are asked whether you want to save changes to your technology file when you exit the layout software, and you do not know what the changes are, it might be that an ASCII MPP template file was loaded during your editing session. The ASCII MPP template file could contain templates with unique names, templates with names that match templates existing in your technology file, or both.

• When the ASCII MPP template file contains templates with unique names, saving changes to your technology file causes the system to add the new templates to the existing templates in your binary technology library on disk.
• When the ASCII MPP template file contains a template with a name that matches an existing template in the technology file, saving changes to your technology file causes the system to overwrite the matching template with the ASCII version. This might not be what you intended.

Solution:

You can verify whether templates loaded from ASCII files produced name conflicts by looking for the following message in the CDS.log file:

Template templateName is replacing an existing template by the same name

For information about what to do, see Template templateName is replacing an existing template by the same name.