This paper describes the unique, ground-breaking development of persistent SDC-equivalent timing constraints within industry-standard OpenAccess design database.

1. Into the Depths of OpenAccess: Timing Constraints Implementation
Timothy J. Ehrler, Senior Principal Engineer
Philips Semiconductors, Design Technology Group
8375 S. River Pkwy., Tempe, AZ 85284
tim.ehrler@philips.com
Abstract
The OpenAccess EDA application database was
contributed to the industry by Cadence Design Systems,
whose in-house development team has performed all core
code development. This contribution includes the
maintenance of current and future API and reference
implementation releases as well as the implementation of
roadmap items prioritized by the OpenAccess Change
Team. One such requested item, in response to Figure 1 - OpenAccess Development Roadmap
OpenAccess Coalition member company requests, was
the development of sufficient capabilities to incorporate Development of API support for timing and other design
timing constraint information within the database. This constraints, a significant item within the roadmap, was
could not be immediately undertaken by Cadence, initiated with the formation of the Timing Constraint
however, due to a lack of available resources with which Workgroup. The responsibility of this group was to define
to develop and implement these capabilities. the timing constraint data requirements compatible with
intent of common industry use of Synopsys SDC [2]. The
Because of its importance to the migration efforts within resulting specification [3] was delivered to the change
Philips Semiconductors and other coalition members, we team for consideration by Cadence as the core code
resourced this development to accelerate its availability. development and integration provider. Since Cadence
This paper, then, describes this development and resources were fully committed to the development of the
implementation effort, which was the first of its kind upcoming OpenAccess 2.2 release, the change team
outside of the contributing Cadence development and requested implementation resources from its members.
integration teams. The development process, experiences, Philips Semiconductors, recognizing the importance of
and encountered issues are addressed within, including this capability, both within Philips as a critical migration
those regarding database/package hierarchy & data requirement as well as among other coalition members,
inheritance and extended design & value data structure contributed the necessary resources and successfully
implementation. Particular attention is paid to related implemented the timing constraints and transferred the
issues concerning compatibility with past and future deliverables to Cadence for integration.
releases.
2. Planning for Success
1. Introduction Planning for this development project followed the
In order to formally guide the evolution of OpenAccess Philips Overall System Realization Process (OSRP),
beyond the original requirements, and in accordance with which defines the formal process for all phases of project
prioritized set of enhancements proposed by the execution, including required documentation, gates, and
OpenAccess Coalition, the OpenAccess Change Team milestones. Because many of the document requirements
maintains a “live” technology roadmap [1] that defines were satisfied by the change team and workgroup
the direction of development over the next few releases. deliverables, the process was tailored as a subproject, as
The general roadmap is shown in Figure 1. shown in Figure 2, subordinate to the overall OpenAccess
release development.
- 1 of 8 -

2. PS
CS
PIA
CA
SRA PC
4. Gaining Insight
OpenAccess
Change CRS Integration The source code base on which development began was
Team
build 5 beta release b005, which was later migrated to
Timing
Constraints
Work group
FRS public release 2.2.0 [4]. The development team was only
very generally familiar with the public 2.1 release [5], and
Implementers PIF PMP Sched changes from that release to this beta release revealed
many critical programming and “philosophical”
S/W UTR
differences that impacted this effort.
UsM
To satisfy future extensibility and flexibility
requirements, however, the concept of rules was
Figure 2 - OSRP Development Process transformed into one of constraints beginning with this
set of 2.2 releases, with the corresponding change from
the oaRule class to new oaConstraint and related classes.
The approach taken to planning this development was
This change, as well as the accompanying hierarchy
based primarily on available resources. A pair of
associated with their implementation and use model,
resources was originally dedicated to this effort – the
forced some changes of the original estimates and task
primary at 50% availability and the secondary at 75%.
allocation.
Planning estimates resulted in an initial duration of ~90
days, which ended up being significantly affected by
factors and issues encountered later. While the oaRule class was relatively simplistic, as shown
in Figure 4,
Resource estimates were based on building upon the
technology rule class oaRule in a rather straightforward
manner, the simplicity of the development timeline of
which is shown in Figure 3.
Figure 3 - Project Plan Duration Estimates
3. Equipping for Development
Development platform selection resulted as much from
the source code installation capability as from platform
and development environment availability. HP-UX
installation was uneventful, but development capabilities
were limited, if any. Linux installation was fraught with
issues, but the development environment was adequate
and stable. Since our primary objective concerned Figure 4 - oaRule Schema
development, this led to installation on a shared directory
on an HP-UX system with data management under CVS. the oaConstraint class and use model is considerably
The development was then done in a Red Hat Linux more complex, as shown in Figure 5. This required a
environment, with GNU gcc C++ compiler and gdb different and more inter-dependent development approach
debugger, which proved sufficient for the task. than originally anticipated.
- 2 of 8 -

