OpenAccess 2.0 (OA20)

Date:  Fri, 21-Oct-2005
Section: Cadence

Cadence Interoperability using OpenAccess 2.0

OpenAccess is a central storage database for the next generation EDA design flow. It replaces GDS and DEF, as well as many other text files. The entire design flow moves from a file based system to a database system.

OpenAccess is developed by Si2 in collaboration with all major EDA vendors.

In practical terms, this means that e.g. Cadence Virtuoso and Cadence Encounter access directly the central database. There is no longer a GDS export/import or DEF export/import.

This tutorial shows how to convert existing design libraries to OpenAccess, how to store an Encounter design in OpenAccess and how to make changes to the design in both Virtuoso and Encounter.

This tutorial uses the NCSU design kit and the OSU standard cell library. The following data is required for this tutorial:

  • NSCU PDK 1.4
  • OSU standard cell library 2.4
  • Cadence ICOA 5.1-41
  • Cadence SOC Encounter 4.1

The lib/cell/view model

OpenAccess uses the familiar "lib cell view" model, which is already used in Virtuoso. For instance we could have "mychip block1 layout". Now Encounter supports this model as well. Where we created "block1.def" or "block1.gds" in the past we can now save the design as "mychip block1 layout" in the OpenAccess database.

The cds.lib file

Virtuoso user are already familiar with "cds.lib". It is a file that specifies where on the file system the libraries are located. What's new is that now Encounter reads the "cds.lib" file as well.

Tutorial Overview

The following file contains all the data required for this tutorial:

This tutorial will perform the following steps:
1) Convert the NCSU and OSU libraries to OpenAccess (OA)
2) Implement a small demo design in Encounter and save to OA
3) Open the design in Virtuoso
4) Delete a wire in Virtuoso and save back to OA
5) Load the design from OA back into Encounter
6) Route the deleted net and save back to OA
7) Load the design back into Virtuoso and remaster

Before we begin, a quick look at the included files:

The file "cdb/cds.lib" has to be customized to point to wherever the NCSU and OSU files are installed on the system. The script "create" will convert them to OpenAccess. The folder "soce" contains a small example design we will implement using OpenAccess. The folder "lef" contains the LEF file from the OSU library, but split up into the technology section and the library section. That is because the technology part is imported into the NCSU DF-II library, whereas the library part corresponds to the OSU DF-II library. The file "display.drf" defines the colors in the Virtuoso Layout Editor.

Converting libraries to OpenAccess (OA)

At the beginning of this flow we have the NCSU techkit and the OSU cell library available as Virtuoso libraries in "cdb" format, which is the conventional database used for DF-II until IC51-41. We now convert the "cdb" libraries to "OA20" for use with ICOA51-41.

