Your SlideShare is downloading. ×
Into the Depths of OpenAccess - paper
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Into the Depths of OpenAccess - paper

206
views

Published on

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

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

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
206
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 -