3. 6. Enforcing Compatibility
Enumerated data type values are defined by the
sequentially enumerated private subtype values of related
data items, and offset within the public data type
enumerations by the first item of that data type. An
example for values is shown in Table 2.
Private SubType Public Type
Definition Value Enumeration Value
oavValueTypeBool 0x0000U oacBooleanValueType 218
oavValueTypeInt 0x0001U oacIntValueType 219
oavValueTypeFlt 0x0002U oacFltValueType 220
oavValueTypeLayerArray 0x0003U oacLayerArrayValueType 221
oavValueTypeInt1DTbl 0x0004U oacInt1DTblValueType 222
oavValueTypeFlt1DTbl 0x0005U oacFlt1DTblValueType 223
oavValueTypeInt2DTbl 0x0006U oacInt2DTblValueType 224
oavValueTypeFlt2DTbl 0x0007U oacFlt2DTblValueType 225
oavValueTypeIntFltTbl 0x0008U oacIntFltTblValueType 226
oavValueTypeFltIntFltTbl 0x0009U oacFltIntFltTblValueType 227
Figure 5 - oaConstraint Schema oavValueTypeDualInt 0x000aU oacDualIntValueType 228
oavValueTypeDualInt1DTbl 0x000bU oacDualInt1DTblValueType 229
oavValueTypeBoxArray 0x000cU oacBoxArrayValueType 230
5. Organization, Structure, & Relationships oavValueTypeValueArray 0x000dU oacValueArrayValueType 231
oavValueTypeViaDefArray 0x000eU oacViaDefArrayValueType 232
OpenAccess is organized as three related ‘packages’: oavValueTypeLayer 0x000fU oacLayerValueType 233
• base - generally available defined classes also used by oavValueTypeAntennaRatio 0x0010U oacAntennaRatioValueType 234
tech and design packages oavValueTypeAntennaRatioArray 0x0011U oacAntennaRatioArrayValueType 235
oavValueTypeViaDef2DTbl 0x0012U oacViaDef2DTblValueType 236
• tech - technical package derived from & based on
base package, intended primarily for use related to Table 2 - Value Type & Subtype Relationship
technology data but also usable by design package
• design - design package derived from & based on base Although the last three values are tech package values,
and tech packages, intended primarily for use related they are sequential to the preceding base package values
to design data because they were implemented at the same time. Since
many more enumerated public types surround this block
This ‘package’ relationship extends into all areas relevant of enumerated values, subsequent value implementations
to constraint definition and usage, ranging from values to could not be made sequential with these, as shown in
definitions to parameters to constraints. This concept not Table 3.
only defines the data hierarchy, but also significantly
impacts the base & derived class inheritance & data Private SubType Public Type
Definition Value Enumeration Value
management elements associated with these class objects,
oavValueTypeString 0x0013U oacStringValueType 269
some of which are shown in Table 1. oavValueTypeDualString 0x0014U oacDualStringValueType 270
oavValueTypeQuadString 0x0015U oacQuadStringValueType 271
Package values data objects constraints oavValueTypeControlType 0x0016U oacControlTypeValueType 272
base oaValue oaObject oaConstraint oavValueTypeLoadType 0x0017U oacLoadTypeValueType 273
tech oaTechValue oaTechObject oaTechConstraint oavValueTypeStateTransition 0x0018U oacStateTransitionValueType 274
design oaDesignValue oaDesignObject oaDesignConstraint oavValueTypeStateTransitionArray 0x0019U oacStateTransitionArrayValueType 275
oavValueTypeTimingType 0x001aU oacTimingTypeValueType 276
Table 1 - Object Class Package Inheritance oavValueTypeTimingTypeArray 0x001bU oacTimingTypeArrayValueType 277
oavValueTypeClockRelation 0x001cU oacClockRelationValueType 278
oavValueTypePropagateType 0x001dU oacPropagateTypeValueType 279
Prior to the development of timing constraints, purely oavValueTypeTimingWindow 0x001eU oacTimingWindowValueType 280
design related values did not exist but were created for
design level constraint use. Previously, an oaValue could Table 3 - Constraint Related Value Types & Subtypes
exist for base, tech, or design usage or an oaTechValue,
derived from oaValue, could be used for base or tech The first three data types are base package related, the last
usage. Now, an oaDesignValue, derived from three are design package related, and the remaining are
oaTechValue, is specifically design related. An example tech package related. Not only are these items not
of this would be the value of an analysis timing window sequential with those previously defined, but neither are
(oaTimingWindowValue). No design-specific objects of newer values types sequential with previously
this type had previously existed, so this class, derived implemented ones within the same package. This is
from oaDesignValue also required definition, as did the forced by compatibility requirements that [enumerated]
associated data types. data types must remain constant among releases, but
complicates internal data management processes,
- 3 of 8 -

