Whenever you upgrade to a new OpenAccess version, always read the release notes in What’s New.

Use the Same Version as Cadence Virtuoso

When I want to know which version of OpenAccess to use, I look to Cadence Virtuoso. Virtuoso 6.1.3 is on DM4, so I am too. OpenAccess 22.04_p028 is a good DM4 version.

DM3 OpenAccess Databases Saved as DM4

When you open a design that was saved using DM3, OpenAccess DM4 translates it to DM4. If you save it, it will be saved as DM4, and OpenAccess DM3 will no longer be able to read it. Skip the save, and your persistent database on disk remains DM3.

OpenAccess DM4 also reads DM3 tech objects, but as always, the tech object is not saved when you save a design. You must save it directly in order for the upgraded DM4 version to appear on disk.

oacDataModelRevNumber tells you the data model of the OpenAccess version you are using.

More oaAssert Assertions

The number of assertions doubled from OpenAccess 2.2.5 to 2.2.6, and doubled again from 2.2.6 to DM4 22.04_p028. More assertions is a great thing, but it means that the run time behavior of OpenAccess debug libraries and optimized libraries continues to diverge. Just keep this in mind.

When an oaAssert fires, it throws an exception of type oacInternalError. For example,

Internal OpenAccess Error: Expression [netHashMap.get(netTbl[i]) == i] returned
false in file oaGlobalMem.cpp at line 463

If you get an assertion failure from OpenAccess debug code, try running the optimized code to see what happens with assertions elided. If you find an inappropriate assertion, make sure to report it.

Don’t Dial D for Debug

Up until DM4, the OpenAccess shared libraries compiled for debug had a D appended to their file name. For example, the optimized shared library file name was named something like liboaBase.so, and the debug library was named liboaBaseD.so.

The D has mercifully been dropped in DM4 so that the shared library file names for optimized and debug libraries are the same–the path name alone determines the type of library. To continue the above example, in DM4 the optimized and debug oaBase shared library files are both named liboaBase.so.

The DM4 release contains symbolic links for backward compatability of shared library files. For example, in lib/linux_rhel30_gcc411_64/dbg/, liboaDMTurboD.so is a link to liboaDMTurbo.so. However, there is no link liboaUtilD.a.  Further, the DM4 plug-in interface only loads the non-D library. If you link your application so it can load only the D libraries, it will not be able to load any plug-ins. You won’t get anywhere without a DM plug-in. You may never see these problems, but the easiest way to avoid trouble is to simply do it the new way: stop appending a D to the shared library file name when linking to DM4.

Here’s how to get started. Your comments and corrections are always appreciated.

Create an Eclipse Workspace

• Download and install Eclipse IDE for C/C++ Developers. Eclipse is included with most Linux distributions, but an update to the latest version is worthwhile. Only C/C++ Development Tooling (CDT) version 4.0 and above are professional quality.
• Choose a workspace directory that will contain OpenAccess and related applications, for example, /home/jm/src. You probably already have such a directory–just use it as is.
• Start Eclipse. In Gnome, it can be executed by selecting Applications > Programming > Eclipse from the menu.
• Specify your workspace path, like /home/jm/src
• The Eclipse Resource screen will appear. Select Workbench - Go to the workbench. The Eclipse workbench appears. This is where you will be spending most of your time in Eclipse.

Create a Project for OpenAccess

If you want to use Eclipse to edit and recompile OpenAccess, you must download OpenAccess to a location within your Eclipse workspace. For this, use the following procedure.

OpenAccess comes with precompiled libraries that work fine. If you do not need to recompile OpenAccess yourself, you can put OpenAccess in a location outside your workspace, and add OpenAccess as a linked folder.

Set Up the Project

• Download OpenAccess to a suitable location within your workspace, such as /home/jm/src/oa/22.04p028
• Create a new project for OpenAccess. Right click in the Project Explorer window. In the context menu, select New > C++ Project. Alternatively, select the menu command File > New > C++ Project.
  • Specify a project name, such as OA
  • Uncheck Use default location, and specify the Location of the oa/ directory within the OpenAccess software, such as /home/jm/src/oa/22.04_p028/oa
  • Since OpenAccess is already complete with all source and build files, select Executable > Empty Project so that Eclipse will not add any files. The other Project types choices are more useful when you start a new project.
  • Click Next to advance to the Select Configurations. Two configurations, Debug and Release are available by default.
  • Click Finish to dismiss the Select Configurations dialog. If the dialog refuses to close, make sure the Location you specified is a full path to a location within the workspace.
