ALF meeting, May 4, 1999 at Cadence, San Jose Attendees: Jay Abraham SI2 Mike Andrews Mentor Graphics Arun Balakrishnan NEC Shir-Shen Chang Synopsys John Decker TERA Systems Tim Ehrler VLSI Technology Ted Elkind Cadence (by phone) Darshan Rauniyar Mentor Graphics Wolfgang Roethig NEC Next meeting: ------------- June 1 - 3 at Synopsys, Mountain View AI status: ---------- old A.I. Test OLAworx for function parsing -- Mike Status: open old A.I. Supply memory models for VSIA demo to Mike -- Jacob for LSI Logic, Wolfgang for NEC Status: NEC done, LSI Logic open old A.I. send last-minute correction items to Yatin -- Tim Ehrler Status: open new A.I. Do the edits ourselves, update version number from 1.0.11 to 1.1 -- Wolfgang new A.I. Stage the 1.1 version on the web -- Mike ALF approval status and plans ----------------------------- ALF 1.1 has been formally approved by OVI board in April. The following roadmap and schedule has also been agreed upon: The ALF work group will become an IEEE study group, yet it will stay under the OVI umbrella until ALF 2.0 is approved. ALF 2.0 is targeted for Dec. 99. Copyright and ownership of ALF will be formally transfered to IEEE in Q1 2000 by forming an IEEE work group. The IEEE work group will propose the contents of ALF 2.0 as IEEE standard, based on the results of the study group. IEEE ballot is targeted for end of 2000. new A.I. recontact Victor Berman for PAR -- Mike Tool & library support status ----------------------------- Wolfgang: NEC now has ALF generation capability for memories, in addition to the already available ALF standard cell library. Shir-Shen: testing IBM's OLA library, NEC's library will be next. No direct evaluation of ALF features, only DCL, which in NEC's case is generated from ALF. Cadworx: discussed LEX & YACC parser issues for recursively defined objects. Also requested alternative syntax for multivalue annotation. A.I. resolve parser issues -- Atul, Arun Status: in progress Physical library update ----------------------- Jay reported the outcome of the LEF-API meeting, April 27 at SI2, involving OPEF group, layout experts from ASIC Council companies and EDA companies. The ASIC council recommendation was to extend ALF as source, OLA as API for physical library. Scope and schedule for ALF 2.0 ------------------------------ Here is the collected input from the participants: Wolfgang: Timing modeling for cores, eventually physical library Mike: Design for test related to cores, do not overload ALF 2.0 Tim Ehrler: Simulation for cores, usage of BEHAVIOR and STATETABLE Darshan: Decision on physical library is crucial Jay: Common library (performance & physical) is desireable, since QA of multiple libraries is a burden. Signal integrity and noise analysis are important. Arun: Common format developped by OPEF & ALF will be advantageous. New features: study modeling of special logic design, such as domino logic, pass-transistor logic. Macromodeling of logic building blocks for timing, power, signal integrity Shir-Shen: Collaboration between EDA and ASIC vendors in library development, verification, coherence, debug. Focus on application. Henceforth the ALF meetings will be topic-centric and involve related work groups, such as OLA (interface between library and design tools), DCWG (design constraints) and OPEF (physical library). DFT discussion -------------- Arun and Mike will be driving the modeling issues here. One topic is BIST, especially for memories. Arun: Library should specify the following items: - BIST algorithm: This is the sequence of address generation for write and read operation - data background: The pattern of memory data, for example * solid 0 or 1(all memory cells store 0 or 1) * row strobe (subsequent rows store alternative 1 and 0) * col strobe (subsequent columns store alternative 1 and 0) * checker board (pattern alternates between 010101 and 101010) - memory architecture example: column multiplex, memory banking, redundant rows and columns for self-correction - BIST port and usage Another topic is specification of test vectors for cores. Mike: Library should specify functionality with limited scope, for example write-through operation directly, so that no inference from the general function description is required. For instance, a core may be modeled hierarchically with subblocks. A set of conditions on each subblock is required to enable a write-through through a certain path. Wolfgang: extensible ALF features are - annotations for test (for CELL, PIN, VECTOR), e.g. SIGNALTYPE, ATTRIBUTE - BEHAVIOR in context of timing constraint VIOLATION - VECTOR to specify the waveform for write-through mode ALF semantics for timing ------------------------ Wolfgang: OLAWorx 1.0 translates DELAY models within a restricted set of vector expressions which have the following form: VECTOR (single_event_expression -> single_event_expression [ & boolean_expression ]){ DELAY { FROM { PIN = pin_id; } TO { PIN = pin_id; } } } The FROM and TO pin_id, respectively must appear in the first and second single_event_expression. Transition polarities (rise or fall) are infered from the corresponding single_event_expression. These restrictions are o.k. for currently existing libraries, and they correspond exactly to the modeling capabilities of timing analysis tools today. However, ALF can describe more general vectors for delay characterization, involving multiple switching signals. OLAWorx 2.0 will translate DELAY models for more general vectors, as long as the following semantics are respected: For a given DELAY, the VECTOR must contain a single_event_expression involving the FROM pin and another single_event_expression involving the TO pin, from which the transition polarities can be unambiguously infered. Similar semantics apply for SLEWRATE, SETUP, HOLD, RECOVERY, REMOVAL, PULSEWIDTH, PERIOD, NOCHANGE, SKEW These semantics still imply restrictions for the complexity of vector_expressions applicable for DELAY. These restrictions should be removed for future core timing modeling. Example: VECTOR ( 01 A -> 10 A -> 01 B -> 01 A -> 01 C ) { DELAY { FROM { PIN = A; } TO { PIN = C; } } This vector contains 3 single_event_expressions involving A. Suggestion: Introduce the specification of EDGE and COUNT. old A.I. Draft a document for timing semantics in next future ALF version for formal reasons -- Ted Elkind Status: Ted send a memo by fax which was discussed new A.I. send a softcopy of the memo for the record -- Ted The discussion of Ted's memo came to the following conclusions: - We need to strengthen modeling for bidirectional pins Right now we have only an application example, no normative definition Suggestion: define a standard bus resolution function, specify the corresponding set of function graphs for bidir. - We need to incorporate the OLAWorx VECTOR interpretation capability into ALF spec, enforcing the compatibility between vector_expression and FROM/TO PIN. - We need to legalize the incremental usage of VECTOR The rule against redefinition of objects shall apply for objects within vectors, not for vectors themselves. Example 1: VECTOR contains DELAY, another VECTOR with the same vector_expression contains POWER. This shall be legal. Example 2: VECTOR contains POWER, another VECTOR with the same vector_expression contains POWER again. This shall be illegal. new A.I. incorporate detailed timing semantics in ALF spec. -- Wolfgang Timing modeling for cores ------------------------- Wolfgang re-iterated the issue of cycle-dependent timing arcs. ALF modeling support is provided in BEHAVIOR, VECTOR, EXISTENCE_CONDITION. Suggestion: define new SIGNALTYPE for cycle counter. PLL modeling issue: Timing analysis does not know that "reference" and "feedback" input of PLL are aligned in phase and frequency and cannot propagate backwards from feedback input to the clock output of the PLL. Designer must specify the clock output of PLL as primary clock for STA. In order to do this, a first timing analysis is required on the path from PLL clock output to PLL feedback input. Note: this path is part of the design, it is not part of the library. Example: reference clock arrival time is 10, delay from clock output to feedback input is 6. Therefore the clock output arrival time must be specified as 10 - 6 = 4. Related issue: clock propagation through frequency dividers is not supported. A.I. Update the core timing modeling proposal with PLL modeling -- Wolfgang Status: done and presented in OLA meeting the next day ALF and related standards ------------------------- Wolfgang presented a document "Introduction to ALF 1.1" which was reviewed. It will be staged on the web, including corrections suggested by the audience. new A.I. Update the doc. and stage it on the web -- Wolfgang, Mike