From: ahearn@cds2050.cadence.com (John Ahearn)
Subject: Design Archiving
Organization: Harris Semiconductor
Date: Mon, 28 Sep 1992 15:28:51 GMT

	I have been reading, with a great deal of interest, the on going
discussion about Design Archiving.  I, with the aide of several others,
have been pursuing this issue with members of Cadence Framework group.

	The following is a rather lengthy email I wrote up awhile ago on the 
subject.  Partners refers to the various technology partnerships Cadence has 
formed with companies (Harris being one of them).

	I would be more than happy to pursue this discussion with anyone
interested.

---
  The intent of this document is to explain why Harris needs Cadence to 
support a method for upward compatibility and archiving design data. If you
have any questions or comments please feel free to contact me at x4470 or 
ahearn@cadence.com. It is our intention of reviewing this memo and any 
discussions with Cadence, with all of the partners.

  Harris has been using Cadence software from the early days of SDA v1.0. 
Over the years the process of migrating design data from one version to the
next has gotten less and less automated and more and more complicated. The 
Cadence solution was to run a piece of AE-ware and then do a lot of hand 
editing. Depending upon the nature of the data, it was usually easier to 
start from scratch or use an industry standard format, such as GDSII or EDIF,
 for translating the data.

  While these translators are less than advantageous, the process of starting 
from scratch is extremely painful. To make matters worse these pieces of 
AE-ware have gone unsupported and in many cases, lost or forgotten. This 
means that starting from scratch is the only method for taking some of our 
older designs forward. This has us greatly concerned since the life-span of 
some of our designs is between 5-10 years.

  In the past when a problem like this occurred, it was possible for us to 
load an older revision of the software on a machine and either work from 
there or do the conversion. However, due to the speed with which hardware 
and operating systems are becoming obsolete it is becoming more and more 
difficult to do this.

  There are two camps within Harris as to how the problem of upward 
compatibility should be addressed. The first camp feels that Cadence should 
use successive translation programs to update the database. The second camp 
feels that Cadence should define or adopt a canonical save format for 
abstracting the data from the software.

  Due to the complex nature of the data the first camp feels it is impossible 
to derive one format for holding all of the currently supported 
representations. They use the failure of EDIF as an example. The second camp 
points out the extremely poor translators from the past and talks about the 
success of GDSII.

  To be more specific, the first camp would like Cadence to take the issue of
database migration more seriously and offer a robust translation program. 
This translation program should allow a user defined Skill program to help 
with the translation. However this user defined routine should not be critical
to a successful translation. In the past the translation program left most of
the problems of translation to the user. The user routine should only be 
worried about user defined properties, etc. These translation programs should 
then be combined under an intelligent supervisory program that performs the 
necessary translations to update a database to current.

  The second camp realizes that it is extremely difficult to define a format 
that will support the entire Cadence database as it exists now. However, had 
Cadence developed a canonical save format long ago there wouldn't be such an 
issue with the database. Now that there is a new system, there is also an 
opportunity to correct this problem.

  We understand that the Cadence database is still a moving target. However, 
we want a serious effort at deriving this format. For the sake of expediency 
we would be willing to look at a format that could address certain 
representations. Those representations that are fundamental to bringing old 
designs forward. These are the representations that can not be generated 
through tools. These representations have also been the most stable. These 
representations include, but are not limited to layers, schematic, extraction 
rules, extracted, symbols, placement, layout, and masks.

  Please note that another benefit of the canonical save format is that it 
also addresses the issue of machine dependence (byte ordering).

  Perhaps the solution is a combination of the two. In the restricted solution
above the format for saving textual data (i.e. extraction rules) does not 
address the changes that take place in that representation. Typically these 
representations are not the output of a program (i.e. placement abstract) so 
they must be saved. However, they are related to the physical process and not 
to the design. These representations must, in the normal course, be translated
over to each new release. A complete solution would need the restricted 
canonical save format and robust translation routines for the remaining data.

  On the issue of Design archiving, we need a facility that can extract out 
the dependencies of a design. This includes everything from schematics to 
extraction rules to simulation models to layout, etc.

  The facility should offer switches for controlling how much of the design 
hierarchy is archived or restored. For example if a design makes use of 
standard parts libraries and models than user should be able to archive only 
the references, or the individually referenced parts, or the entire library. 
This goes for types of data for archiving.One user may only be interested in 
the original schematic while another might want to archive everything down to
tool log files.
----- End of Memo ----




--
John Ahearn 		Cadence Design Systems / RO3-3127
ahearn@cadence.com	555 River Oaks Parkway
			San Jose, CA 95134
			(408)428-4470 FAX (408)944-7265