• A dialog will ask, This kind of project is associated with the C/C++ perspective. Do you want to open this perspective now? A perspective is an arrangement of windows within the Eclipse workbench. Click Yes, and the C/C++ perspective appears. This perspective is suitable for writing code. Later, you will encounter the Debug perspective that displays different windows suitable for debugging.
• Project OA now appears in the the Project Explorer window. Expand folders by single clicking, and open files by double clicking.

Set Up Building

• Create an oa_install target for the Debug configuration
  • Right click on the OA project in the Project Explorer folder. Set the active configuration to Debug using Build Configurations > Set Active > Debug.
  • Right click on the OA project in the Project Explorer folder. Select Make targets > Create in the context menu. The Create a new Make target dialog appears.
    • Specify oa_install for both Target Name and Make Target
    • Specify make OPTMODE=dbg for Build command
    • Click Create
• Create an oa_install target for the Release configuration
  • Right click on the OA project. Set the active configuration using Build Configurations > Set Active > Release.
  • Right click on the OA project. Select Make targets > Create in the context menu. The Create a new Make target dialog appears.
    • Specify oa_install for both Target Name and Make Target
    • Specify make OPTMODE=opt for Build command
    • Click Create
• To build OpenAccess for a configuration,
  • Right click on the OA project. Set the active configuration using the Build Configurations > Set Active command.
    
  • Right click on the OA project. Select Make targets > Build
  • In the dialog, select oa_install
  • Click Build to recompile OpenAccess

Create a Project for Each of Your Applications

The next step is to add a project for each of your own applications. You do it in much the same way as described above.

Set Up the Project

• If your application already exists, check out the source hierarchy to a suitable location within your workspace, such as /home/jm/src/mower/oa2mw
• Right click in the Project Explorer window. In the context menu, select New > C++ Project to create a new project for your application. Alternatively, select the menu command File > New > C++ Project.
  • Specify a project name, such as oa2mw
  • The default project location is the directory with the same name as the project, immediately under the workspace directory. If this is not the case, uncheck Use default location, and specify the path within the workbench, such as /home/jm/src/mower/oa2mw.
  • Select from the Project Types:
    • If your application already has source and build files, select Executable > Empty Project so that Eclipse will not add any files
    • If you are starting a new application, choose the type of Project types that matches your style
  • Advance to Select Configurations by clicking Next. Two configurations, Debug and Release are available by default. They should be sufficient for now. You can easily add more later.
  • If you will be using your own Makefile, rahter than the Eclipse internal builder,
    • Click Advanced settings. Select C/C++ Build.
      • Select Configuration Debug
        • Uncheck Use default build command
        • Specify the appropriate command to build your application for debug, such as make OPTMODE=dbg
        • If the default Build directory is incorrect, uncheck Generate Makefiles automatically
        • In Build directory, specify the working directory in which your Makefile should be run, for example, ${workspace_loc:/mower/way/Debug}
        • Click Apply
      • Select configuration Release
        • For most applications, the default Build command (make) is in fact the correct release build command. If not, uncheck Use default build command, and specify the command to build your application optimized, such as make OPTMODE=opt.
        • If the default Build directory is incorrect, uncheck Generate Makefiles automatically
        • In Build directory, specify the working directory in which your Makefile should be run, for example, ${workspace_loc:/mower/way/Release}
        • Click Apply
      • Click OK
  • Click Finish to create the project. If the Select Configurations dialog refuses to close, make sure the Location you specified is a full path to an existing location within the workspace.
• A dialog may ask, This kind of project is associated with the C/C++ perspective. Do you want to open this perspective now? A perspective is an arrangement of windows within the Eclipse workbench. Click Yes, and the C/C++ perspective appears. This perspective is suitable for writing code. Later, you will encounter the Debug perspective that displays different windows suitable for debugging.
• Your project now appears in the the Project Explorer window. Expand folders by single clicking, and open files by double clicking.

Set Up Building

Here I assume that you will be using your own Makefile, not the Eclipse internal builder.

