ALF-OLA meeting minutes 6/1/99 - 6/3/99 Hosted by Synopsys, Mountain View CA ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Attendees ^^^^^^^^^ Ted Elkind Cadence Tim Baldwin Cadence Cary Wei Fujitsu Peng-Fei Zhang Fujitsu Jay Abraham Si2 Priti Vijayvargiya Synopsys Shir-Shen Chang Synopsys Tim Ayres Synopsys Shivkumar Kitty Synopsys Henry Zhu Synopsys Darshan Rauniyar Mentor Mike Andrews Mentor Archie Lachner Mentor CK Cheng Mentor Kent Moffat Mentor Andrew Zaferakis IBM John Beatty IBM Wolfgang Roethig NEC Jacob Xiao LSI Next meeting date and location ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ July 27 - 29, hosted by Mentor Graphics, Portland OR ALF Action Items ^^^^^^^^^^^^^^^^ old A.I. Test OLAworx for function parsing -- Mike Status: in progress old A.I. Supply NEC memory models for VSIA demo to Mike -- Wolfgang Status: done old A.I. Supply LSI memory models for VSIA demo to Mike -- Jacob Status: dropped old A.I. Do the ALF spec. edits, update version number from 1.0.11 to 1.1 -- Wolfgang Status: in progress old A.I. recontact Victor Berman for PAR -- Mike Status: Superseeded by new A.I. Get OVI board approval for ALF forming an IEEE study group -- Vassilios Gerousis old A.I. resolve parser issues -- Atul, Arun Status: done new A.I. get ALF work group approval for new syntax of multivalue annotation -- Wolfgang old A.I. send a softcopy of the simulation modeling memo for the record -- Ted Status: done old A.I. timing semantics for next version of ALF spec. -- Wolfgang Status: in progress old A.I. update core timing modeling proposal with PLL modeling -- Wolfgang Status: done new A.I. Old OLA Action Items Status ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Update OLA spec (1.0.2) - Jay Abraham - Done 2. Investigate SI tools at IBM - John Beatty - TBD 3. Distribute pinlist proposal to reflector - John Beatty - Done 4. Develop a methodology by which EDA apps are informed when RC estimation computation can change from call to call - John Beatty - TBD 5. Summarize requirements for goingo to IEEE for ASIC Council - Tim E. - Done 6. Come up with a description on hos to use the API calls for arc values and existence conditions - Archie Lachner - Done 7. Update proposal for getting string representation for state strings - Archie Lachner - Done New OLA Action Items Generated ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Find out how Einstimer handles NOCHANGE in static timing - John Beatty | 2. DELETED 3. Modify the API calls for PLLs - John Beatty | 4. DELETED 5. Log NonScanCell proposal in Issue Tracking System - John Beatty 6. Log an issue for new pin list API - John Beatty 7. Log update issue for pin list that this API must also return bus width information - John Beatty 8. Log an issue for ROM initialization - Mike Andrews 9. Need to submit examples of function description for memories - ASIC vendors 10. Log an issue for the need in OLA new function operators that correspond to new ALF operators '*' and '~>' - Jay Abraham 11. Log an issue for proposed APIs and methodology for interconnect reduction - John Beatty 12. Come up with function operator subset for synthesis, formal verification, DFT and state dependent static timing - EDA vendors 12. Need a new API for the calculation of noise - Wolfgang Roethig 13. A template showing the implementation of interconnect algorithms and API protocols in OLA is needed - Jay Abraham 14. Can IBM donate a skeleton of the interface that they have implemented internally for 1481 style interconnect delay calculation - Andrew Z. 15. How do you get driver pin resistance of cell that is in a different technology, but is a part of the network that is in the technology being worked on - John Beatty 16. Write up an issue log for APIs for arrival times - Wolfgang Roethig 17. Add power_pin type to the newly proposed API dpcmGetCellPinList - John B. 18. Write up an issue log for appGetCurrentFrequency - Wolfgang Roethig 19. Write up an issue log for OLA API dpcmGetCellCurrent to match ALF spec for arithmetic models for 'transient', 'static', 'average', 'rms', and 'peak' - Wolfgang Roethig 20. Write an issue log for clock tree modeling and synthesis - Wolfgang Roethig 21. Get participation from physical design experts from ASIC and EDA vendors - Jay Abraham 22. Need more information on IEEE standardization process (e.g. what is IEEE-SA) - Kent Moffat 23. ASIC vendors are to provide a list of requirements for OLA 1.0.x that is to be rolled into IEEE 1481.1 (deadline July 31) - ASIC vendors | 24. Report on the requirements of Synopsys DFT tools where they differ | from the document "DFT Requirements for OLA (5/31/1999)" distributed by | Mike Andrews - Tim Ayres | 25. add wording to the overview of the arc existence/value graphs | indicating that only an OLA-compliant application neeed use the graphs. | After verifying that it will suffice, to indicate that the graphs | be limited to using operators that map to IEEE 1481 GCL. Log the | existence/value graphs proposal in the issue-tracking system. - Archie | 26. Log core-timing proposal in the issue-tracking system | 27. Add functions for multiplication and division to the PLL proposal | after it is logged (by John Beatty) in the issue-tracking system. - Archie | 28. Add a function for obtaining "edge_number" to the vector-timing | proposal after it is logged (by Jay or Wolfgang) in the issue-tracking | system. - Archie ALF Administrative status ^^^^^^^^^^^^^^^^^^^^^^^^^ Wolfgang called for participation at ALF Birds-of-a-feather session at DAC, organized by OVI. The purpose is to present the status of the ALF work group as well as to educate the audience about the purpose of ALF and its relation to other emerging standards, especially OLA. Mike agreed to chair the session. Jay will represent the OLA viewpoint. Wolfgang will prepare a presentation. According to Dennis Brophy, formation of the ALF IEEE study group needs OVI board approval. Vassilios will work with the OVI board to get clearance for this step. Note that the ALF study group will work very closely with the OLA study group. Technically, ALF will be a new IEEE standard whereas OLA will be the next version of the IEEE 1481 standard. OLA Administrative status ^^^^^^^^^^^^^^^^^^^^^^^^^ The ASIC Council has agreed that OLA 1.0.x must be submitted as an extension to IEEE 1481. Kent Moffat of Mentor Graphics will chair the IEEE study and working groups. Jay presented a proposal for the timeline to get OLA into IEEE. The following was thought the best guess as to tool support for IEEE 1481.1: Synthesis, Timing, Power, DFT, Crosstalk analysis related to timing, Postlayout delay calculation (this may already be in the spec, but need to test that it is complete) The following was thought the best guess as to tool support IEEE 1481.2 Layout, Design Planning, Simulation, Signal Integrity related to physical data. The Issue Tracking System (ITS) shall be used to track OLA spec issues. These can be logged at ... http://www.si2.org/ola/its.html NEC indicated that in development of their internal delay calculator compatible with IEEE 1481 they discovered some deficiencies in the 1481 spec for inter- connect delay computation. Core Timing ^^^^^^^^^^^ Comment from Wolfgang R., should NOCHANGE be in the 'timing' domain or 'vectorTiming' domain. Shir-Shen and Wolfgang felt that in order to do a NOCHANGE test, it must be done in a dynamic sense. Cannot do this in stating timing w/o constraining for example a WriteEnable pin to be synchronous with respect to clock. Archie indicated that the NOCHANGE test can be done in static timing. Archie felt that NOCHANGE test can be determined using arrival times. The conclusion was that NOCHANGE shall be represented in 'timing' AND 'vectorTiming' domains. | Addendum from Archie Lachner : | | Unfortunately, this seems to have captured only part of this issue, and | does for me not represent a completely accurate view of our position on | this matter. Because of the fundamental nature of the underlying | mechanisms, I intend to send a clarification directly to the OLA reflector. ALF Semantics for Timing ^^^^^^^^^^^^^^^^^^^^^^^^ vector (01a -> 10a -> 01b -> 01a -> 01c) delay { from { pin=a;} to { pin=c;} The above is ambiguous since one does not know the edge number at which 'a' transitioned. The proposal was to add an 'edge_number' keyword that will specify which edge number is transitioning. Shir-Shen brought up the point that what will an application, especially a timing analysis tool use this data. Specifically: 1. Delay specified from non subsequent events, how is his resolved 2. Multiple delays from same vector, what is the relationship between them In OLA there is only one pathData for a given vector. How does one represent 'edge_number' in OLA. Archie Lachner took an action item to look into this. Arc Values and Existence Condition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Archie presented his document (already circulated on the reflector) on this topic. Shir-Shen was concerned that with respect to the state strings in the DCL Group Condition Language, Archie's proposal was introducing two ways of doing the same thing. | Addendum from Archie Lachner : | | My proposal introduces a REPLACEMENT for the way in which this is done | under 1481. I thought we all agreed that Shir-Shen's concern will be | addressed by adding wording indicating that, while an OLA-compliant | application shall use the graphs for these purposes, a NON-COMPLIANT | application would be free to use the strings. PLL Modeling and API Issues for the Decomposition of Cores ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ John presented his API proposal. The idea is that the call for delay on the *artificial* timing arc between PLL input and PLL output will result in a callback requesting delay calculation on the design-specific path between PLL output and PLL feedback. Wolfgang pointed out, that the former is exactly the inverse of the latter. Positive delay and frequency division, respectively, between output and feedback results in negative delay and frequency multiplication, respectively, between input and output. Only two or three PLLs can be expected to be found on a chip. Therefore the number of API callbacks that need to be implemented to model a PLL is not an issue. Modeling of frequency division and multiplication, as described in the original core timing modeling porposal by Archie, is involved, yet not restricted to, PLL modeling. wolfgang pointed out that the timing constraint taxonomy requires distinction between "derived clock" and "periodical signal". Not every periodical signal is a derived clock. A derived clock is defined by a period and a duty cycle and has exactly one rising and one falling edge within the period. The duty cycle is the ratio between the high pulse width and the period. A periodical signal may have an arbitrary number of 2N edges within one period. DFT discussion ^^^^^^^^^^^^^^ We reviewed John Beatty's proposal for NonScanCell property. An issue brought up by John is that in IBM technology, the NonScanCell could be a DFF, the scan cell could be MUX plus DFF. So there is a requirement to replace a single cell with more then one cell. John's proposal included the use of a mini-netlist in function graph form as the replacement. Shir-Shen had the same conclusion that the current implementation of NonScanCell in ALF and OLA does not fit the model of EDA tools. Perhaps ConnectClass could be used to stitch together the more then one cell scenario? Wolfgang pointed out that mini-netlists can be described in ALF using primitive instantiations in the function description and that this concept was developped in ALF precisely to accomodate DFT modeling requirements. Another issue is that the current implementation of OLA and ALF requires the scan cell to point to the NonScanCell. Today most tools do the reverse. A possible solution is to have the compiled OLA library implement the above with a new API. John took an action item for this. It was agreed to keep also the existing API, so that both APIs will allow a cross-probing between scan-cells and non-scan-cells. The ALF specifiation was established with contributions from Mentor and Sunrise (now Synopsys) DFT tool experts. From a library development standpoint it makes sense to reference a non-scan cell or a set of non-scan cells in the description of the scan cell, since the scan cell knows about its non-scan cell by definition whereas a non-scan cell does not know a priori for which scan cells it will be a placeholder. Another issue that was debated extensively was that the non scan cell could point to one scan cell (presumably of the same power level). It is up to the application to figure what the best power level replacement would be. Shir-Shen recommended to use the intelligence of the synthesis tool for the choice of the power level rather than to be library-driven. IBM prefers the library-driven solution. DFT memo from Mike Andrews ^^^^^^^^^^^^^^^^^^^^^^^^^^ Mike presented his document. Mike took notes on this discussion. discussion evolved around which DFT properties are useful and which could be infered from the function. Tim Ayres pointed out that relatively simple relations, such as output pin and related enable pin a defined explicitely whereas more complex relations, such as related data, control, address pins within multiport memories can only be infered from the function. An action item for ASIC vendors is to show function model descriptions of multiport memories in order to decide, for which cases inference from function or direct specification of property is more practical. Signal Integrity ^^^^^^^^^^^^^^^^ Wolfgang brought up the point that appGetCurrentRailVoltage is instance specific, which is what it should be. The question is, how does one handle transient IR (=V) drop. Some discussion; should the application or library compute IR calculation. Wolfgang -> application does this today. Tim Baldwin -> why not have the library doing this job? IR drop calculation is in principle the same as interconnect delay calculation. However, interconnect delay calculation is done on thousands of small nets in a design using relatively simple algorithms such as Elmor Delay, AWE. Therefore ASIC vendors can incorporate this into the library. Voltage drop calculation is done on one single net consisting of millions of R,L,C components. It requires matrix solving techniques. Therefore SPICE or dedicated application tools are doing this job today. As delay calculation becomes more complicated in DSM, including xtalk effects etc., the trend for delay calculation goes towards becoming a dedicated application as well. Therefore it is crucial to find efficient ways to incorporate 3rd party delay and voltage drop calculators into OLA. Jay took an action item to develop some sample code in order to show how vendors could plug in their delay calculator code. Pin resistance for output pins is defined in ALF to mean the driver resistance contained internally to a cell. This resistance can be a state-dependent value as well as a non-linear arithmetic model (table or equation). OLA 1.0.2 API dpcmGetPinResistance may not be needed since the OLA library itself knows internally the cell pin resistance. VOID pointers for this can be passed around for the admittance of this resistance. It could be superseeded by dpcmAppendPinAdmittance, where PinAdmittance represents an RLC network. The remaining issue is the representation of a non-linear resistance. For cross talk there needs to be a dpcmCalcNoise API for the calculation of noise. Wolfgang took an action item for this. Discussion on whether the IEEE 1481 definition of energy meant total energy. After checking the spec, the conclusion was: In IEEE 1481, energy calculation is total energy. NetEnergy calculation is energy due to interconnect. Wolfgang pointed out that the ALF 1.0.11 spec clearly and unambigously stated that ENGERGY meant total energy (internal + charge/discharge effect). Thus ALF and OLA would be perfectly in sink. Mike said it there is room for another interpretation, and some people might want to represent the internal energy separately in the library. Clock Tree Modeling ^^^^^^^^^^^^^^^^^^^ Sergei Sokolov from Sente was to present on this, but was absent due to illness. Wolfgang said that this sort of modeling was needed for early power estimation and clock tree synthesis. Inclusion of Physical in OLA ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We discussed current activities in this area by OPEF and the ASIC Council. OPEF is in the process of reviewing the data model of the Synopsys/Gambit format GIOF for determination if it satisfies requirements for physical design tools. Both ASIC Council and OPEF have requested Cadence to donate the LEF file format to a standards body. A decision on this is expected shortly. It was felt that the goal of the OLA working group must be to focus on the long term and develop a data model for and then develop the appropriate APIs. Jay Abraham took it as an action item to get involvement by physical design experts from ASIC and EDA vendors in the next OLA meeting. Meeting adjourned at 2:30pm on 6/3/99 ----------------------------------------------- WWW : http://www.si2.org Jay Abraham Phone: (512) 342-2244 X52 Si2 Inc. Fax : (512) 342-2037 4030 Braker Lane, Suite 550 Pager: 1-800-SKY-PAGE X1897776 Austin, TX 78759 Email: jabraham@si2.org