- 1 of 8 -

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 OpenAccess Coalition member company requests, was the development of sufficient capabilities to incorporate timing constraint information within the database. This could not be immediately undertaken by Cadence, however, due to a lack of available resources with which to develop and implement these capabilities.

Because of its importance to the migration efforts within Philips Semiconductors and other coalition members, we resourced this development to accelerate its availability. This paper, then, describes this development and implementation effort, which was the first of its kind outside of the contributing Cadence development and integration teams. The development process, experiences, and encountered issues are addressed within, including those regarding database/package hierarchy & data inheritance and extended design & value data structure implementation. Particular attention is paid to related issues concerning compatibility with past and future releases.

1. Introduction In order to formally guide the evolution of OpenAccess beyond the original requirements, and in accordance with prioritized set of enhancements proposed by the OpenAccess Coalition, the OpenAccess Change Team maintains a “live” technology roadmap [1] that defines the direction of development over the next few releases. The general roadmap is shown in Figure 1.

Figure 1 - OpenAccess Development Roadmap

Development of API support for timing and other design constraints, a significant item within the roadmap, was initiated with the formation of the Timing Constraint Workgroup. The responsibility of this group was to define the timing constraint data requirements compatible with intent of common industry use of Synopsys SDC [2]. The resulting specification [3] was delivered to the change team for consideration by Cadence as the core code development and integration provider. Since Cadence resources were fully committed to the development of the upcoming OpenAccess 2.2 release, the change team requested implementation resources from its members. Philips Semiconductors, recognizing the importance of this capability, both within Philips as a critical migration requirement as well as among other coalition members, contributed the necessary resources and successfully implemented the timing constraints and transferred the deliverables to Cadence for integration.

2. Planning for Success Planning for this development project followed the Philips Overall System Realization Process (OSRP), which defines the formal process for all phases of project execution, including required documentation, gates, and milestones. Because many of the document requirements were satisfied by the change team and workgroup deliverables, the process was tailored as a subproject, as shown in Figure 2, subordinate to the overall OpenAccess release development.

- 2 of 8 -

SchedPMP

CRS

FRS

PIF

PS

S/W

PIA PC

UTR

UsM

OpenAccessChangeTeam

Implementers

TimingConstraintsWork group

CSSRACA

Integration

Figure 2 - OSRP Development Process

The approach taken to planning this development was based primarily on available resources. A pair of resources was originally dedicated to this effort – the primary at 50% availability and the secondary at 75%. Planning estimates resulted in an initial duration of ~90 days, which ended up being significantly affected by factors and issues encountered later.

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 development, this led to installation on a shared directory on an HP-UX system with data management under CVS. The development was then done in a Red Hat Linux environment, with GNU gcc C++ compiler and gdb debugger, which proved sufficient for the task.

4. Gaining Insight The source code base on which development began was build 5 beta release b005, which was later migrated to public release 2.2.0 [4]. The development team was only very generally familiar with the public 2.1 release [5], and changes from that release to this beta release revealed many critical programming and “philosophical” differences that impacted this effort.

To satisfy future extensibility and flexibility requirements, however, the concept of rules was 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. This change, as well as the accompanying hierarchy associated with their implementation and use model, forced some changes of the original estimates and task allocation.

While the oaRule class was relatively simplistic, as shown in Figure 4,

Figure 4 - oaRule Schema

the oaConstraint class and use model is considerably more complex, as shown in Figure 5. This required a different and more inter-dependent development approach than originally anticipated.

- 3 of 8 -

Figure 5 - oaConstraint Schema

5. Organization, Structure, & Relationships OpenAccess is organized as three related ‘packages’: • base - generally available defined classes also used by

tech and design packages • tech - technical package derived from & based on

base package, intended primarily for use related to technology data but also usable by design package

• design - design package derived from & based on base and tech packages, intended primarily for use related to design data

This ‘package’ relationship extends into all areas relevant to constraint definition and usage, ranging from values to definitions to parameters to constraints. This concept not only defines the data hierarchy, but also significantly impacts the base & derived class inheritance & data management elements associated with these class objects, some of which are shown in Table 1.

Package values data objects constraints base oaValue oaObject oaConstraint tech oaTechValue oaTechObject oaTechConstraint design oaDesignValue oaDesignObject oaDesignConstraint