• Establish the relationship between your application and OpenAccess:
  • If you created a project for OpenAccess, Right click on your project in the Project Explorer folder. Select Properties. In the Project References section of the Properties dialog, check OA and any other projects on which this project depends.
  • If OpenAccess is not a project within your Eclipse workspace, follow the instructions to create a linked folder within your application’s project.
• To build OpenAccess for the currently active configuration, use the Project > Build Project command

Add OpenAccess to Your Application Project as a Linked Folder

If you want to put OpenAccess in a location outside your workspace and merely refer to it, add OpenAccess to your application project as a linked folder using the following procedure. This works best for larger installations where client applications require access to the same stable OpenAccess release.

However, you will not be able to edit and recompile OpenAccess. If you want to do this, add OpenAccess as a distinct Eclipse project.

• In the Project Explorer, right click to select the project to which you want to add OpenAccess
• In the context menu, select New > Folder. Alternatively, select the menu command File > New > Folder. The New Folder dialog appears.
• Specify a folder name, like OA
• Click the Advanced button. The dialog expands to show more options.
• Click Link to folder in the file system
• Specify the path to the oa/ directory within the OpenAccess software, such as /usr/local/eda/oa/22.04_p028/oa
• Click Finish

Ready for the hack? There are probably former employers you do not want in your LinkedIn profile. Yet you want to connect with the people who work(ed) there. Just momentarily add the company to your profile, search for your friends and invite them to connect. Then delete the company from your profile before anyone sees it.

Abusing this hack will probably get you kicked off LinkedIn, as it should. So only invite people who would welcome an invitation from you.

Still, leave as many companies as possible in your profile, so your former colleagues can find you in the future.

Procedural access to other EDA companies’ design databases was out of the question. As Avanti CEO Gerry Hsu once declared, “We let nobody suck our blood. We suck other people’s blood, but nobody sucks our blood!” Gerry considered interoperability between his tools to be the lifeblood of Avanti, a competitive advantage that was to be jealously guarded. While other CEOs were less graphic that Gerry, all EDA vendors who had any blood to suck shared his attitude. Meanwhile, EDA users got by using text files for multivendor interoperability.

Finally, powerful EDA customers like Agere, Hewlett-Packard, IBM, Intel, LSI Logic, Freescale and STMicroelectronics got fed up with the limitations of text file data exchange and demanded procedural access to a common database. While the intervening machinations are beyond the scope of this paper, the result is that everyone now has C/C++ procedural access to both Cadence/Si2 OpenAccess and Synopsys Milkyway.

API or File Exchange?

The question is now whether you as an EDA tool developer should take advantage of the Milkyway and OpenAccess APIs, or stick with the classic LEF, DEF, Verilog and GDSII.

File exchange is appealing because it seems so easy:

• Virtually every other tool reads and writes the popular text file formats
• Readers and writers with APIs are available
• They are familiar to most everyone
• They are human readable (except GDSII)
• They can be edited manually or with Perl, sed or awk (except GDSII)

Unfortunately, time consuming problems lurk beneath the apparent simplicity of file exchange:

• File writers know nothing about where their data will go; file readers know nothing about the data source
• LEF and DEF are flat formats. The user must specify each individual design to transfer.
• Tools read and write their own incompatible dialect of the text file format
• Each file format represents only a single view of the design, so multiple files are required
• Multiple files presents the opportunity for file skew, where all files are not from exactly the same version of the design
• Each file format has its own unique semantics, which are yet again different from the semantics of the databases on either side of the file transfer
• More often than not, you must edit the files to fix some problem. The required edit is often particular to the tool version used and the individual design.

Therefore, “our tool simply reads and writes LEF and DEF” becomes much more involved in actual practice. Your AE and customer must:

1. Start with a perfectly good, cohesive design database
2. Tear it apart into giant files with incompatible semantics
3. Edit the files to correct problems
4. Add a custom configuration file containing additional missing data that is missing in the standard file formats
5. Read all the data in all the files, using command line options determined through extensive experimentation
6. Reassemble the data
7. Troubleshoot the inconsistencies:
   • Between writers and readers
   • Between files exchanged (including the evil file skew)

The trouble can be reduced by spending the time to build a solid flow and supplying it to your AEs and customers. A Makefile-driven flow is especially effective in reducing the risk of file skew.

