ALF meeting Dec.8 @ SI2, Austin Texas

Attendees
	Robert Hoogenstryd	Silicon Metrix
	Robert Gonzalez		Silicon Metrix
	Steve Schulz		Texas Instruments
	Pierre Girouard		Logicvision
	Mike Andrews		Mentor Graphics
	Gregory Dufour		Mentor Graphics
	Archie Lachner		Mentor Graphics
	Andrew Zaferakis	IBM
	John Beatty		IBM
	Jay Abraham		SI2
	Tim Ehrler		Philips
	Gopal Varshney		Philips
	Dan Moritz		LSI Logic
	Wolfgang Roethig	NEC

Agenda:
1) Review of ALF modeling for DFT
2) Review of ALF incremental spec for version 2.0
3) misc

1) Review of ALF modeling for DFT
---------------------------------

Chapter 1 and chapter 2.1
previously reviewed

Chapter 2.2
Discussion: pin with multiple SIGNALTYPE values has multiple signaltype-specific
POLARITY values as well. Associating the polarity with the signaltype is more
natural than describing them in a separate ATTRIBUTE.
Existing style:
	SIGNALTYPE {READ WRITE}
	ATTRIBUTE { READ {POLARITY=high;} WRITE {POLARITY=low;} }
Recommended new style:
	SIGNALTYPE {READ {POLARITY=high;} WRITE {POLARITY=low;}}
A.I. change example - Mike Andrews
A.I. recommend to phase out ATTRIBUTE for READ, WRITE - Wolfgang Roethig

Chapter 2.3
Discussion: Describe how the ALF language for BEHAVIOR relates and tracks
the evolution of Vital. Many concepts for DFT are explicitely defined in Vital.
A.I. get some contact people for VITAL	- Steve Schulz

Chapter 2.4
Suggestion for ROM initialization: use ALF STATETABLE, INCLUDE statement
ROM initialization in the library is only applicable, when ROM is
programmed by the technology provider as opposed to the user.
A.I. write the suggestion for the DFT doc. - Wolfgang

Chapter 2.5
Discussion: PORTTYPE is proposed for describing READ, WRITE port.
Is this redundant, since the signaltype of the involved pins of the port
already define the porttype? Maybe not in all cases.
A.I. Find example where PORTTYPE is not redundant - Tim Ehrler

We may want to find a better keyword than PORTTYPE, since PORT is
already used in the context of physical modeling with different semantics.
A.I. Decide on an other keyword, maybe OPERATIONTYPE - all

Chapter 2.6
Discussion: For conflicts between read, write etc. a set of keywords
is proposed which represents an exhaustive enumeration of all cases.
A self-extending approach may be preferable instead.
A.I. Invent a constructive language, maybe use VIOLATION construct - Wolfgang

Chapter 2.7
A.I. Introduce OPERATION keyword formally - Mike

Chapter 3.1
A.I. Send email with additional signaltypes proposed by LSI Logic - Dan Moritz

Chapter 3.2 and 3.3
Discussion: How to describe the relationship between PIN and VECTOR
in the context of a particular operational mode.

A.I. remove OPERATION_SET, use EXISTENCE_CLASS instead - Mike Andrews

Question: Is the DFT doc on the critical path for OLA as implementation spec?
Answer: Probably not, since there is much more work to be done elsewhere,
e.g. interconnect delay calculation, crosstalk ...

Bit grouping and bit scrambling:
The doc. proposes that scrambilng of physical row and column address bits
may be interrelated. However, analysis of memory circuitry suggest that
address bit scrambling occurs only within a row or within a column,
respectively. However, the grouping/scrambling may depend on the memory bank.
For data bits, bit scrambling may be related to address bits.
A.I. Find out the applicable rules for bit grouping/scrambling
in general memory architectures - Wolfgang

Representation of scalar pins within a bus is necessary, especially
in a library applicable for both logical and physical modeling.
The following suggestion was made:
	PIN [1:3] my_pin {
		// put items applicable for the bus here
		my_pin [1] {
			// put items applicable for bit 1 here
		}
		my_pin [2] {
			// put items applicable for bit 2 here
		}
		my_pin [3] {
			// put items applicable for bit 3 here
		}
	}
Also, partial buses could be represented with this idea, e.g. my_pin[2:3]
A.I. Elaborate on the proposal - Wolfgang

Limited range of address, e.g. address[4:0] has 32 logical values,
but sometimes not all values are used.
Suggestion: use a shorter syntax than the current proposal in doc.
New proposal:
	PIN [4:0] address {
		address [4] = bank {
			// fill in items for address [4]
		}
		address [3:2] = column {
			MIN = 0; MAX = 2;
			// fill in other items for address [3:2]
		}
		address [1:0] = row {
			// fill in items for address [1:0]
		}
	}
A.I. Elaborate on the proposal - Wolfgang	
 

2) Review of ALF incremental spec for version 2.0
-------------------------------------------------
chapter 1.1
supplementary proposal accepted

chapter 2.1
A.I. include illustration with edge_number
     on the diagrams - Wolfgang Roethig

chapter 2.2
A.I. statement for timing arc inference by DFT tool
     from STRUCTURE statement - Mike Andrews

3) misc
-------
Existing ALF supports the following:
A PIN has a PINTYPE = digital | analog | supply
A PIN with PINTYPE=digital may have a SIGNALTYPE = data | address | clock etc.

Proposal 1: 
For a PIN with PINTYPE=supply define a SUPPLYTYPE = power | ground | bias | other?

Proposal 2:
Define a SIGNAL_CLASS and a SUPPLY_CLASS for digital and supply pins, respectively.
SIGNAL_CLASS and SUPPLY_CLASS are orthogonal to SIGNALTYPE and SUPPLYTYPE, respectively.
SIGNAL_CLASS assigns pins to a logical port, e.g. address, data, clock of a memory read port.
A pin may have more than one SIGNAL_CLASS, for example the clock may be common to
read and write port.
SUPPLY_CLASS assigns pins to a supply port, for instance power/ground for core,
power/ground for I/O, power/ground for a particular PLL

A.I. put example for SIGNAL_CLASS into DFT document, memory modeling - Mike Andrews

A.I. exchange ideas for usage of SUPPLYTYPE, SUPPLY_CLASS etc. - Tim Ehreler, Wolfgang Roethig

A.I. Get input from mixed-signal designers, whether it makes sense to have also
     ANALOGTYPE and ANALOG_CLASS for a PIN with PINTYPE=analog - Dan Moritz


Correction to ALF 1.1
A.I. include # as nonreserved character in ALF lexical spec. - Wolfgang