Stats

  • Locked Locked
  • Replies 8
  • Subscribers 143
  • Views 15604
  • 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

  •  The OA database itself sets a "in use" flag when a cell is opened for edit. Virtuoso cannot override the flag.Try to change the mode on the cellView to read only (make it non editable, you may have to discard edits first) and then save the data.

     Ted

  • Hi Ted,

    Unfortunately that doesn't work either - it says:
    *WARNING* (DB-270236): Cannot save to cellview 'amsPLL/blah/schematic'; the cellView is opened read-only.

    which is not very helpful. I think closing (purging) it is the only option at the moment (I tried "s" mode too (but that's really read in disguise)).

    Can't use dbCopyCellView, because it tells you:

     

    INFO (DB-170007): dbCopyCellView: amsPLL/blah/schematic already in VM. No copy being done.

     

    Regards,

     

    Andrew.

  • Thanks for correcting me, I do not have access to Virtuoso to test my suggestion.

  • Sorry Ted - I guessed you'd not had the chance to try it. By coincidence I was looking into this at the same time as you, that was all.

    Andrew.

  • That's OK, I hate giving out bad info and welcome corrections.
     
    Ted

  • Hi, Ted and Andrew,

    Thank you for your information! After read your comments, I tried to dig out more from the Cadence OA documents. In the dbSave section, the document still tell me that I could save a cellview to a different open cellview as long as the target view is opened in "w" mode. Sounds the document about dbSave is not up-to-date yet. However, there is a release notes about dbCopyCellview and dbWriteCellView, which described the different behaviors of those commands between OA and CDB.  The description is very similar to what Ted pointed out: the operation is allowed when the target cell view is in "r" mode, but not in "a" or "w" mode. But actually, even opened in "r" mode for the target cell view, as Andrew said, you couldn't do the dbSave into the target cellview. Sounds there is a little bit confuse in the document.

     Tongju

  • Please report this to customer support, and then we can get a CCR filed to get this fixed (I'd do it myself, but bit swamped at the moment).

    Andrew.

  • Hi, Andrew,

     I have filed a SR (#42361144).  Also, I tried dbCopyCellView(cvid libName cellName viewName nil nil t), here, "t" means "allow overwrite", then, the dbCopyCellView works when the target cell view is opened in Virtuoso memory.  So, sounds the dbCopyCellView command is ok. But the dbSave command ONLY works when the target cellview is completely purged from memory.

     Thanks,

     Tongju

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.