If you are doing an evaluation, many weeks will pass as you repeatedly pester your prospect with requests for the right data. The sales opportunity may pass before your tool ever sees complete, consistent input data. When you present your results, your sales prospect faces another ordeal reading your data back into their design environment. By the time they finish, your results may not look so exciting.

Control in File Exchange Flows

The worst problem with file exchange is all the nasty things that happen to the design data before your tool even sees it, and what happens after your tool writes it. For example, consider how little control you have over the DEF input flow:

Someone else (often your competitor) controls the foreign database, file format, and the translation between them. The best they can do is blindly write the file, not knowing what you expect. It is very difficult for them to test their results. By the time you get the file, the data you need may be missing, erroneously translated, or even obfuscated.

You are in the same situation when it is you writing the file. Even with the best of intentions, it is difficult to know how the data you write will be interpreted.

Further, the interface problems will be different for each design style, each tool and each version of tool with which you exchange files. This is responsible for the profusion of confusing command options on all file readers and writers.

Next, let’s have a look at specific examples of file exchange interfaces for which there is no satisfactory solution, only an unstable workaround.

Case 1: Milkyway to OpenAccess via LEF and DEF

While Milkyway LEF Out does an fine job of creating LEF MACROs (cell masters),

• The LEF TECHNOLOGY section must be created either manually, or with a custom program
• The boundary of rectilinear macro blocks is converted to a rectangle

Milkyway 2004.06 has a much-improved DEF writer, write_def. Even so,

• def2oa cannot read the blockages output by write_def
• Identical cell instances appear multiple times
• Double cut vias and notch/gap geometries appear in the DEF SPECIALNETS section

If you are using an earlier version of Milkyway DEF Out, the problems are almost intolerable:

• The TAPER statement is incorrect
• DEFAULT vias are used in NONDEFAULT routes
• Vias are not properly rotated

These problems necessitate changes to the tech file, which causes delays because the library group must approve them. Worse, before writing DEF, all blocks must be re-routed with Astro using the new tech file. This kind of nonsense is often fatal to a benchmark or tool evaluation.

Case 2: OpenAccess to Milkyway via DEF

After successfully transferring the data to OpenAccess from Milkyway, you will see more problems on the way back to Milkyway:

• Inconsistent handling of bus delimiters will cause the Astro router to re-route parts of the design
• The above problem changes subtly depending on whether the bus in the original Verilog netlist was bit-blasted

This file transfer requires a custom Perl script for each DEF, because some busses may be bit-blasted and others may not. Any netlist changes may require a modification to the Perl script.

Case 3: LEF and DEF from Milkyway back into Milkyway

This should be a very straightforward flow. Not so.

• Since many individual files are involved, merely assembling a complete, synchronized set of LEF and DEF files is quite difficult.
• Only the most basic technology rules are translated from the LEF TECHNOLOGY section. Hopefully you have the original Astro tech file.
• Milkyway read_lef and read_def each output a Scheme side file that define and assign variable route rules. If your net names look like regular expressions (like bus[3]), the rule may be assigned to the wrong net, or to no net at all. Regardless, you must manually edit the file.
• read_def creates multiple ports on nets, which is illegal in Milkyway. Mower’s detailed diagnostics caught this error.

The above case studies cannot describe the full extent of the file exchange problems that anyone might encounter. Maintaining the translators and flow is a nightmare because the problems never end, changing from tool to tool, version to version, and design to design.

The API Flow

I have had as much success as anybody building and running multivendor design flows using file exchange. Still, their robustness and utility pales in comparison to the interfaces that can be built using a C/C++ API to databases like Milkyway and OpenAccess.

The API flow has several key advantages:

• Control over the entire translation
• Stability across tools, versions and design styles
• No translation to or from file format semantics
• Fast, in-memory data transfer
• Access to the entire hierarchy of a single cohesive database with all views
• Bidirectional data exchange, and even sharing the same design in memory

The API interface extends inside both databases in a multivendor flow, giving you extraordinary control:

Because the interface has access to the entire hierarchy of the input and output designs, the interface can automatically decide what to do, and translate with minimal user guidance. For example, when asked to translate a cell from Milkyway to OpenAccess, Voom Mower™ checks to make sure that OpenAccess contains all necessary child cells, and recursively translates the missing cells from Milkyway. In contrast, DEF interfaces depend on the user to specify which hierarchical cells to output.

Without the intermediate file format, only one translation, directly from database to database is required. Development is easier, because binary databases are similar to each other, but quite different from text files. Further, since all your design data is unlikely to fit in a single text file format, this single API interface replaces not just two file translators, but four, six, or even eight translators, each invoked on multiple files. It is then up to your support staff to help the users figure out how to correctly apply all these translators.

The data stored in design databases is remarkably accurate and stable across versions. This is enforced by the fact that inside the database, the tools all must eat their own cooking–even leftovers from last night’s version. The API gives your tool a seat at the same table with Astro and Virtuoso.

Conclusion

Design data interchange using text files is simple enough in theory, but in actual practice text files provide an unstable and incomplete interface. With text file exchange, if some tool forgets to write the data you need, they don’t care. That’s your problem.

For a reasonable up-front investment, your tool can have a robust, easily maintained, easy-to-use link to Milkyway or OpenAccess through a published API.

Get Voom

If your tools are based on OpenAccess, eliminate sales objections, save development time and instantly make your tools a part of the Synopsys Galaxy Design Platform. Get Mower, the industry’s only bidirectional Milkyway-to-OpenAccess translator.

If you use your own proprietary design database, we will apply our unique combination of Milkyway and OpenAccess application programming, tapeout and multi-vendor flow expertise to quickly make your software a natural, integrated extension of Synopsys and OpenAccess physical design flows.

Here I present a system configuration that allows FLEXnet to work with DHCP connected to different networks, or connected to no network at all. This configuration is tested on Red Hat Enterprise Linux 3.0 and 5.0.

DHCP Protocol

The Dynamic Host Configuration Protocol (DHCP) is an Internet protocol for automating the network configuration of computers. The DHCP server automatically assign IP addresses, the subnet mask and default router, and provides other configuration information such as the addresses for printer, time and news servers. A computer using DHCP can easily connect to any network that has a DHCP server. It is therefore very popular on laptop computers.

Acresso FLEXnet (formerly Macrovision FLEXlm)

The Acresso FLEXnet license manager is a popular license manager that supports floating licenses. Using TCP/IP, client machines access a license server to check out and check in licenses to run software. This works well when the license server has a static IP address.

The FLEXnet End User Licensing Guide is very useful. For some reason, the Acresso web site is the only place you cannot get this manual. So just search the Internet for “FLEXnet End User Licensing Guide”, and take your pick.

What Goes Wrong with FLEXnet and DHCP

Laptop computers usually employ the DHCP protocol, in which the IP address is always changing. When the laptop is not connected to a network, it will often have no IP address at all. This makes FLEXnet unable to find the vendor daemon on the network via TCP/IP, even though it is actually running right there on the same machine.

The purpose of the localhost loopback in /etc/hosts is to enable the machine to talk to itself over the network, no matter what the network configuration. This seems like the perfect solution, but merely specifying localhost (or 127.0.0.1) in the FLEXnet license file does not work.

SERVER localhost 000205AB3F60 17000 # Incomplete solution

The FLEXnet license manager daemon, lmgrd, at some point still tries to use the real host name. When the real name is looked up in /etc/hosts and DNS, it will most likely be missing or have an IP address different from the IP address assigned by DHCP, so the vendor daemon cannot be found, and license check out will fail.

The Solution

The solution is to add the machine’s real name to /etc/hosts as an additional loopback.

For example, suppose that a laptop using DHCP is named goon. It has its own floating license, and is therefore the license server. In the /etc/hosts file, define a loopback for the name goon:

127.0.0.1 localhost loghost # Always present
127.0.0.1 goon goon.voom.net # Added for FLEXnet
#
# Do not forget to remove any existing entry for goon!
### 192.168.1.4 goon goon.voom.net
#
# Continue with any other host entries…

The FLEXnet license file should contain the real host name, as usual:

SERVER goon 000205AB3F60 27000

Now, no matter what DHCP does, the IP address of the FLEXnet license server is 127.0.0.1.