Table 1 - Object Class Package Inheritance

Prior to the development of timing constraints, purely design related values did not exist but were created for design level constraint use. Previously, an oaValue could exist for base, tech, or design usage or an oaTechValue, derived from oaValue, could be used for base or tech usage. Now, an oaDesignValue, derived from oaTechValue, is specifically design related. An example of this would be the value of an analysis timing window (oaTimingWindowValue). No design-specific objects of this type had previously existed, so this class, derived from oaDesignValue also required definition, as did the associated data types.

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 ValueoavValueTypeBool 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 oavValueTypeDualInt 0x000aU oacDualIntValueType 228 oavValueTypeDualInt1DTbl 0x000bU oacDualInt1DTblValueType 229 oavValueTypeBoxArray 0x000cU oacBoxArrayValueType 230 oavValueTypeValueArray 0x000dU oacValueArrayValueType 231 oavValueTypeViaDefArray 0x000eU oacViaDefArrayValueType 232 oavValueTypeLayer 0x000fU oacLayerValueType 233 oavValueTypeAntennaRatio 0x0010U oacAntennaRatioValueType 234 oavValueTypeAntennaRatioArray 0x0011U oacAntennaRatioArrayValueType 235 oavValueTypeViaDef2DTbl 0x0012U oacViaDef2DTblValueType 236

Table 2 - Value Type & Subtype Relationship

Although the last three values are tech package values, they are sequential to the preceding base package values because they were implemented at the same time. Since many more enumerated public types surround this block of enumerated values, subsequent value implementations could not be made sequential with these, as shown in Table 3.

Private SubType Public Type Definition Value Enumeration ValueoavValueTypeString 0x0013U oacStringValueType 269 oavValueTypeDualString 0x0014U oacDualStringValueType 270 oavValueTypeQuadString 0x0015U oacQuadStringValueType 271 oavValueTypeControlType 0x0016U oacControlTypeValueType 272 oavValueTypeLoadType 0x0017U oacLoadTypeValueType 273 oavValueTypeStateTransition 0x0018U oacStateTransitionValueType 274 oavValueTypeStateTransitionArray 0x0019U oacStateTransitionArrayValueType 275 oavValueTypeTimingType 0x001aU oacTimingTypeValueType 276 oavValueTypeTimingTypeArray 0x001bU oacTimingTypeArrayValueType 277 oavValueTypeClockRelation 0x001cU oacClockRelationValueType 278 oavValueTypePropagateType 0x001dU oacPropagateTypeValueType 279 oavValueTypeTimingWindow 0x001eU oacTimingWindowValueType 280

Table 3 - Constraint Related Value Types & Subtypes

The first three data types are base package related, the last three are design package related, and the remaining are tech package related. Not only are these items not sequential with those previously defined, but neither are newer values types sequential with previously implemented ones within the same package. This is forced by compatibility requirements that [enumerated] data types must remain constant among releases, but complicates internal data management processes,

- 4 of 8 -

resulting in non-trivial code modifications in all affected related areas.

7. Virtual Persistence Even though OpenAccess is presented to an application as an object-oriented C++ API, the actual manipulated object data is not the instantiated ‘API object’ itself. Instead, an underlying ‘data table’ structure is manipulated through an associated ‘table object’. A much-simplified representation of these relationships is shown in Figure 6.

Figure 6 - General Object & Data Relationship

Although transparent to the application, this hidden complexity allows database compatibility by isolating the object from the data manipulation, while at the same time the manipulated data is isolated from the stored data, thus allowing for another level of compatibility.

Because of these object and data manipulation relationships, and especially in the context of derived related objects, many non-trivial data structure and derivative object modifications were required to ensure compatibility while at the same time not degrading performance or data integrity. A very simplistic representation of a small subset of constructs and their inter-relationships is shown in Figure 7.

oaDesignValueTbl

oaValueTbl

oaTechValue

oaDesignValue

oaValue

oaClockRelationValue

oaTechValueTbl

oaClockRelationValueTbl

create instance

in-memory database data

databasestorage

Figure 7 - Example Object & Data Relationships

