1 Introduction

This document specifies a Programming Interface (PI) and corresponding Information Model (IM) which constitute Release 1.0 CAD Framework Initiative Standard for Design Representation data. This document is the work of the CFI Design Information Technical Committee's 1.0 Design Representation Working Group.

1.1 Statement of Purpose

The goal of the CFI Design Information Technical Committee's 1.0 Design Representation Working Group is to define a means for CAD tools to create, access, or modify electronic design data in other CAD tools or databases. This is in support of the CFI goals of tool interoperability, tool interchangeability, data substitution, and data translation.

The Design Representation Working Group's approach to this problem is to define a formal information model (IM) and a programming interface (called the DR-PI) based on the IM. The Information Model identifies the relevant object types in the domain of interest and specifies the attributes of each object type, including its relationships to other objects.

Release 1.0 of the IM and the DR-PI is limited to the domain of ELECTRICAL CONNECTIVITY information. The scope for the IM and the DR-PI is defined by the connectivity information needed for netlisters (EDIF, VHDL, . . .), logic simulators, timing analyzers, synthesis tools, layout tools, and flatteners, all of which work on hierarchical electrical connectivity data.

1.2 Problem Statement

Tools integrated into a CAD framework (or otherwise providing interoperability) require access to design data. A standard means of interactive (run-time) access can avoid translation from one design data format to another. There are two parts to this problem: (1) defining a specific common access mechanism for design data and (2) achieving sufficient consensus across the industry that this specific solution is acceptable and useful. Unless the second part is satisfied, it is unlikely that the CFI DR-PI will become a standard.

So, the 1.0 DR Working Group must do two things:

Define a particular means for CAD tools to represent, access, and manipulate design data, and
Achieve a consensus on that particular means among the members of the committee in order to drive the formation of a common guideline for the industry. Both are substantial problems, and they must be solved in parallel.

1.3 Solution Approach

An approach has been defined for solving each of the two problems.

1.3.1 The Design Data Access Problem

In the initial meetings of the DR Working Group, the committee quickly decided on an interface-oriented approach for solving the design data access problem. The approach is to define a Programming Interface (PI) which may be implemented in various programming languages (initially in C) and invoked directly from CAD tools. This programming interface is called the Design Representation Programming Interface, or "DR-PI." It was also quickly decided that, to define the DR-PI, an Information Model (IM) for the data to be handled by the DR-PI must first be defined. The IM shows abstractly what design information is made accessible via the DR-PI. The IM represents both the organization and the semantics of that information.

Note that the IM and the DR-PI do not constitute the design of any particular database facility. The IM is not a data model. Instead, each implementor (or provider) of the DR-PI must perform the appropriate mapping between the data model of their actual database and the organization of the CFI Design Representation Information Model. Particular data models and the transformations behind them can (and likely will) be proprietary to particular vendors.

The DR-PI provides access to actual design information, and it also provides an interface to a particular system's data without revealing the underlying implementation. It is a mask which is "put on" by that system and through which all access and manipulation of the data is provided. There is no implication whatsoever that the underlying data must be physically organized exactly like the IM.

To provide this access to the design information, the DR-PI is "handle-" or Object ID- (OID) based. No data structures are created or returned directly. Instead, the DR-PI defines a set of primitive types: such as integer, float, and string, and enumerated types: such as for specification of port direction, and OIDs that provide the "handles" to instances of the entities defined by the Information Model.

OIDs may not be assumed to be pointers and may never be de-referenced directly by DR-PI users. Access to both the attributes and relationships of a design object is only via DR-PI procedures applied to its OID. In particular, the C structure member operators "." and "->" are never used to access fields of a design object because the OID need not be a pointer (though it may be one in a particular implementation).

The Information Model is presented in the form of diagrams using the EXPRESS-G notation, as English text describing those diagrams, and as EXPRESS language text [1]. Each procedure in the DR-PI corresponds to some operation on design data in the domain specified by the IM. When possible, EXPRESS is used to define the semantics of those operations. When not, English text is used. Both EXPRESS and English are used to state the rules which are to be enforced as the information is manipulated.

1.3.2 The Consensus-Building Problem

Achieving the consensus of a large group of technical people with widely differing personal experience is a complex, laborious task. As the DR Working Group has grappled with this problem, an approach has grown out of the many attempts at listing the issues and bringing them to a state of closure.

This approach is based on democracy and electronic-mail. During meetings, different people will present technical approaches to the problems under consideration. Issues and concerns raised by working group members now must be submitted in writing. Between the meetings, these issues and others are distributed electronically. The issues are presented in a form that allows the members to vote their agreement or disagreement. When disagreement is voted, a member can supply a counter-proposal to be voted on by the group. This approach is proving to be an objective, unemotional procedure for obtaining decisions.

1.4 Scope

The scope of the Information Model is restricted to NETLIST or ELECTRICAL CONNECTIVITY information. This corresponds approximately to the EDIF Netlist View, encompassing Cells, Ports, Nets, Instances, and Port Instances.

Table of Contents

Next Chapter