Note that all of this happens "under the hood". The designer only interfaces with DF-II, not directly with "cdb". To the designer it is transparent which database we utilitze withing DF-II. However he will notice (in a good way that suddenly a lot more tools can access his data without painful translations!

The translator is called cdb2oa. In addition, we will use lefin. That is because the OA database will be used for digital designs as well, so we can integrate the LEF file, which was a separate tech file for digital designs, into our central database.

The tutorial includes a script create which handles the conversion of the NCSU kit and the OSU library. The input to the script is a "cds.lib" file that points to those libraries. The script expects that file in the folder "cdb". So at this point you need to open the file "cdb/cds.lib" in a text editor and change the path names to match your installation. If you don't already have the NCSU and OSU libraries, you can download them from the respective websites. You can use e.g. "pico" or "emacs" to edit the file. When done you are ready to call the "create" script:

cd cdb
pico cds.lib
cd ..
./create
cat cds.lib

When "create" finishes we do "cat cds.lib" to verify the created libraries. The OpenAccess converter "cdb2oa" automatically added an entry for each library that was converted.

For schematic design we require also the library "basic", which comes with ICOA51. The command to add it to "cds.lib" is:

echo "DEFINE basic $CDSHOME/tools/dfII/cdslib/basic" >> cds.lib

Note that this assumes that $CDSHOME points to your ICOA installation. Substitute the actual path on your system so that the full path is valid. At this point the "cds.lib" should look as follows:

Now we have our libraries converted to OpenAccess and defined in "cds.lib". So we are ready to start ICOA:

icfb

To open the Library Manager use "Tools -> Library Manager". It should present all the libraries from "cds.lib":

We can already see that there is no visible difference between IC51 and ICOA51. The underlying database is different, but the user framework is the same. Just to see if the library is valid, lets open the layout of any cell in the OSU cell library:

At this point we have a complete design environment in OpenAccess. We could perform analog in Virtuoso as usual. The big change is that we can now also use digital tools with our libraries.

Cadence Encounter and OpenAccess

The tutorial files include a small demo design "nrdcore". It is a 8-bit divider and ALU. We will synthesize it using PKS and then implement is using Encounter. Then we will save to an OpenAccess database, and not to a GDS file as we would have done in the past.

To run PKS update the file "pks/compile_bgx.scr" if necessary. The PKS flow is identical to the usual flow:

cd soce
pks_shell -f compile_bgx.scr

The output should look like this:

Now we have a gate-level netlist in "nrdcore.vh" and timing constraints in "nrdcore.sdc". On the Encounter.

Take a quick look at "encounter.conf" in case you have to update any path names. Also note that "encounter.conf" defines the variable ui_oa_reflib. It contains the names of reference libraries. in our case those are the NCSU Ami06 technology library and the OSU standard cell library. During export Encounter will reference these libraries for things like vias and standard cells. Now run Encounter:

encounter -init encounter.tcl

Note that "encounter.tcl" does not contain anything magic. We just use it as a time saver. It will floorplan the design, route the power and then perform a quick place and route. When done it will open the final design in the GUI. This part of the implementation is identical to the usual flow:

Now comes the new step: Export to OpenAccess. Do "File -> Save OA Design". We will have to specify the library, cell and view, just like in DF-II. We choose "nrdcore" for both the library and cell name and "layout" for the view". This will create a new library "nrdcore" and create the cell-view "nrdcore layout" in it. All the standard cells and vias will be referenced from the NSCU and OSU libraries:

After the OpenAccess export the Encounter command window should look like this:

Now that we saved the design we can exit from Encounter. Let's take a quick look at the "cds.lib":

cat cds.lib

The first line was already there in the tutorial templates. It includes the main "cds.lib" file so Encounter can find our NCSU and OSU reference libraries. The second line was added by Encounter.

Now let's go back to Virtuoso and look at the layout:

icfb

We notice that our design is indeed just another library in the Library Manager:

Double-click on the "layout" view to open it in Virtuoso. You can use "shift-f" to expand all the standard cells. We see that we have the complete layout in Virtuoso, where we now have full mask-level edit capabilities. And we never used a DEF or GDS file, or any translation for that matter, at all.

Virtuoso - Encounter Interoperability

Although we have seen a nice example of OpenAccess so far, now we will go one step further. A common example, especially under time pressure before tape-out, is the need to make small changes to the layout. Usually making the change takes less time than cleaning up the layout afterwards. Or some digital cells had to be moved and now we need to rerun the digital signoff flow. In the first case we would like to use Encounter to perform the cleanup and potential re-route for us. In the second case we must bring the design back to Encounter for the sign-off flow.

In this tutorial we will do the following: We will randomly choose a wire and delete it. We won't delete a full net, just a segment of a net, to further complicate things. Then we will let Encounter fix the design for us. And we will double-check the result back in Virtuoso. In business terms we are performing an "Engineering Change Order" (ECO).

We left the previous section with the layout open in Virtuoso. Now use the right mouse button to zoom into the upper left corner. Then randomly click on a wire segment to select it:

The segment will be highlighted when it is selected. Then hit the "Del" key to delete the segment. Then click the "Save" icon, which is the top icon on the left icon bar.

Now we have modified the design and stored back in the OA database. We will now bring it back up in Encounter, again with out any translation.

After closing down Virtuoso and ICOA, start Encounter:

encounter

Do "File -> Restore OA Design". Then select in the dialog box our "nrdcore nrdcore layout" view:

We see the restored design in the Encounter window:

We could zoom into the area where we deleted the net. But we will let Encounter's "Verify Connectivity" find the broken net for us. Do "Verify -> Connectivity" and uncheck "Antenna", since we can already assume that the broken net will also cause an Antenna violation:

When the check is finished Encounter will highlight the broken net for us. Now we can easily zoom in with the right mouse button. We notice that Encounter already recognized that a segment of the net was missing so it removed the entire routed net. And the connectivity check added markers that show the unconnected pins and unrouted net:

Now we will call NanoRoute again to clean up the design. We are only making a local change so we certainly don't want the entire design rerouted. Instead, we use NanoRoute in ECO mode, where it only routes unrouted nets. To bring up NanoRoute, do "Route -> NanoRoute...". Then check the "ECO" mode button:

The routing should take not long at all, since we only had one unrouted net. We can then see that our net is now routed again:

We can do a final connectivity check to ensure that our design is clean. It should not report any violations.

Now we completed the digital part of the ECO flow and can save the design back into the OA database. Do "Design -> Save OA Design" and fill in "nrdcore nrdcore layout". Then exit Encounter.

Now we bring up "ICOA" again and load the layout back into Virtuoso. During the entire ECO flow we have been able to focus on the design. All the bookkeeping was done by OpenAccess. We never had to worry about things like layer mappings, name spaces, bus-bit-style and so on.

Design Remastering in Virtuoso

So far we used the "abstract" view of the standard cells. That view is equivalent to the information in a LEF file. It contains only the information required by Encounter, so there was no need to use the full "layout" view of the cells.

At this point we will assume that we have signed-off on the design and prepare for tape-out. Now we can replace the "abstract" views with the "layout" views. This process is called "remastering". Note that this is not a one-way street. We could easily remaster back to "abstract" views and perform another ECO loop if we needed to.

To perform remastering, do "Design -> Remaster Instances..." in Virtuoso. We can specify library and cell names. But in our case we simply replace the "abstract" view of all cells in all libraries. So we only have to fill in the view names "abstract" and "layout":

Now we have the final mask-level layout. We can zoom in and see the individual transistors of each cell. This design could readily be sent to the foundary. But as we noted, we could easily remaster back to "abstract" views.


This article comes from www.chiptalk.org
http://www.chiptalk.org

The URL for this article is:
http://www.chiptalk.org/modules/wfsection/article.php?articleid=12

Copyright (c) 2013 by www.chiptalk.org