It should be noted here that the information & values of object ‘type’ & ‘subtype’ constants serve as index & location information for data structures & data storage mechanisms. This illustrates the requirement for the consistent values of such defined & enumerated constants across database releases to ensure and enforce compatibility and data integrity.

8. The Structure Evolves Having investigated and studied the organization, data model, and relationships within OpenAccess in detail,

concerted development efforts were started to implement the required timing constraint information [3]. Based on this architectural knowledge, the implementation proceeded in the following order: 1. constraint related value objects 2. constraint parameter definitions 3. constraint definitions 4. constraint objects 5. design logic related objects 6. clock related objects

Prior to much of this development, however, were the modifications, enhancements, and additions to architectural and structural areas of OpenAccess in order 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 significantly affected involved the extensions of: • data type definitions and enumerations to cover

additional data and object types • value objects into design package for isolation from

tech package • constraint and constraint group member objects into

design package

9. Implementation Commences In addition to those private subtypes and public types shown in Table 3, corresponding definitions and enumerations were required for data types and objects more directly related to constraints as shown in Table 4.

Private SubType Public Type Definition Value Enumeration ValueoavConstraintDefTypeGeneral 0x0003U oacGeneralConstraintDefType 259 oavConstraintDefTypeEdge 0x0004U oacEdgeConstraintDefType 260 oavConstraintDefTypeClockRelated 0x0005U oacClockRelatedConstraintDefType 261 oavConstraintDefTypePath 0x0006U oacPathConstraintDefType 262 oavConstraintDefTypeCompound 0x0007U oacCompoundConstraintDefType 263 oavConstraintTypeGeneral 0x0003U oacGeneralConstraintType 264 oavConstraintTypeEdge 0x0004U oacEdgeConstraintType 265 oavConstraintTypeClockRelated 0x0005U oacClockRelatedConstraintType 266 oavConstraintTypePath 0x0006U oacPathConstraintType 267 oavConstraintTypeCompound 0x0007U oacCompoundConstraintType 268

Table 4 - Constraint Related Data Types & Subtypes

Note that by this time the timing constraints had been logically classified into five categories:

• general - simple value constraint applied to a logic point

• edge - simple value constraint applied to a logic point with associated state transition

• clock related - simple value constraint applied to a logic point with associated state transition in relation to clock with associated state transition

• path - constraint applied to a logic path with associated state transitions

table objectAPI object

data table

databasestorage

- 5 of 8 -

• compound - constraint applied to a logic point and requiring associated constraints for full constraint definition (later re-defined)

Also defined were the required design logic and analysis related data object information shown in Table 5.

Private Data Type Public Type Definition Value Enumeration Value

oacClockDataType 74 oacClockType 256 oacLogicPointDataType 73 oacLogicPointType 257 oacWaveformDataType 75 oacWaveformType 258

Table 5 - Design Logic & Analysis Data Objects

It must be noted here that the development and 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 defined in a very trivial manner so that development in all other areas could continue to completion, allowing a more efficient use of the available resources.

10. Embracing Change One of the more severe impacts on the development effort was the anticipated release of the production source code for the 2.2.0 release of OpenAccess. While not an insurmountable effort, the merging of source code developed on the beta b005 base with that of the production release was not insignificant. In particular, the juxtaposition of some constant definitions and enumerations from the base development source code required a concerted effort to re-align current development code to the production release. Furthermore, the lack of insight into what could have been a significant change in architecture, structure, or data models within the production release necessitated a concerted assessment of the released source code base to ensure that no functional discrepancies resulted from the merging of the development code.

Later in the project, resource unavailability became a serious detriment to the progress of this development effort. Unanticipated periods of jury duty and extended business travel, as well as critical internal issues requiring the temporary re-allocation of resources to resolve, extended the scheduled effort by one-third past the original plan.

As development continued, discussions and code reviews with system integrator Cadence yielded some observations and suggestions that affected the then-current implementation. In an effort to more concisely allocate data objects to the most appropriate package, a corresponding re-allocation was performed, resulting in the re-structuring of a large portion of implemented code. Furthermore, derivation and inheritance models were also impacted, necessitating a more extensive re-organization

in some areas to ensure compatibility and data integrity. A particular observation was that of the “compound” constraint category that contained a single constraint concerning logic driving cells other than clocks. As recommended, the implementation was changed to 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 constraint specifying a clock driver was moved to this same category, providing a consistent set of constraints within this appropriately renamed “driver” category.

