Now that almost all of the major custom design tools run on OpenAccess, we often get asked about how well Calibre supports OpenAccess (OA). The truth is that Calibre has supported reading polygonal data from OA since February 2007 and we have kept up with the new releases of OA as they come along. What has really driven adoption of OA in the last year or so has been the release of Virtuoso on OA, the availability of PCELL caching from Ciranova and Cadence, and the IPL effort. Now, the Synopsys and Springsoft custom design tools are getting on the bandwagon and suddenly there are enough customers using or evaluating OA-based design tools that the question of Calibre compatibility comes up.
First of all, be confident that the existing stream-based (GDSII) verification flow is not going away. OA adoption is still in a nascent phase and we expect that customers will always prefer to do final verification on the same file that they will deliver to the foundry — the GDSII or OASIS file.
The basic steps to getting Calibre running on OA are the following:
- Tell Calibre that you want to use OA and point it to the library and topcell
- Create a lib.defs file to define where the library and topcell are located
- (optional) Configure the version of OA and compiler your database used
- (optional) Configure the location of custom libraries for OA plug-ins
Items #1, #2: Basic set-up. If you don’t have PCELLs in your design, running Calibre from OA is as simple as making a few changes to your rulefile or Calibre Interactive and creating a lib.defs file. In Calibre Interactive, you can specify OpenAccess as the source format on the Inputs pane. Alternatively, you can add the following statements to your rule file:
LAYOUT SYSTEM OA
LAYOUT PATH “libraryName”
LAYOUT PRIMARY “topcellName”
where of course “libraryName” is the name of your OA library and “topcellName” is the name of your topcell. Then, you simply have to create a lib.defs file in your home or run directory. A typical lib.defs file can be as simple as the one line “DEFINE libraryName ./lib/topcellName”.These steps cover items 1 and 2 above.
Item #3. Calibre is currently shipping with the 22.04p007 version of OA. In most cases, this will work for you even if you are using an older version of OA. However, you may be using a very new or pre-release version of OA. In this case, you will need to set the OA_HOME environment variable to point to your OA installation.
Item #4. PCELLS. However, most people using custom design tools will also be using one or more forms of PCELLs. Of course the dominant PCELL provider is Cadence (SKILL-based). However, there are now TCL-based (Springsoft, Synopsys) and Python-based (Ciranova) PCELLs. You must have a plug-in from one of these providers linked into the OA library to enable Calibre to read the PCELLs from the database. Conceptually, this isn’t difficult, but you have to get the path to the plug-in and the plug-in libraries set up properly, which can be a little challenging when you are used to simply pointing Calibre at a single GDSII file.
If you are having problems getting Calibre to read your PCELLS out of the database, there are a couple of steps to take. First, make sure that the “Abort on PCELLs” option in Calibre is turned off. Second, make sure that you can use the utility oa2strm to create a GDSII file containing the evaluated PCELLS from the database. The oa2strm ships with the OA libraries and can be found in the MGC_HOME tree or your own installation of OA. If your set-up is right, oa2strm will create a valid GDSII file and Calibre should not have any OA-related problems. On the other hand, if oa2strm doesn’t create a valid GDSII file with all of the evaluated PCELLs, then the problem is in your paths and set-up and not in Calibre.
I hope that this is helpful. We also have a more detailed AppNote that is available if you want more information.
Let us know if you are using Calibre with OA and your experiences.