At some point every company doing chip design will struggle with the following question:
How do we manage the complexity of our EDA tool installations?
Different people will come up with different answers to this question (even within the same company). As best as I can tell the solutions people come up with fall into four general categories:
- Ad hoc
- Included in run scripts
- Configuration file
- Wrapped binaries
Ad hoc
The ad hoc environment is usually the way most companies
start laying out their EDA tool installations. The most organized thing about this type of installation is the directory
structure that gets created – usually in the form of /tools/{vendor}. If the engineer installing the tools is a
little more experienced, you’ll get something like /tools/{vendor}/{toolname}/{version}. Unfortunately, at some point during the
creation of the EDA industry the major players got together and made (one can
only assume) a solemn pact that each company would use a different directory
structure for their tool installations. As
a result, it is difficult to create a clean directory structure that doesn't
also take up a lot of disk space and confuse people familiar with a specific
vendor’s installation hierarchy.
Once the directories are laid out, the next step is to determine how to set up the user’s environment. In the Ad Hoc approach each user either adds the appropriate variables to their local shell configuration file or sources a site/project specific file. Because of the way the files are sourced, it is possible for a user to corrupt their EDA tool configuration causing failures that can be difficult to debug without blowing away all user modifications and rebuilding the environment from scratch. To prevent this type of issue from occurring, environment variables are often configured by run scripts.
Environment Settings Contained By Run Scripts
Under this scheme, the script used to kick off individual or batches of tests sets all necessary environment variables. This helps ensure the environment will be correct and makes it likely any errors that occur will be reproducible between different users. Additionally, by keeping the run script under revision control it is possible (assuming all of the tool versions are still available) to reproduce old builds without worrying whether changes in tool versions will cause unexpected failures.
There are a few issues that need to be considered when using this approach. First, what happens if your project needs to be run on servers at multiple sites? What happens if license servers change? Will you be able to seamlessly move everyone to the new servers without making them patch their current build directory? You'll want to modularize the script so that you can load the appropriate configuration information dynamically (information such as the base location for all tool installations, pointers to license files, etc.). These types of issues can lead people to create an environment where tool installations are managed by a central CAD group and the only information that must be provided to configure tools correctly is the list of tool names and versions that are needed.
To Wrap or Not to Wrap
Configuration files can be set up in two ways. The first way allows scripts or users to create a list of the tool versions they'd like to use. Behind the scenes, all of the appropriate variables are set up in the user’s or script's environment. Binaries are pulled directly from tool installation directories. The advantage to this approach is that you don’t have to anticipate all of the ways an end user might want to have tools interact with each other. If I want to use DDD or GBD to debug C++ code that has been dynamically linked in with a simulator, everything I need is available directly from the environment. I don't have to hack around to create a solution that looks suspiciously like the “Ad Hoc” approach described earlier. One disadvantage is that it is possible for a user to mess up tool configurations by adding additional variables to their environment after the EDA stuff has been setup. If a script directly sources the EDA configuration files it will override any user specific settings, limiting the impact of errors to a user’s own environment.
The second way for a user to take advantage of configuration files is to create wrappers for the binaries of individual tools. The mechanics of how this works is beyond the scope of this post. The general idea is that when I go to call a tool (like “specman” or “ncverilog”) I actually end up calling a wrapper script that sets up the environment appropriately and then calls the real binary which is hidden somewhere in the file system. The benefit of this system is that it is impossible for the user to mess anything up as long as they have the bin directory for the tools in their path. So what could possibly be wrong with this system? Tool interactions need to be carefully managed within the wrapper system so that I can call different tools together and have all the environment variables set up correctly. As I hinted at above, trying to use the C/C++ debugger in this type of environment can be a nightmare. It can also be difficult to access libraries tucked away in the nooks and crannies of a tools installation directory. The impact of these problems can be mitigated in some instances by providing hooks in the wrappers to pull out useful bits of information for use in scripts that need to pull different tools together. Another way to solve the problem is to not allow end users to do things that aren’t supported… well, ok… that’s not really a solution at all but that hasn't stopped CAD organizations from giving it a try! Advanced users who like to push the envelope when using EDA tools bump into the limitations of these types of systems very quickly and end up having to pull in the CAD organization to make modifications to the tool flow.
What Is the Problem We're Trying To Solve?
I've said nothing in the preceding discussion about the characteristics of the problem we're trying to solve. We'll just have to save that for another post!