Finally, implementation progress was significantly impacted by the loss of one-half of the development team, resulting in another extension to the schedule and ultimately the planned delivery date.

11. The Path[s] Well-chosen The concept of a logic design path, crucial to many of the timing constraint objects, did not yet exist within OpenAccess. In order to prevent an explosion of persistent constraint data, and enabling a more succinct definition of multi-point paths, an encompassing description of a logic design path is defined as “an ordered array of logic points”. Logic points in turn are defined as “a set of one or more connected occurrence elements associated with a set of one or more signal state transitions”. Given the interconnected logic elements of Figure 8,

Figure 8 - Example Logic Path

an encompassing logic path can be defined as: • starting at either the occurrence term otA or the

occurrence instance term oitb, and having either a rising or falling signal state transition

• passing through occurrence net onC with a falling signal state transition

• ending at the occurrence instance term oitD with a rising signal state transition

Implementation of this construct, however, required the creation of a number of new design objects: • oaPathPointArray - an array (oaArray) of design

objects (oaDesignObject*) • oaStateTransitionArray – an array (oaArray) of

enumerated state transition constants (oaStateTransitionEnum)

• oaLogicPoint – an object consisting of a set of one or more path points (oaPathPointArray) and a set of one or more state transitions (oaStateTransitionArray)

Q

QSET

CLR

D

otA,( )

,( )

onC( )

oitD( )

oitB

- 6 of 8 -

• oaLogicPointArray – an ordered array (oaArray) of logic points (oaLogicPoint*)

Providing an implementation consistent with other database objects, however, requires the capability for equivalence comparisons, revealing another unforeseen issue. Homogenous tables of data base objects require only the location index information, but heterogeneous database object tables also require data object type information. In previous OpenAccess releases this data was implemented as structure type oaIndexTypePairData. However, since class member equivalence functions are required for comparison purposes, this structure was converted to a class of the same name, and the corresponding equivalence member functions implemented therein. Although extensively used throughout the database implementation, this conversion had relatively little impact since a C++ structure is actually the [most] trivial instance of a class - converting from a structure to a class had no impact on the data structure or its use throughout OpenAccess.

12. Beating the Clock Crucial for timing analysis, clocks must exist to enable their application within the scope of timing constraints, hence the creation of the oaClock class object. As with logic design paths, the concept of a clock had not previously been defined within OpenAccess, either created with a waveform or derived from another signal. The relationships between waveforms and created & derived clocks are shown in Figure 9.

Figure 9 - Waveform and Clock Relationships

Created clocks require the definition of a series of rising and falling signal transitions over a specified period to be applied to design logic signal points for analysis purposes. This “set of edges”, usually transitioning between logic levels zero (‘0’) and one (‘1’) and having state transition times of zero (‘0.0’), is defined with the oaWaveform class object. However, to allow for flexibility and future extensibility of waveforms, the oaWaveform class was created that provides for the primitive clock signal requirements noted above, as well as providing for transition states other than logic level ‘0’ and ‘1’ and non-zero transition times. By allowing such capabilities, waveforms can then be defined as having one or more of the following characteristics: • logical - transition between logic states ‘0’ and ‘1’ • ideal - edge transition times of ‘0.0’ • circular - first edge transition start state same as last

edge transition end state

Waveforms having all of the above characteristics would be consistent with the current definition of an ideal clock. More complex waveforms, however, may be defined by combining state transitions to non-logical levels and non-zero transition times. Representations of simple and complex waveforms are shown in Figure 10.

Figure 10 - Simple & Complex Waveforms

A derived clock is basically an instance-specific modification of a previously defined clock signal having propagated through one or more stages of design logic and having a defined set of transition characteristics. Although important for analysis and constraint purposes, the four types of derived clocks are relatively trivial implementations compared with a created clock. The types of derived clocks created for constraint purposes include: • divided – derivative of existing signal, having its

frequency divided by an integer scaling factor • multiplied – derivative of existing signal, having its

frequency multiplied by an integer scaling factor • edge specific – derivative of an existing signal,

consisting of an ordered subset of edges • shifted edge specific – derivative of an existing signal,