4. resulting in non-trivial code modifications in all affected concerted development efforts were started to implement
related areas. the required timing constraint information [3]. Based on
this architectural knowledge, the implementation
7. Virtual Persistence proceeded in the following order:
1. constraint related value objects
Even though OpenAccess is presented to an application as 2. constraint parameter definitions
an object-oriented C++ API, the actual manipulated object 3. constraint definitions
data is not the instantiated ‘API object’ itself. Instead, an 4. constraint objects
underlying ‘data table’ structure is manipulated through 5. design logic related objects
an associated ‘table object’. A much-simplified 6. clock related objects
representation of these relationships is shown in Figure 6.
data table Prior to much of this development, however, were the
modifications, enhancements, and additions to
API object table object
database architectural and structural areas of OpenAccess in order
storage
to accommodate the required hierarchically oriented and
derived data structures and data management mechanisms
necessary to support the implementation of the timing
constraint information model. Among those areas most
Figure 6 - General Object & Data Relationship significantly affected involved the extensions of:
• data type definitions and enumerations to cover
Although transparent to the application, this hidden additional data and object types
complexity allows database compatibility by isolating the • value objects into design package for isolation from
object from the data manipulation, while at the same time tech package
the manipulated data is isolated from the stored data, thus • constraint and constraint group member objects into
allowing for another level of compatibility. design package
Because of these object and data manipulation 9. Implementation Commences
relationships, and especially in the context of derived In addition to those private subtypes and public types
related objects, many non-trivial data structure and shown in Table 3, corresponding definitions and
derivative object modifications were required to ensure enumerations were required for data types and objects
compatibility while at the same time not degrading more directly related to constraints as shown in Table 4.
performance or data integrity. A very simplistic
representation of a small subset of constructs and their Private SubType Public Type
inter-relationships is shown in Figure 7. Definition Value Enumeration Value
oavConstraintDefTypeGeneral 0x0003U oacGeneralConstraintDefType 259
oaValue oaValueTbl oavConstraintDefTypeEdge 0x0004U oacEdgeConstraintDefType 260
in-memory database data
oavConstraintDefTypeClockRelated 0x0005U oacClockRelatedConstraintDefType 261
oavConstraintDefTypePath 0x0006U oacPathConstraintDefType 262
oaTechValue oaTechValueTbl
database oavConstraintDefTypeCompound 0x0007U oacCompoundConstraintDefType 263
storage
oavConstraintTypeGeneral 0x0003U oacGeneralConstraintType 264
oavConstraintTypeEdge 0x0004U oacEdgeConstraintType 265
oaDesignValue oaDesignValueTbl
oavConstraintTypeClockRelated 0x0005U oacClockRelatedConstraintType 266
oavConstraintTypePath 0x0006U oacPathConstraintType 267
oavConstraintTypeCompound 0x0007U oacCompoundConstraintType 268
oaClockRelationValue oaClockRelationValueTbl
Table 4 - Constraint Related Data Types & Subtypes
create instance
Figure 7 - Example Object & Data Relationships Note that by this time the timing constraints had been
logically classified into five categories:
It should be noted here that the information & values of • general - simple value constraint applied to a logic
object ‘type’ & ‘subtype’ constants serve as index & point
location information for data structures & data storage • edge - simple value constraint applied to a logic point
mechanisms. This illustrates the requirement for the with associated state transition
consistent values of such defined & enumerated constants • clock related - simple value constraint applied to a logic
across database releases to ensure and enforce point with associated state transition in relation to
compatibility and data integrity. clock with associated state transition
• path - constraint applied to a logic path with associated
8. The Structure Evolves state transitions
Having investigated and studied the organization, data
model, and relationships within OpenAccess in detail,
- 4 of 8 -

