Data Management for Designers

Back when I was a programmer at VLSI Technology in the mid-1980s, I was responsible for all the data management in the VLSI Design Tools. By responsible for, I mean that I designed the whole system and wrote all the code. Prior to the 5th release of our product, there was no data management, designers simply used filenames and it was up to them to keep track of what they were doing. Of course, as software developers, we had a source-code control system. We actually rolled our own before eventually we switched to ClearCase years later, then almost the standards before the open source alternatives like subversion and git took over.

The challenge with data management for designers is three fold. Firstly, designers are not software engineers and so complex configuration schemes the software people are used to are going to either baffle them or not get used. By complex configuration I’m talking about things like forks and merges. Secondly, designers often live in a graphical environment on their desktop and are not just typing commands into a command line interface. This means that any data management needs to be integrated into the tools so that it doesn’t require the designer to go somewhere different. The third thing is that the files involved are either binary or, even if text, are meaningless to the designer and only mean anything to the software engineers creating the tools. For example, looking for changes in a netlist the way it is represented in a file using a text diff type tool is not useful.

I implemented the standard checkout/checkin procedure, whereby each designer had their own sandbox (I called it a working library) and projects had a controlled library, and then there would usually be several read-only libraries that held things like standard cell data and could not simply be changed and usually formed part of the release of the process node from the foundry (or, in the case of VLSI, our own library development organization). These were integrated into the tools cleanly. If a designer in a layout editor changed a cell, it would automatically be checked out.

It is interesting how many of these basic concepts live on in ClioSoft’s data management. The implementation is more modern, and it has to be integrated into several different layout/schematic environments, not just one. Almost all designs teams are geographically distributed these days so that needs to be cleanly supported. Designs have grown so large, too, that optimizing the use of disk space is important, rather than duplicating every file many times.

But it is still the case that design is very different from software development:

• Users are working at higher abstraction levels such as libraries and cells and are not necessarily aware of the directories and files that store the data.
• Design tools create files that contain design data as well as temporary run files that need not be managed. End users do not know which files should be managed and which should not.
• A design flow has several complex tools sometimes from different vendors. Each tool organizes data files in different ways.
• A design object such as a schematic or layout is usually made up of multiple files created by the design tool with software-generated names.
• The size of the data is much larger. There are many more files and several of them are large binary files.
• Designers often think in terms of design hierarchy that is not apparent when looking at the file system.

The bottom line is that it is not appropriate to use a software-oriented configuration management system for managing design data. It is not integrated with the design tools, it requires designers to know far more than they should about how their data is actually represented on disk and it forces them to learn unfamiliar concepts.

ClioSoft’s data management addresses these concerns. It has a simple model, with the complexity hidden by the ClioSoft software. It is cleanly integrated into all the most popular layout environments (for example, the above picture shows the integration with Cadence’s Virtuoso environment, but it is also integrated with Synopsys Custom Designer and Mentor’s Pyxis). And it understands design representations so that it can show changes in the same graphical environment.

Also Read

Modern Data Management

Cadence ♥ ClioSoft!

A Brief History of ClioSoft