consisting of an ordered subset of shifted edges

13. Are we there, yet? Because of the inter-related nature of the modifications, enhancements, and additions to the OpenAccess source code required for even a prototypical implementation of the related constraint objects, very little isolated object unit testing was performed as implementation progressed. Although interim and full builds were performed on a regular basis during development, actual executable testing was necessarily postponed until at least a “critical mass” of development had been implemented – up to but excluding oaClock and oaWaveform development and implementation.

An advantage gained by this approach was the early opportunity to “discover” development environment limits and restrictions not previously encountered. Indeed, early compilations revealed a makefile environment string limit that was exceeded when the additional source files were included. Fortunately, this was easily resolved by the judicious removal of “white space” within, but future releases will require modifications to this approach as more files are added and this string limit is once again exceeded with no remaining means of resolution.

As implementation progressed to the point that execution unit testing was applicable, decisions concerning the most

oaWaveform

designlogic

oaClock(created)

oaClock(derived)

1

0

HiZ ?

ideal & logical complex

- 7 of 8 -

appropriate approach necessary for sufficient testing of the code were made. Rather than creating test benches from scratch to properly test the various additions and enhancements to the OpenAccess code base, studies of the test cases accompanying the source code distribution confirmed that some could be modified and/or adapted to test new but related objects within the then-current scope of those test cases. With this testing approach, then, the test cases shown in Table 6 were used to: • ensure that no errors had been introduced into otherwise

stable areas • verify that new elements did not impact similar,

previously implemented ones and performed as expected

• verify expected functionality of newly implemented elements

• confirm suspected issues in previously implemented areas

Test Case Change State Verification Usage oaConstraint Unchanged No regression oaConstraintDef Unchanged No regression

New constraint definitions

oaConstraintParam Unchanged No regression oaConstraintParamDef Unchanged No regression

New constraint parameter definitions

oaValue Modified No regression New value types

oaClock New New clock and waveform objects

oaLogicPath New New logic path objects oaDesignConstraint New New constraints oaSimpleConstraint Modified Confirm other test case

failure

Table 6 - Test Case Usage

The scope of unit testing covered all elements directly related to those added and/or modified for timing constraints: • data value classes • clock and associated waveform classes • logic path and path point classes • implemented timing constraint and definition classes

while also implicitly testing these architectural, structural, and organizational items and related classes: • value and data type compatibility enhancements

• [now] non-sequential type & subtype correlation, setting, mapping, and checking

• value and data ‘package’ derivation and inheritance • ‘design’ package inheritance from ‘tech’ package • ‘tech’ package inheritance from ‘base’ • inherited class initialization and consistency

Final testing and validation, including clocks and waveforms, was completed by the end of February 2005.

14. Delivering the Goods Deliverables for this project fell into four categories: • project documentation - documents associated with the

resulting development deliverables • development aids - applications and test cases used to

assist in the development of the product • product documentation - documents that define, and

otherwise specify, the interface, use model, and other application related information of the developed product

• product source code - source code employed to implement the reference implementation of the developed product

The specific items delivered to the system integrator included: • Test case / test application • Development test report (UTR) • OpenAccess 2.2 database development implementation

source code

The user guide was not delivered, by agreement with Cadence, so that they could create the appropriate documentation with the necessary styles and formats to be consistent with current release standards. All other items, however, were delivered to Cadence for final integration and testing the first of March 2005.

15. Conclusions and Recommendations Other than a couple of very minor test case issues, almost certainly the result of improper use of derived test cases, validation was successfully completed and the development and implementation of timing constraints and the related required data objects was considered to have been successful.

Although all of the oaClock objects have been implemented by overloading that class’s create member function, a more appropriate implementation would be to derive appropriate clock classes from oaClock as a base class corresponding to the derived clock types. This recommendation was forwarded to the integration team, but it may or may not be implemented as such when publicly released.

The 'package' structure should also be re-architected to enable the exclusion of tech package elements from the design package. The current package hierarchy does not allow this capability but instead only allows exclusion of design elements from the tech package. This would, however, involve the creation of another level of abstraction, which may or may not allow complete compatibility with previous releases – this will involve a rather concerted effort on the part of the system integrator.

- 8 of 8 -

16. Play it Again, Sam 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.