5. • compound - constraint applied to a logic point and in some areas to ensure compatibility and data integrity. A
requiring associated constraints for full constraint particular observation was that of the “compound”
definition (later re-defined) constraint category that contained a single constraint
concerning logic driving cells other than clocks. As
Also defined were the required design logic and analysis recommended, the implementation was changed to
related data object information shown in Table 5. include the transition constraint values as parameters to
the API rather than requiring their application as further
constraints for completeness. At the same time, the
Private Data Type Public Type
Definition Value Enumeration Value constraint specifying a clock driver was moved to this
oacClockDataType 74 oacClockType 256 same category, providing a consistent set of constraints
oacLogicPointDataType 73 oacLogicPointType 257 within this appropriately renamed “driver” category.
oacWaveformDataType 75 oacWaveformType 258
Table 5 - Design Logic & Analysis Data Objects Finally, implementation progress was significantly
impacted by the loss of one-half of the development team,
resulting in another extension to the schedule and
It must be noted here that the development and
ultimately the planned delivery date.
implementation of these data objects was not completed
until close to the end of development efforts due to
scheduling and resourcing issues. These were therefore 11. The Path[s] Well-chosen
defined in a very trivial manner so that development in all The concept of a logic design path, crucial to many of the
other areas could continue to completion, allowing a more timing constraint objects, did not yet exist within
efficient use of the available resources. OpenAccess. In order to prevent an explosion of
persistent constraint data, and enabling a more succinct
10. Embracing Change definition of multi-point paths, an encompassing
description of a logic design path is defined as “an
One of the more severe impacts on the development effort
ordered array of logic points”. Logic points in turn are
was the anticipated release of the production source code
defined as “a set of one or more connected occurrence
for the 2.2.0 release of OpenAccess. While not an
elements associated with a set of one or more signal state
insurmountable effort, the merging of source code
transitions”. Given the interconnected logic elements of
developed on the beta b005 base with that of the
Figure 8,
production release was not insignificant. In particular, the
juxtaposition of some constant definitions and ( , )
enumerations from the base development source code otA ( ) ( )
required a concerted effort to re-align current onC
oitD SET
D Q
development code to the production release. Furthermore, oitB
the lack of insight into what could have been a significant ( , ) CLR
Q
change in architecture, structure, or data models within
the production release necessitated a concerted Figure 8 - Example Logic Path
assessment of the released source code base to ensure that
no functional discrepancies resulted from the merging of
an encompassing logic path can be defined as:
the development code.
• starting at either the occurrence term otA or the
occurrence instance term oitb, and having either a
Later in the project, resource unavailability became a rising or falling signal state transition
serious detriment to the progress of this development
• passing through occurrence net onC with a falling
effort. Unanticipated periods of jury duty and extended
signal state transition
business travel, as well as critical internal issues requiring
• ending at the occurrence instance term oitD with a
the temporary re-allocation of resources to resolve,
rising signal state transition
extended the scheduled effort by one-third past the
original plan.
Implementation of this construct, however, required the
creation of a number of new design objects:
As development continued, discussions and code reviews
with system integrator Cadence yielded some • oaPathPointArray - an array (oaArray) of design
observations and suggestions that affected the then- objects (oaDesignObject*)
current implementation. In an effort to more concisely • oaStateTransitionArray – an array (oaArray) of
allocate data objects to the most appropriate package, a enumerated state transition constants
corresponding re-allocation was performed, resulting in (oaStateTransitionEnum)
the re-structuring of a large portion of implemented code. • oaLogicPoint – an object consisting of a set of one or
Furthermore, derivation and inheritance models were also more path points (oaPathPointArray) and a set of one
impacted, necessitating a more extensive re-organization or more state transitions (oaStateTransitionArray)
- 5 of 8 -

