Cadence IC 6.1.0 Simulation

tkhan said:

sometimes if you don't exit icfb/virtuoso gracefully (i.e. a core dump, accidentally logging out, etc...) the .cdslck file doesn't get deleted and your designs which were open stay 'in limbo'. to remove any .cdslck files in your home folder type the following in terminal

 find ~ -name "*.cdslck" -exec rm -f {} \;

In general, you should not have to delete .cdslck files. I am always wary when people do this, because I've seen over zealous deletion of lock files leading to loss of data, because they blew away lock files which were preventing concurrent editing of data.

There is a well behaved standed lock recovery mechanism in the Cadence IC tools. What happens is that when you try to open a cellView (or indeed any file that uses the lock mechanism), it checks to see if it is locked. If there is a lock file, it consults the contents of the file, as this has info to say what machine the lock is on, and what the process id of the locking process is. Virtuoso then tries to talk to a process called "clsbd" on that machine, and asks if that process is still alive. clsbd returns either true or false (clsbd stands for Cadence Locking System Boolean Daemon, since it doesn't manage the locks, just returns true or false if the process is alive). 

If clsbd returned false, then the lock can safely be recovered, and that's what happens. If it returns true, then the lock is valid. If it couldn't talk to clsbd (maybe the process isn't running, or the machine is not reachable), then it errs on the side of caution and assumes it is still locked.

clsbd is started automatically the first time you run the IC tools on a machine if the process is not already running. Sometimes people start it up at boot time, just to be sure.

So typically the only time you would need to remove lock files is if the machine which previously had the lock is no longer available - it's down for an extended period of time, say. Or if nobody has run a Cadence IC tool on the machine after a reboot. In such cases, deletion of the lock files is reasonable, although we do have a tool "clsAdminTool" to help you locate lock files, and delete them in a controlled manner - for example, you can delete just those owned by a particular machine/process id, so you leave the valid locks. It's a bit more controlled than blind file deletion...

I've seen cases where over-zealous sys admins have blocked the ports that clsbd uses, stopping it from being able to communicate. Anyway, more info on the ports can be found in the Cadence Application Infrastructure Guide.

I felt it was important to explain this. I've been at customer sites where I've been told "Cadence sometimes throws away my edits, even though I saved them". I then found out by doing a bit of digging and found that it was routine to delete lock files, and so actually often there were two people editing at once - in this scenario, whoever saves last wins, effectively overwriting the other person's edits.

Regards,

Andrew.

tkhan said:

sometimes if you don't exit icfb/virtuoso gracefully (i.e. a core dump, accidentally logging out, etc...) the .cdslck file doesn't get deleted and your designs which were open stay 'in limbo'. to remove any .cdslck files in your home folder type the following in terminal

 find ~ -name "*.cdslck" -exec rm -f {} \;

In general, you should not have to delete .cdslck files. I am always wary when people do this, because I've seen over zealous deletion of lock files leading to loss of data, because they blew away lock files which were preventing concurrent editing of data.

There is a well behaved standed lock recovery mechanism in the Cadence IC tools. What happens is that when you try to open a cellView (or indeed any file that uses the lock mechanism), it checks to see if it is locked. If there is a lock file, it consults the contents of the file, as this has info to say what machine the lock is on, and what the process id of the locking process is. Virtuoso then tries to talk to a process called "clsbd" on that machine, and asks if that process is still alive. clsbd returns either true or false (clsbd stands for Cadence Locking System Boolean Daemon, since it doesn't manage the locks, just returns true or false if the process is alive). 

If clsbd returned false, then the lock can safely be recovered, and that's what happens. If it returns true, then the lock is valid. If it couldn't talk to clsbd (maybe the process isn't running, or the machine is not reachable), then it errs on the side of caution and assumes it is still locked.

clsbd is started automatically the first time you run the IC tools on a machine if the process is not already running. Sometimes people start it up at boot time, just to be sure.

So typically the only time you would need to remove lock files is if the machine which previously had the lock is no longer available - it's down for an extended period of time, say. Or if nobody has run a Cadence IC tool on the machine after a reboot. In such cases, deletion of the lock files is reasonable, although we do have a tool "clsAdminTool" to help you locate lock files, and delete them in a controlled manner - for example, you can delete just those owned by a particular machine/process id, so you leave the valid locks. It's a bit more controlled than blind file deletion...

I've seen cases where over-zealous sys admins have blocked the ports that clsbd uses, stopping it from being able to communicate. Anyway, more info on the ports can be found in the Cadence Application Infrastructure Guide.

I felt it was important to explain this. I've been at customer sites where I've been told "Cadence sometimes throws away my edits, even though I saved them". I then found out by doing a bit of digging and found that it was routine to delete lock files, and so actually often there were two people editing at once - in this scenario, whoever saves last wins, effectively overwriting the other person's edits.

Regards,

Andrew.