• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. PCell Package

Stats

  • Replies 1
  • Subscribers 142
  • Views 788
  • Members are here 0

PCell Package

thiruvenkata
thiruvenkata 2 months ago

Hello, I need some clarifications regarding PCell packaging for the end customer.

  1. Should I create a library containing all the PCells and only include the dependency files (like procedures and utilities) in it, triggered through libInit.il — or should I also include the encrypted PCell code and CDF code separately along with the dependencies?

  2. Which type of encryption is the safest: .ile or .cxt?
    I’ve also come across .cbe — what is that?

  3. Can I convert a CDF.il file into a context file (.cxt)? The file starts with database handle APIs, which are not recommended for use when generating a context file. If it's possible, how can I properly convert the CDF file to a context file?
  • Sign in to reply
  • Cancel
  • Andrew Beckett
    Andrew Beckett 2 months ago

    Some answers:

    1. It doesn't really matter. You can lump together any auxiliary functions called by your PCells and your CDF callbacks into a single containing file if you like - or you can keep them separate. The one thing you shouldn't do is load any code that is directly calling pcDefinePCell from your libInit.il, because that would try to recreate the PCell again at initialisation time; that not only needs write permission, but would mean your pcell is going to keep getting redefined. The code in the body of the pcDefinePCell is stored within the view (e.g. the layout, symbol, schematic view for the PCell). Similarly you should not redefine the CDF from the libInit.il - just provide any CDF callbacks.
    2. The binary .cxt file is generally safest, but it is more work to generate. An encrypted file (often called .ile or .ilse - but the suffix is not actually that important) isn't very secure if you just use encrypt("code.il" "code.ile") but it's better (not particularly robust cryptographically but not trivial to read the plaintext) to use encrypt("code.il" "code.ile" "mypassword") and then loaded with load("code.ile" "mypassword"). Password encrypted files require understanding of the encryption algorithm to decrypt, and knowing the password (which you need for loading the file) does not enable the user to easily decrypt them.
      A ".cbe" file is not a standard suffix, but it's a convention some foundries use for an encrypted file containing their SKILL callbacks. It could equally be called ".ile" or in fact have any suffix you want!
    3. I'm not sure what a "CDF.il" file is. If it's what is dumped from the Tools->CDF->Edit form, then you don't want to load this from the libInit.il - once the CDF is created, it's stored in property bags in the library and the code needed to construct that only needs to be run once rather than every time the library is used. For some more info on context creation, see this recent thread (from this week): Creating Context file

    Andrew

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information