Probably chief among the areas of improvement would be that the preparations for development planning should also have included a more extensive investigation of the source code. In particular, if the change in philosophy from the oaRule based concept of previous releases to that of the oaConstraint based concept in the 2.2 release had been apparent much earlier, then it would not have had such a significant impact on task priorities and resource allocation.

A more concrete availability of resources, along with contingent alternate resource capacity, would have reduced or eliminated development delays and the resulting impact on the planned schedule. This is especially true in light of the impact of the rule/constraint philosophy/concept issues.

Although Cadence was involved and/or consulted during this development, the majority of these discussions occurred late in the development cycle. The OpenAccess 2.2 release development and validation responsibilities within Cadence precluded early involvement on their part because of the obvious resource availability issues. More intimate involvement and earlier planning & code reviews could have addressed a number of implementation issues that were necessary to resolve during development.

17. Thanks for the Memories Development and implementation of the timing constraints would not have been possible without the dedication of the workgroup that contributed to the requirements specification for this project: • Adil Bhanji, IBM • Lyren Brown, Freescale Semiconductor • Kevin Grant, Freescale Semiconductor • Mark Hahn, Cadence Design Systems • Gael Paul, Synplicity • Joanne Schell, Freescale Semiconductor • Padmaja Susarla, Mentor Graphic Corporation • Sean Tyler, Hewlett-Packard • Jim Wilmore, Hewlett-Packard

References [1] OpenAccess 1H03 technical Roadmap, Version 1.0,

29 May 2003, OpenAccess Coalition [2] Using Synopsys Design Constraints Format, Version

U-2003.03, March 2003, Synopsys, Inc. [3] Timing Constraints Data Requirements, 30 March

2004, OpenAccess Timing Working Group [4] OpenAccess 2.2 C++ API Specification, October

2004, Silicon Integration Initiative (Si2)

[5] OpenAccess 2.1 C++ API Specification, September 2004, Silicon Integration Initiative (Si2)

Credits [1] Figure 1 - OpenAccess Development Roadmap,

OpenAccess 1H03 technical Roadmap, Version 1.0, 29 May 2003, OpenAccess Coalition, © Silicon Integration Initiative (Si2)

[2] Figure 2 - OSRP Development Process, Timing Constraints Implementation Project Plan, Revision 1.0, 13 Aug 2004, Philips Semiconductors

[3] Figure 3 - Project Plan Duration Estimates Plan, Project Management Plan, Revision 1.0, 13 Aug 2004, Philips Semiconductors

[4] Figure 4 - oaRule Schema, OpenAccess 2.1 C++ API Specification, September 2004, OpenAccess Coalition, © Silicon Integration Initiative (Si2)

[5] Figure 5 - oaConstraint Schema, OpenAccess 2.2 C++ API Specification, October 2004, OpenAccess Coalition, © Silicon Integration Initiative (Si2)

[6] Table 6 - Test Case Usage, Unit Test Report, Revision 1.0, 1 Mar 2005, Philips Semiconductors

Biography Timothy received his BS in Computer and Information Science from The Ohio State University, College of Engineering, taking a position as Test Systems Analyst with Industrial Nucleonics Corporation, followed shortly thereafter by 14 years with Honeywell Information Systems, now Groupe Bull, involved with their proprietary HDL-based system for large mainframe computer system design.

Timothy joined VLSI Technology, Inc., in 1993 as a staff software engineer, heavily involved in the development of the integrated ASIC design environment, during which time he received a patent for timing analysis and model optimization, with another related patent pending. He subsequently managed the ASIC tools development group and, after the acquisition by Philips Semiconductors, later served as the architect the Chip Physical Architecture design area of the Philips SoC Design Environment for leading edge technology designs.

Timothy was a contributing member of the Advanced Library Format (ALF) and led the migration effort within Philips Semiconductors to a design environment based on ALF. He is a member of the Open Library Architecture (OLA) / IEEE-1481 working group and led efforts toward the development and support of OLA libraries and EDA tools within Philips. He is an active participant in the OpenAccess initiative as a Coalition representative and Change Team member, as well as a member of the Golden Gate Working Group and chair of the Timing Working Group, and is currently leading the efforts within Philips in migrating towards OpenAccess based/compliant design environments.