Browse Prior Art Database

Self-Describing File Vintage for Hardware System Design Files

IP.com Disclosure Number: IPCOM000037343D
Original Publication Date: 1989-Dec-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 4 page(s) / 122K

Publishing Venue

IBM

Related People

Stetler, WC: AUTHOR

Abstract

The current logic design process proceeds through multiple iterations before the design if finally released to manufacture. At any point in time multiple versions of a particular hardware component design file may exist. Each version has an associated level identity that indicates the particular level of design verification and function. Simulation, timing, and design verification models are constructed using the design files. In the past, control of the design levels was a manual process subject to error. The lack of automated level control allowed the use of inconsistent design levels for model build, resulting in problems solved but not included in the model being rediscovered when the model is run, and an unclear view of the remaining changes to be incorporated into subsequent models.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

Self-Describing File Vintage for Hardware System Design Files

The current logic design process proceeds through multiple iterations before the design if finally released to manufacture. At any point in time multiple versions of a particular hardware component design file may exist. Each version has an associated level identity that indicates the particular level of design verification and function. Simulation, timing, and design verification models are constructed using the design files. In the past, control of the design levels was a manual process subject to error. The lack of automated level control allowed the use of inconsistent design levels for model build, resulting in problems solved but not included in the model being rediscovered when the model is run, and an unclear view of the remaining changes to be incorporated into subsequent models.

Multiple systems exist for tracking problems uncovered during design verification and testing, for example, the problem management system (PMS), DESA, PTM, etc. These systems provide an ability to document problems as they are uncovered and to assign a unique problem tracking number to the problem. By associating the tracking number with the design file version, a history of design changes in response to problems can be developed.

(Image Omitted)

The concept of retaining the level identity of each file used for model build and associating, with that model, the aggregate of these level identities for all files comprising the model is described here and is being implemented for a new program. The problem solution history can be incorporated by associating the file version with the problem tracking numbers of solutions incorporated into a design change. These self-described model levels will be incorporated into a file associated with the model itself in machine readable form for data reduction purposes. By accessing the problem tracking system, the detailed descriptions of problems and solutions can be reviewed.

The alternative procedures outlined here are in terms of the Design Library EXECS and capabilities, although the concept may be implemented using other libraries.

(Image Omitted)

IMPLEMENTATION APPROACHES

Three approaches to implementing the level control procedures are being pursued to define and develop more automated approaches to level control and model build processes. They are presented below in the order of highest degree of automated assistance to the model build process. Each results in machine readable data about the design changes included in a model.

Alternative 1) Each library data file could contain the current list of problem solutions incorporated in each design file. This is truly self-describing data at the file level. Model build processing would carry the level description of all files and the aggregate of this data would represent the model level description.

1

Page 2 of 4

(Image Omitted)

Alternative 2) Each model will be specified in terms of the file levels...