Encounter Puzzler Solution: Where Did My Fences Go?

A couple of days ago I posted a puzzler on a scenario where fences couldn't be seen in Encounter.  Check it out HERE.

Congratulations to Jason G for absolutely nailing it in the comments.  He was indeed corrrect -- the issue was that the fences didn't contain any standard cells within them, so the tool wasn't displaying them. That's because the default setting stiplulates that module guides with less than 100 instances within them aren't displayed.  This setting is controlled via the GUI under Options->Set Preference...->Display:

(Note: In 8.1 and earlier this form was accessed via Design->Preferences...)

This has been a long-standing default in the tool and it's usually a sensible one.  If you think back to Encounter's legacy of being a high capacity floorplanning system with a unique virtual-flat view, it makes sense to think that modules will usually have standard cells beneath them and if there are less than 100 instances within a given module, it's usually not a large enough entity to consider as a partition.  That being the case, the default is set to 100 in order to avoid the GUI from being cluttered up.

However, it's quite common for users to perform early floorplanning where there is no standard cell content to the modules.  In cases like this, the tool can treat empty modules as black boxes, or  as empty modules as was the case in the puzzler.  That being the case, I'd be in favor of changing the default to 0 (i.e., all modules should be displayed regardless of how many standard cells are within them).  What do you think?  Let us know in the comments or by dropping me an E-mail: dwyer@cadence.com

Setting that aside, why was it that one user was able to see the fences yet another wasn't?  It was because one user had long ago set this preference and saved it in his home directory in an .enc file.  If you'd like to save preferences for future sessions you can do so by clicking "Save" on the Preferences form and then choosing where you'd like to save the file.  Next time you start the tool, it will pick up the preferences automatically:

For more information about EDI initialization files and the order in which they are sourced see this section of the EDI User's Guide.

So why doesn't the tool save the preferences when a design is saved?  Well, it does, but depending on whether the design is restored or loaded from scratch, the preferences won't get restored.  If one did a "saveDesign testcase.enc" that would result in a testcase.enc.dat directory.  That testcase.enc.dat directory would contain the preferences saved in an enc.pref.tcl file.  If that session was restored via Design->Restore Design... (or "source testcase.enc" which is equivalent to Design->RestoreDesign and the TCL command "restoreDesign") then the preferences associated with the database would be restored along with the design.  But if the design is restored by loading a configuration file and floorplan file, then the preferences file doesn't get sourced.

In all, the moral of the story is that there is more information stored as a result of saveDesign than what is stored in the .conf file.  You might consider passing around .enc.dat directories rather than .conf files when sharing data between users.

Further Reading: If you want to create a self-contained testcase this blog entry might be useful.  It describes how to create a testcase that also contains all of the supporting library data which can be useful when passing databases to other sites that don't have visibility to the same file system.  It's also very useful for passing testcases to Cadence applications engineers to troubleshoot issues. This is why "saveTestcase" is one of my favorite commands.

I hope this format is fun and useful.  I'll post another puzzler soon.

Bob Dwyer