6. • oaLogicPointArray – an ordered array (oaArray) of Waveforms having all of the above characteristics would
logic points (oaLogicPoint*) be consistent with the current definition of an ideal clock.
More complex waveforms, however, may be defined by
Providing an implementation consistent with other combining state transitions to non-logical levels and non-
database objects, however, requires the capability for zero transition times. Representations of simple and
equivalence comparisons, revealing another unforeseen complex waveforms are shown in Figure 10.
issue. Homogenous tables of data base objects require
only the location index information, but heterogeneous 1
database object tables also require data object type H iZ ?
information. In previous OpenAccess releases this data
0
was implemented as structure type oaIndexTypePairData. ideal & logical com plex
However, since class member equivalence functions are
required for comparison purposes, this structure was Figure 10 - Simple & Complex Waveforms
converted to a class of the same name, and the
corresponding equivalence member functions A derived clock is basically an instance-specific
implemented therein. Although extensively used modification of a previously defined clock signal having
throughout the database implementation, this conversion propagated through one or more stages of design logic
had relatively little impact since a C++ structure is and having a defined set of transition characteristics.
actually the [most] trivial instance of a class - converting Although important for analysis and constraint purposes,
from a structure to a class had no impact on the data the four types of derived clocks are relatively trivial
structure or its use throughout OpenAccess. implementations compared with a created clock. The
types of derived clocks created for constraint purposes
include:
12. Beating the Clock • divided – derivative of existing signal, having its
Crucial for timing analysis, clocks must exist to enable frequency divided by an integer scaling factor
their application within the scope of timing constraints, • multiplied – derivative of existing signal, having its
hence the creation of the oaClock class object. As with frequency multiplied by an integer scaling factor
logic design paths, the concept of a clock had not • edge specific – derivative of an existing signal,
previously been defined within OpenAccess, either consisting of an ordered subset of edges
created with a waveform or derived from another signal. • shifted edge specific – derivative of an existing signal,
The relationships between waveforms and created & consisting of an ordered subset of shifted edges
derived clocks are shown in Figure 9.
13. Are we there, yet?
Because of the inter-related nature of the modifications,
design
logic
enhancements, and additions to the OpenAccess source
oaWaveform code required for even a prototypical implementation of
oaClock oaClock
(created) (derived)
the related constraint objects, very little isolated object
unit testing was performed as implementation progressed.
Figure 9 - Waveform and Clock Relationships Although interim and full builds were performed on a
regular basis during development, actual executable
Created clocks require the definition of a series of rising testing was necessarily postponed until at least a “critical
and falling signal transitions over a specified period to be mass” of development had been implemented – up to but
applied to design logic signal points for analysis purposes. excluding oaClock and oaWaveform development and
This “set of edges”, usually transitioning between logic implementation.
levels zero (‘0’) and one (‘1’) and having state transition
times of zero (‘0.0’), is defined with the oaWaveform An advantage gained by this approach was the early
class object. However, to allow for flexibility and future opportunity to “discover” development environment
extensibility of waveforms, the oaWaveform class was limits and restrictions not previously encountered. Indeed,
created that provides for the primitive clock signal early compilations revealed a makefile environment string
requirements noted above, as well as providing for limit that was exceeded when the additional source files
transition states other than logic level ‘0’ and ‘1’ and non- were included. Fortunately, this was easily resolved by
zero transition times. By allowing such capabilities, the judicious removal of “white space” within, but future
waveforms can then be defined as having one or more of releases will require modifications to this approach as
the following characteristics: more files are added and this string limit is once again
• logical - transition between logic states ‘0’ and ‘1’ exceeded with no remaining means of resolution.
• ideal - edge transition times of ‘0.0’
• circular - first edge transition start state same as last As implementation progressed to the point that execution
edge transition end state unit testing was applicable, decisions concerning the most
- 6 of 8 -