With DHCP, you may never have to change your network configuration, even when your laptop is not connected to any network. If you do need to change configurations, the Red Hat Linux Network Configuration tool (System Settings > Network or system-config-network) can help you. This tool saves each network configuration in a “profile”. When you switch profiles, it restores the previously-saved network configuration, including the /etc/hosts file.

FLEXnet uses the MAC address of your first network device (usually Ethernet interface eth0) to identify the server hardware. This network interface must be active when the FLEXnet license daemon lmgrd starts.

Download PDF

This is based on Milkyway and OpenAccess Design Data Interface Scope: What Can You Access?, presented on June 20, 2006 at the 17th Synopsys EDA Interoperability Developers’ Forum.

It is good design practice to use as few SDC files as possible. This post describes a way to create a single SDC file that can be used both before and after clock tree synthesis (CTS), and by both Cadence PKS and SoC Encounter.

Test Mode SDC File

You will still need at least one more test mode SDC file for use when fixing test mode hold violations. You can put the design into test mode in SoC Encounter 3.1 only with set_case_analysis contained in a separate, full SDC file. The design can be put into test mode in PKS dynamically using the set_constant_for_timing command, but I have not actually tried this.

Functional Mode SDC File

Define the clocks as propagated. For example,

set_propagated_clock {clk200 txclk rxclk}

Create a virtual clock for each clock that appears in set_input_delay or set_output_delay. For example,

create_clock -name clk200v -period 5 -waveform {0 2.5}
create_clock -name txclkv -period 5 -waveform {0 2.5}
create_clock -name rxclkv -period 5 -waveform {0 2.5}

Usually, timing paths between clock domains are marked as false paths in the SDC file (if there is only one clock in your design , there will be no such false paths). Add set_false_path,

• From each virtual clock to each real clock
• From each real clock to each virtual clock

For example, suppose that false paths between the real clock domains are already defined in the SDC file as follows:

set_false_path -from [get_clocks {clk200}] -to [get_clocks {txclk}]
set_false_path -from [get_clocks {clk200}] -to [get_clocks {rxclk}]
set_false_path -from [get_clocks {txclk}] -to [get_clocks {tclk200}]
set_false_path -from [get_clocks {rxclk}] -to [get_clocks {tclk200}]

Add the corresponding false paths to and from the new virtual clocks:

set_false_path -from [get_clocks {clk200v}] -to [get_clocks {txclk}]
set_false_path -from [get_clocks {clk200v}] -to [get_clocks {rxclk}]
set_false_path -from [get_clocks {txclkv}] -to [get_clocks {tclk200}]
set_false_path -from [get_clocks {rxclkv}] -to [get_clocks {tclk200}]

set_false_path -from [get_clocks {clk200}] -to [get_clocks {txclkv}]
set_false_path -from [get_clocks {clk200}] -to [get_clocks {rxclkv}]
set_false_path -from [get_clocks {txclk}] -to [get_clocks {tclk200v}]
set_false_path -from [get_clocks {rxclk}] -to [get_clocks {tclk200v}]

Define network latency for the original clock and source latency for the virtual clock. Use the same value for both. This latency is your estimate of the clock latencies in the surrounding blocks, not the current block. Even so, it is quite common to use the latency for the clock in this block as a best guess of the clock latencies in other blocks.

set_clock_latency 2.0 [get_clocks {clk200}]
set_clock_latency -source 2.0 [get_clocks {clk200v}]

The -network option is the default, so it it omitted. Here, we are guessing that the surrounding blocks will eventually contain a clock tree with an insertion delay of 2.0nS.

Change the reference clocks for the input and outputs to the virtual clock. For example,

set_input_delay 2.5 -clock [get_clocks {clk200v}] [get_ports {garbageIn}]
set_output_delay 2.5 -clock [get_clocks {clk200v}] [get_ports {garbageOut}]

This is equivalent to changing the delays to set_input_delay 4.5 and set_output_delay 0.5. It is however, much more convenient to adjust a single set_clock_latency than to add and subtract delays to all IO pins.

Specify cells that you do not want to be used as set_dont_use.

set_dont_use TLATNX20
set_dont_use TLATNXL

Note that this is a less restrictive list than the list used during logic synthesis. During logic synthesis, cells like clock buffers, clock gate cells, delay cells, and scannable flip-flops are usually marked as dont_use, but not here.