ALF meeting March 7 @ Mentor Graphics Attendees (all day): Kent Moffat Mentor Graphics Dhaval Sejpal IBM Don Cottrell SI2 Simon Favre Monterey Paul Zukowski IBM Tim Ehrler Philips Tim Jennings Philips Jay Abraham Silicon Metrics Wolfgang R. NEC Greg Dufour Mentor Graphics John Beatty IBM Joe Daniels Intrinsix Additional attendees (joining late morning/early afternoon): Alex Zamfirescu ASC Pierre Giroard Logicvision Rajesh Uppuluri Logicvision Agenda: morning: Physical modeling discussion Review of ALF 2.0 features for layout afternoon: Review of ALF 2.0 features for interconnect analysis Review of ALF 2.0 features for function and test Physical modeling discussion ---------------------------- 1. LEF/DEF status Don Cottrell presented LEF/DEF license status. The group discussed possible migration paths from LEF to OLA. 1st possibility: Put new modeling features in LEF syntax. Augment LEF API for the new features and integrate into OLA. 2nd possibility: Use the proposed ALF syntax for the new modeling features. Augment OLA with APIs for the new features. The group leaned in favor for the 2nd possibility, since the LEF syntax does not lend itself to extensibility except for ad-hoc extensions. The arithmetic model concept in the ALF language provides already most of the required extensions for nanometer design rules. A.I. recommend the ALF syntax from a technical merit to the ASIC council General Managers - ASIC council Technical Managers 2. SIPPS presentation by Don Cottrell The spec. is also available through SI2. SIPPS is the input to extraction rule generation programs. It contains a very detailed description of stack-up information. The group concluded that this is complementary to the physcial ALF language, which presents parasitic information at a higher level of abstraction. Review of ALF 2.0 features for layout ------------------------------------- 3. Review of LEF to ALF translation example (Paul Zukowski) Example contains SYMMETRY. Every orientation of the object can be described as a combination of (flip, rotate, shift) operations. Need the capability to enumerate each one explicitely. A.I. Update spec - Wolfgang DONE Example contains supply pin with DIRECTION. The meaning should be standardized as follows: DIRECTION = input means pin is a power supply sink. DIRECTION = output means pin is a power supply source. DIRECTION = both means pin can be both source and sink. DIRECTION = none applies for a pin without connection to source or sink. These definitions are electrically equivalent to signal pins with direction. Note: The LEF direction "inout" for power does not follow this standard. A.I. update spec - Wolfgang DONE Example contains pin with ROUTING_TYPE. Tim Ehrler: A pin may have multiple ports, each of which has a different ROUTING_TYPE. A.I. Update spec: Allow ROUTING_TYPE for PORT, also in conjunction with CONNECT_RULE - Wolfgang DONE 3. Review of ALF spec., chapter 3 * Chapter 3.2 Geometric model statement Precedence for geometric transformations (shift, flip, rotate, repeat) is not necessary, since they apply to the origin of the object. Therefore the result is the same, independent of the order. FLIP statement shall specify the flipping direction, not the orientation of the axis. FLIP=0 means flip in horizontal direction, i.e., around a vertical axis. FLIP=90 means flip in vertical direction, i.e., around a horizontal axis. A.I. update spec - Wolfgang DONE * Chapter 3.3 LAYER statement LAYER has PURPOSE = master | routing | cut PURPOSE = overlap is not there. It exists in LEF as an auxiliary construct to define non-rectangular objects. It seems not necessary for ALF, since non-rectangular objects are fully supported by the language. A.I. make sure that we don't need "overlap" - Simon The PREFERENCE should apply only per layer, not accross all layers. Therefore the numbers for HORIZONTAL and VERTICAL should add up to 1 indiviually for each layer. A.I. update spec - Wolfgang DONE Paul: THICKNESS, WIDTH for LAYER need MIN TYP MAX Wolfgang: MIN, TYP, MAX is implicitely supported A.I. change example to show MIN, TYP, MAX - Wolfgang DONE * Chapter 3.6 PATTERN and VIA statement SHAPE = line | cross | tee | jog | corner | end Corner: rule applies at the corner Jog: rule applies for wire segment in the middle, usually non-prefered direction A.I. define reference for each shape when subjected to a rule or measurement - Wolfgang DONE VIA: New proposed set for USAGE = default | non_default | top_of_stack A.I. update spec - Wolfgang DONE Paul: need a via select model, i.e., selected via = f( width of routing wire ) Wolfgang: see via rule * Chapter 3.7 RULE statement Supports pattern-specific capacitance extraction rules. There will be a practical limit for complexity of patterns, however, the language does not impose restrictions. * Chapter 3.8 SITE statement SYMMETRY gives a restriction for a symmetrical cell to be placed at the site. Valid placement orientations are given by the intersection between CELL SYMMETRY and SITE SYMMETRY. PLACEMENT_TYPE for SITE is redundant, since it is in the CELL. A.I. update spec - Wolfgang DONE * Chapter 3.9 ANTENNA statement Wolfgang pointed out, that there exist various possible ways of accounting for area in path-based accumulative antenna rules. Not only the calculation equation, but also the path tracing algorithm must be specified somehow. A.I. try to describe the different variants of antenna rule calculations - all Review of ALF 2.0 features for interconnect analysis ---------------------------------------------------- * Chapter 2.4 The proposal of using vector expressions for describing timing and noise models in the context of xtalk was appreciated. Review of ALF 2.0 features for function and test ------------------------------------------------ * Chapter 2.5 SIGNALTYPE, OPERATION Feedback from Dhaval Sejpal (IBM): The herein proposed signaltypes should be adopted as is for OLA Review comments from Mike Andrews (by email): READ_WRITE_ENABLE signaltype is questionable. Also the polarity for xxx_CONTROL signaltypes would be useful. The use of OPERATION statement might be an overkill. Response from Wolfgang: According to the fundamental definition of ENABLE, READ_WRITE_ENABLE means that both read and write are enabled by the same state of the signal, indicated by its POLARITY, as opposed to READ_WRITE_CONTROL, where one state enables WRITE and the other state enables READ. The request of re-introducing polarity for control signals is noted and will be in an amendment. Wolfgang put the understanding of the signaltype definitions to a test on the whiteboard. 3 different implementations of a scan-flipflop were presented with the task of assigning correct signaltypes to the pins. See attached pdf file. Unfortuneatelly, the "intuitive" signaltype assignment clashed with the formal signaltype definition in the case of SCAN_ENABLE vs SCAN_CONTROL. It is customary to label the select input of the scan multiplexor with signaltype SCAN_ENABLE, regardless whether another mode may be enabled by the same input. The formal definition says, SCAN_ENABLE applies if and only if the scan mode is the only mode enabled by that pin. Otherwise, the signaltype should be SCAN_CONTROL. Conclusion: There seems to be a fundamental conflict between defining signaltypes in a formal way or in a customary way. The issue needs to be resolved by a vote. In the meantime, everybody who has issues with the currently proposed set of signaltypes should explicitely say which definitions are o.k. and which one should be changed, just as Mike did. A.I. give feedback on signaltype definitions - all A.I. amend proposal based on the feedback - Wolfgang Pierre raised questions on how OPERATION would be used by a DFT tool. Wolfgang explained the principle: A VECTOR contains a vector_expression describing the specified sequence of input stimulus and expected output. An OPERATION is associated with each VECTOR relevant for DFT. Note: a VECTOR without OPERATION is not relevant for DFT, but it may be relevant for timing, power etc., dependent on the models associated with the VECTOR. The vector_expressions must be self-sufficient such that the DFT tool can construct a valid sequence of operations based on the semantic meaning of the OPERATION only. For instance, the semantic meaning of OPERATION=START and OPERATION=END is that those operations must be the first or the last, respecitivily, in a sequence of operations. If those are not specified, the sequence can start or end, respectively, with any operation. Set of vectors with associated operations can be regrouped by EXISTENCE_CLASS. Only operations of the same EXISTENCE_CLASS can be used in one sequence. EXISTENCE_CLASS is orthogonal to OPRATION. For instance, there may be OPERATION=READ, OPERATION=WRITE in "fast" mode and in "normal" mode. Logical conditions associated with a certain operation are part of the vector_epression. Logical conditions which are common to all operations within a particular EXISTENCE_CLASS can be specified as EXISTENCE_CONDITION and therefore applied as co-factor to all vector_expressions. This concept has already been introduced for modal timing analysis. Maybe an application note for DFT is necessary. A.I. incorporate application note for DFT usage of EXISTENCE_CLASS, EXISTENCE_CONDITION in the spec. - Wolfgang Alex pointed out that the IEEE P1500 CTL & STYLE group also works on specifications for test pattern generation. However, Alex prefers the ALF vector_expression language for its capability of describing partial event sequences in an elegant way (using the *?, <&> operators etc.) A.I. point to the CTL and STYLE webpage - Alex * chapter 2.7 The mapping between logical and physical address and data for memories needs more work. Off-line discussions between Steve Pateras (Logicvision) and Wolfgang revealed that the semantics of "logical address" versus "physical address" in the Logicvision application note is opposite to the understanding in the ALF spec. Also, the current proposal can not describe a complete bitmap of the memory. The current proposal suffices for generating a checkerboard pattern. The group decided that we want to have the full bitmap capability, since this may be required for more sophisticated test patterns. A.I. write up the conclusions and present a proposal for bitmap - Wolfgang