7. appropriate approach necessary for sufficient testing of 14. Delivering the Goods
the code were made. Rather than creating test benches
Deliverables for this project fell into four categories:
from scratch to properly test the various additions and
• project documentation - documents associated with the
enhancements to the OpenAccess code base, studies of
resulting development deliverables
the test cases accompanying the source code distribution
confirmed that some could be modified and/or adapted to • development aids - applications and test cases used to
test new but related objects within the then-current scope assist in the development of the product
of those test cases. With this testing approach, then, the • product documentation - documents that define, and
test cases shown in Table 6 were used to: otherwise specify, the interface, use model, and other
• ensure that no errors had been introduced into otherwise application related information of the developed
stable areas product
• verify that new elements did not impact similar, • product source code - source code employed to
previously implemented ones and performed as implement the reference implementation of the
expected developed product
• verify expected functionality of newly implemented
elements The specific items delivered to the system integrator
• confirm suspected issues in previously implemented included:
areas • Test case / test application
• Development test report (UTR)
Test Case Change State Verification Usage • OpenAccess 2.2 database development implementation
oaConstraint Unchanged No regression source code
oaConstraintDef Unchanged No regression
New constraint The user guide was not delivered, by agreement with
definitions Cadence, so that they could create the appropriate
oaConstraintParam Unchanged No regression documentation with the necessary styles and formats to be
oaConstraintParamDef Unchanged No regression consistent with current release standards. All other items,
New constraint however, were delivered to Cadence for final integration
parameter definitions
and testing the first of March 2005.
oaValue Modified No regression
New value types
oaClock New New clock and 15. Conclusions and Recommendations
waveform objects
Other than a couple of very minor test case issues, almost
oaLogicPath New New logic path objects
certainly the result of improper use of derived test cases,
oaDesignConstraint New New constraints
oaSimpleConstraint Modified Confirm other test case validation was successfully completed and the
failure development and implementation of timing constraints
and the related required data objects was considered to
Table 6 - Test Case Usage have been successful.
The scope of unit testing covered all elements directly Although all of the oaClock objects have been
related to those added and/or modified for timing implemented by overloading that class’s create member
constraints: function, a more appropriate implementation would be to
• data value classes derive appropriate clock classes from oaClock as a base
• clock and associated waveform classes class corresponding to the derived clock types. This
• logic path and path point classes recommendation was forwarded to the integration team,
• implemented timing constraint and definition classes but it may or may not be implemented as such when
publicly released.
while also implicitly testing these architectural,
structural, and organizational items and related classes: The 'package' structure should also be re-architected to
• value and data type compatibility enhancements enable the exclusion of tech package elements from the
• [now] non-sequential type & subtype correlation, design package. The current package hierarchy does not
setting, mapping, and checking allow this capability but instead only allows exclusion of
• value and data ‘package’ derivation and inheritance design elements from the tech package. This would,
• ‘design’ package inheritance from ‘tech’ package however, involve the creation of another level of
• ‘tech’ package inheritance from ‘base’ abstraction, which may or may not allow complete
• inherited class initialization and consistency compatibility with previous releases – this will involve a
rather concerted effort on the part of the system
Final testing and validation, including clocks and integrator.
waveforms, was completed by the end of February 2005.
- 7 of 8 -

