Cadence file "write" lock ..

Hi

As part of our setup I force a load("skillfile") on all users. For the first
user to start cadence this is okay and host of PCells are generated. The
next user sees a whole lot of these

*WARNING* XXopen: failed to lock file FILENAME in A_MODE mode - is
currently "write" locked by user

This is not the real issue in this request however. My problem is that in
order to make changes to the PCells I have to ask the first user to shut
down cadence in order to gain write permission myself .. is there any clever
way of handing over that permission or can I as an administrator simply
steal it ? The limitation is not from unix rights but is solely cadence
related.

Best,

Jan

 

Hi Jan,

Why are you redefining the pcells in the setup? That's definitely not necessary.

Normally the code containing the pcDefinePCell is just invoked once - at the
time you want to compile the pcell. Since the pcell code is then compiled into
the cellView, there's no need to load it again in subsequent sessions.

If your pcell calls any functions that you've defined yourself, then those
need to be loaded in each session. See the example that I just posted about
a stretchable rectangle which preserves the area - the two functions
abRectWidthChange and abRectLengthChange would need to be loaded
in each session, but the pcDefinePCell would only need to be loaded by the pcell
developer when he is recompiling the code to change the functionality.

Regards,

Andrew.

 

Hi Andrew

The thing is that I have a load(PCells) in the init file to make sure that
all users actually load the correct skill file. If one user has loaded the
file then, as you say the code is compiled into the cellView. But if I need
to make a correction to one of the PCells then this change is not going to
have effect before all users have closed cadence down and one then restarts
cadence. That is why I would like to know if I can steal the lock from
another user and then recompile the change into the cellView.

Another reason for my question is the lack of elegance in my 'solution' now.
All users try to load the PCells but only the first to do it is allowed to
compile the thing .. all other users get the warnings. I would like to
espand the setup so that Cadence checks for the write lock for the PCell
skill file and then only try to compile it if this has not already been
done.

Best,

Jan

 

Jan,

But your method doesn't help in any way!

Even if you could steal the write lock (which could be done by using the
clsAdminTool, perhaps), any user who has the existing cellView in memory
won't get the updated code until they either exit, or do a View->Refresh.

If users never compile the code (and only you compile the code), then the
situation is exactly the same, if they have already opened the pcell, then they
won't get the change until they either exit or do a View->Refresh.

The approach you're taking is fundamentally wrong (apologies for being
so brutal).

If you really must do it this incorrect way (which I still see no avantages in),
then the solution is to add something like this after the pcDefinePCell (after
the close parenthesis):

cv=dbOpenCellViewByType("libName" "pcellName" "layout" "a")
dbSave(cv)
dbPurge(cv)

But you really should _NOT_ be compiling pcells in every user session. That
just doesn't make sense.

Andrew.

 

Hi Andrew

Thanks for your reply .. and I'd rather have the brutal truth than the
softer ballpark talk
Well .. I'll try to give it a go once more

1) When the first user to open that particular design kit has to load and
compile the PCells .. how would you suggest I handle the situation where
user #2 opens the same kit? How do I check to see if the PCells have already
been loaded at this point in time?

2) As the setup is now, if a PCell needs to be updated I have to ask the
first user to reload the skill file. This would then update the compiled
PCells but the other users, with already open views, would still need to
refresh. I would still like to steal the lock and then update the compiled
PCells and ask users to refresh. If the first user has left for the weekend
without terminating cadence .. no PCell errors can be made effective until
the following Monday .. and also .. I like to feel that I am in charge

Best,

Jan

 

Jan,

If you didn't get every user to load the code which compiles the pcells,
neither of the issues below would be an issue. So I still don't understand
why you keep wanting to do this?

Surely it's clear that only the person who is developing the pcells (presumably
you) needs to load the code which defines the pcell, whenever you need
to make a change. Then you'd never have any problems about locking,
and everyone would see the latest pcell as soon as they access it for the
first time.

As I mentioned, if you really insist on approaching this this way (the wrong
way...), then adding a save and purge after the definition would free up
the lock in any session that defines it. But I can't see any sense in doing
that - why redefine the pcell in every single session if there is absolutely
no benefit in doing this.

Regards,

Andrew.

 

Hi Andrew,

It is not me who wants to do it like that .. in the design-kit documentation
it is stated that the PCells must be loaded each and every time the
design-kit is started. Maybe that is not the case? The way I read the
documentation to the design-kit, then the compiled PCells are 'lost' each
time all Cadence users close the program .. and therefore .. the first user
to open the design-kit has to recompile the cells again? Either that or I
should have an always running Cadence open .. Or maybe it is just me that
have misunderstod how the loading and compiling of PCells work?

/Jan

 

Hi Jan,

What design kit is it? It's absolutely wrong that the pcells must be loaded each
time the kit is started. If there are any functions used by the pcells, then
these must be loaded each time - exactly as I said in my original reply, but
there is absolutely no need to do the pcDefinePCell each time.

Most design kits are supplied and used readonly, so it would be completely
untenable if the Cadence tools required you to recompile the pcell in every
session.

Think about it another way. At the moment, the first user is compiling the
pcell, and keeping the lock on the pcell. The second user manages to use
the pcells OK despite the fact that he couldn't recompile them - so if it works
for the second user, it would work for the first if he didn't recompile them
either!

Regards,

Andrew.