Stats

  • Locked Locked
  • Replies 8
  • Subscribers 143
  • Views 15606
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Any clue on the dbSave behavior change after dfII 6.1.* release?

Tongju

I have code like:

dbSave(cvid_org libName cellName viewName) ,

which works fine within dfII 5.1* release even when the target cell view (libName:cellName:viewName) is open for edit in the current session. Basically, it just overwrites the current target cellview with the contents in cvid_org.  As the result, I will see both disk and display window of the target cellview  are updated.

 However, in the dfII 6.1 release,  this same code  works correctly ONLY when the target cell is not open in the same session (memory) for edit. Otherwise, it complains "dbWriteCellView: Unable to lock database file for libName/cellName/viewName" and fails. Sounds to me that the same API will not be able to handle memory anymore: it couldn't figure out that the target cell is in memory in EDIT mode and it has the "lock" already.

 So, I am using a ugly work-around:  adding "dbPurge" first in my script to remove the target cell from memory and then, run the same dbSave, and reopen it after that.

Do you have any clue why its behavior should change to the new way? Do you have suggestion for better work-around?

 Thanks,

 Tongju

Parents Reply Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.