ALF meeting minutes, October 8 1999 @ IBM, Burlington VT

Attendees:

Mike Andrews		Mentor
Archie Lachner		Mentor
Kent Moffat		Mentor
Jim Engel		IBM
Susan Lichtensteiger	IBM
Andrew Zafarakis	IBM
Shir-Chen Chang		Synopsys
Dan Moritz		LSI
Cary Wei		Fujitsu
Wolfgang Roethig	NEC


ALF spec. review
----------------

Wolfgang distributed a document containing proposals for
	1. amendments for ALF 1.1
	2. new features for ALF 2.0, excluding layout features

1.1 Incremental redefinition of vector

Feedback from Shir-Chen: useful feature, we should also consider incremental
addition of other objects, e.g. property, attributes, library, sublibrary.
"supplemental definition" is better wording than "incremental redefinition".
Maybe a parser hint on supplemental definition would be useful.
Note: this feature is transparent to OLA.

A.I. change "incremental redefinition" into "supplemental definition" - Wolfgang
A.I. put proposal for supplemental definition of library etc. into doc. - Wolfgang
A.I. give feedback from ALF parser developper - Sente, CADWorx, VLSI

1.2 Timing arcs in the context of vector

This looks o.k. It formalizes the rules which are followed in practical
ALF library development today.
Note: OLAWorx follows these rules as well.

1.3 Normative distinction between "driver resistance" and "pin resistance"

The driver resistance is mainly for Xtalk. NEC is currently characterizing
driver resistance for new technologies.

Note: A corresponding OLA construct does currently not exist. It was desired
to pull xtalk-enabling features into OLA prior to version 2.0.

2.1 EDGE_NUMBER for timing arc

This looks o.k., as it has been discussed in previous meetings.

A.I. put illustrative figures from last meeting into the spec - Wolfgang

Note: The corresponding OLA feature has also been discussed between Archie Lachner,
John Beatty, Jay Abraham and Wolfgang. It will reside in the vector-timing domain.

2.2 STRUCTURE statement

This has been also discussed in previous meetings. Shir-Shen was concerned about
tool implications, which can be addressed by adding more explanatory text.
The idea is that a cell with a structure underneath shall have top-level function,
timing and power models. The only tools concerned with the models of the instantiated
cells in the structure shall be library characterization and library verification tools. 
Design tools shall only use the top-level function, timing, power models.
Mike Andrews pointed out, that STRUCTURE matches a physical netlist whereas instantiations
in BEHAVIOR are for modeling purpose only.
Wolfgang: The CELLTYPE of a cell with STRUCTURE should be BLOCK.

A.I. put the appropriate statements into the doc - Wolfgang


IEEE PAR (Process Authorization Request)
----------------------------------------

The flow is the following:
PAR -> DASC -> study group max. 6 months -> NESCOM -> work group -> Ballot -> REVCOM
issues: schedule, copyright, intercept with other standards

ALF/OLA relationship: OLA will be the next version of IEEE 1481, ALF will get a
separate PAR number 1481.1
This ensures indepenence between ALF and OLA in terms of schedule and balloting,
On the other hand, the relationship between ALF and OLA is also clearly indicated
by the dot standard.

A first suggestion for the text of the ALF PAR:

The objective of the Advanced Library Format (ALF) is to make it possible for integrated
circuit vendors to consistently specify and represent technology and cell characterization
information for function, timing, power, signal integrity only once per technology and to
use this information in a coherent way by all EDA tools for design creation and analysis.
This is accomplished by defining a standard modeling language for circuit design units,
i.e. cells and higher level design elements.

A.I. review the PAR and suggest amendments - all

Copyright issue: Can OVI workgroup still work on layout extensions to ALF and publish
the next version, when the timing, power, function part will already be under IEEE?

A.I. Find out from DASC about the best way of handling this issue - Kent Moffat


Addendum: Modeling of supply voltage constraints
------------------------------------------------

Note: This was brought up in the OLA meeting by Jim Engel. The issue was modeling
of voltage rails with mode-specific voltage ranges.
Wolfgang pointed out that there is already an ALF solution for this issue, which is
therefore included in these minutes.

Situation: A cell has an analog pin with a constant voltage which needs to be in a certain
range. Moreover, this range may be programmed by a digital control pin.

The ALF library describes the scenario as follows:

PIN modesel {
	DIRECTION = input; PINTYPE = digital;
}
PIN VSIG {
	DIRECTION = input; PINTYPE = analog;
// the following statement describes the voltage range on the pin without control pin
	LIMIT { VOLTAGE { min=1.0; max=3.5; } }
}

// the following statements describe the voltage range dependent on the state of the control pin
VECTOR ( modesel ) {
	LIMIT { VOLTAGE { pin=VSIG; min=1.0; max=2.0; } }
}
VECTOR ( !modesel ) {
	LIMIT { VOLTAGE { pin=VSIG; min=2.5; max=3.5; } }
}

A.I. Put this into an ALF application note - Wolfgang