8. 16. Play it Again, Sam [5] OpenAccess 2.1 C++ API Specification, September
2004, Silicon Integration Initiative (Si2)
As with all projects, 20-20 hindsight reveals a number of
practices, policies, and approaches that may have resulted
in a more efficient development cycle. Credits
[1] Figure 1 - OpenAccess Development Roadmap,
Probably chief among the areas of improvement would be OpenAccess 1H03 technical Roadmap, Version 1.0,
that the preparations for development planning should 29 May 2003, OpenAccess Coalition, © Silicon
also have included a more extensive investigation of the Integration Initiative (Si2)
source code. In particular, if the change in philosophy [2] Figure 2 - OSRP Development Process, Timing
from the oaRule based concept of previous releases to that Constraints Implementation Project Plan, Revision
of the oaConstraint based concept in the 2.2 release had 1.0, 13 Aug 2004, Philips Semiconductors
been apparent much earlier, then it would not have had [3] Figure 3 - Project Plan Duration Estimates Plan,
such a significant impact on task priorities and resource Project Management Plan, Revision 1.0, 13 Aug
allocation. 2004, Philips Semiconductors
[4] Figure 4 - oaRule Schema, OpenAccess 2.1 C++ API
A more concrete availability of resources, along with Specification, September 2004, OpenAccess
contingent alternate resource capacity, would have Coalition, © Silicon Integration Initiative (Si2)
reduced or eliminated development delays and the [5] Figure 5 - oaConstraint Schema, OpenAccess 2.2
resulting impact on the planned schedule. This is C++ API Specification, October 2004, OpenAccess
especially true in light of the impact of the rule/constraint Coalition, © Silicon Integration Initiative (Si2)
philosophy/concept issues. [6] Table 6 - Test Case Usage, Unit Test Report,
Revision 1.0, 1 Mar 2005, Philips Semiconductors
Although Cadence was involved and/or consulted during
this development, the majority of these discussions Biography
occurred late in the development cycle. The OpenAccess Timothy received his BS in Computer and Information
2.2 release development and validation responsibilities Science from The Ohio State University, College of
within Cadence precluded early involvement on their part Engineering, taking a position as Test Systems Analyst
because of the obvious resource availability issues. More with Industrial Nucleonics Corporation, followed shortly
intimate involvement and earlier planning & code reviews thereafter by 14 years with Honeywell Information
could have addressed a number of implementation issues Systems, now Groupe Bull, involved with their
that were necessary to resolve during development. proprietary HDL-based system for large mainframe
computer system design.
17. Thanks for the Memories
Development and implementation of the timing Timothy joined VLSI Technology, Inc., in 1993 as a staff
constraints would not have been possible without the software engineer, heavily involved in the development of
dedication of the workgroup that contributed to the the integrated ASIC design environment, during which
requirements specification for this project: time he received a patent for timing analysis and model
• Adil Bhanji, IBM optimization, with another related patent pending. He
• Lyren Brown, Freescale Semiconductor subsequently managed the ASIC tools development group
• Kevin Grant, Freescale Semiconductor and, after the acquisition by Philips Semiconductors, later
served as the architect the Chip Physical Architecture
• Mark Hahn, Cadence Design Systems
design area of the Philips SoC Design Environment for
• Gael Paul, Synplicity
leading edge technology designs.
• Joanne Schell, Freescale Semiconductor
• Padmaja Susarla, Mentor Graphic Corporation
Timothy was a contributing member of the Advanced
• Sean Tyler, Hewlett-Packard
Library Format (ALF) and led the migration effort within
• Jim Wilmore, Hewlett-Packard
Philips Semiconductors to a design environment based on
ALF. He is a member of the Open Library Architecture
References (OLA) / IEEE-1481 working group and led efforts toward
[1] OpenAccess 1H03 technical Roadmap, Version 1.0, the development and support of OLA libraries and EDA
29 May 2003, OpenAccess Coalition tools within Philips. He is an active participant in the
[2] Using Synopsys Design Constraints Format, Version OpenAccess initiative as a Coalition representative and
U-2003.03, March 2003, Synopsys, Inc. Change Team member, as well as a member of the
[3] Timing Constraints Data Requirements, 30 March Golden Gate Working Group and chair of the Timing
2004, OpenAccess Timing Working Group Working Group, and is currently leading the efforts
[4] OpenAccess 2.2 C++ API Specification, October within Philips in migrating towards OpenAccess
2004, Silicon Integration Initiative (Si2) based/compliant design environments.
- 8 of 8 -