Cadence library encryption?

Discussion in 'Cadence' started by Erik Wanta, Feb 4, 2004.

  1. Erik Wanta

    Erik Wanta Guest

    Has anyone written anything to keep all the cells in a dfII library
    encrypted and decrypt when they are opened?
    Erik Wanta, Feb 4, 2004
  2. Interesting topic !

    The problem with this, is that once decrypted, the data may be
    re-saved as un-encrypted data ...
    Perhaps there is a way to make read-only libraries and in this way
    the encryption may be preserved ... But this seems not existing
    since 4.4.x

    Kholdoun TORKI
    Kholdoun TORKI, Feb 6, 2004
  3. Erik,
    If your trying to provide a 3rd party with a read-only
    version of the data, I have a way in slam to do this.
    Basically, you'd read in the gds, "protect" the cells, then
    provide the protected data to the 3rd party along with the
    viewer program. After the cells are protected, only the viewer
    program can open them. The third party would not be able to
    open the cell and export it again. It's sort of an undocumented
    feature in my system.
    I couldn't quite tell what you were trying to achieve,
    so I may be completely off with this reply.

    Mike Stabenfeldt
    Mike Stabenfeldt, Feb 6, 2004
  4. Erik,

    A way to encrypt DFII databases :

    1) Use the Skill command "dbWriteSkill" to dump an entire
    cellview into a Skill file. (look at the DFII Skill Ref. manual)
    If you use it with argument g_ref true, then all the reference
    cellviews will be dumped out and included in the file.

    2) Use "encrypt()" Skill command to encrypt the result.
    The encryption protect the Skill file from being ascii, but
    every one can execute it. If you want to prevent this, you may
    encrypt with a password, and release the password only to
    whom is concerned.

    Hope that this help.

    Kholdoun TORKI
    Kholdoun TORKI, Feb 7, 2004
  5. Erik Wanta

    fogh Guest

    This is, I suppose for archiving. If that would be for tranfer, I guess
    you would have no reason to transfer a library and then a key: you would
    retaion the library and transfer it at the time you would have the key.
    So, when that is for archiving, why don t you use a standard way of
    doing this:
    -cleanup the library
    -put it in a tarball
    -create a MD5 hash of the tarball
    -encrypt it with good-old unix trippleDES "crypt", or some other fancy.

    I take the occasion to put forward my 2cents about encrption in analog
    encrypted callbacks
    + encrypted spectre device models
    + encrypted behavioural verilogAMS
    + encrypted assura ruledecks
    =total blindness
    =non-functional IC
    fogh, Feb 10, 2004
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.