ALF conference call, May 9 2000, 10AM - 11:30AM

Participants:

Mike Andrews		Mentor
Joe Daniels     	Intrinsix
Wolfgang Roethig	NEC
Dan Moritz		LSI (joined later)

Bitmap proposal review
----------------------

Pin ATTRIBUTEs for memory BIST	o.k.

RANGE o.k.

TEST { behavior } o.k.

Introduce additional pin attributes for DRAM:
	ROW_ADDRESS_STROBE, COLUMN_ADDRESS_STROBE

Logic BIST requirements are covered by
	FUNCTION, CELLTYPE, SIGNALTYPE

Expecting feedback from Logicvision, before OKing
the proposal.

Meeting minutes review from April 20
------------------------------------

Cell attributes for special cells o.k.

Note: Tie cells are CLAMP cells with high drive strength,
pull up/down are low drive strength.

Example:

CELL my_pullup {
	CELLTYPE = special;
	ATTRIBUTE { CLAMP }
	PIN my_pin { DIRECTION = output; }
	FUNCTION { BEHAVIOR { my_pin = 'bH; } }
}
CELL my_tie_high {
	CELLTYPE = special;
	ATTRIBUTE { CLAMP }
	PIN my_pin { DIRECTION = output; }
	FUNCTION { BEHAVIOR { my_pin = 'b1; } }
}

CELLTYPE BLOCK o.k.
PLACEMENT_TYPE BLOCK o.k.

Note:
"CELLTYPE" BLOCK is from a function/synthesis perspective.
It means that the cell can be described and synthesized
as a netlist of leaf cells.

"PLACEMENT_TYPE" BLOCK is from a layout perspective.
It means that the cell is a hierarchical block within which
smaller components are placed.


CELLTYPE CORE	o.k.
PLL may be a different category than DSP, CPU, but this
could be indicated by supplementary attributes.
However, there seems to be no requirement to distinguish
cores which contain analog components from cores which don't
from a tool perspective. This information would be purely
informational.

LOAD_ENABLE, LOAD_CONTROL
purpose: state initialization of a sequential element,
e.g. counter, shift register

Proposal for new attributes for logic building blocks
-----------------------------------------------------

The following attribute values apply for cells with
CELLTYPE = BLOCK | CORE (depends whether synthesized or hardmacro)

ATTRIBUTE { COUNTER | SHIFT_REGISTER | etc. }

COUNTER
	a complex sequential cell going through a predefined sequence
	of states in its normal operation mode where each state represents
	an encoded control value.

SHIFT_REGISTER
	a complex sequential cell going through a predefined sequence
	of states in its normal mode, where each subsequent state can be
	obtained from the previous one by a shift operation and each bit
	represents a data value.

Mike will gather more attributes for logic building blocks.

Proposal for differential pins
------------------------------

Introduce the following multi-value annotation at the cell level:

PIN_PAIR { <pin_name> <pin_name> }

Introduce the following ATTRIBUTE values for PINs which are
part of a PIN_PAIR:

INVERTED
	Signal is part of a pair of signals carrying complementary values.
	The value of this signal is inverted.
NON_INVERTED
	Signal is part of a pair of signals carrying complementary values.
	The value of this signal is not inverted.
DIFFERENTIAL
	Signal is part of a differential pair of signals. Differential pairs
	of signals have to be routed together.

Restrictions:
PINTYPE, SIGNALTYPE, DIRECTION of both pins of a PIN_PAIR must be the same.
One PIN must have the attribute INVERTED, the other NON_INVERTED.
Either both pins or none must have the attribute DIFFERENTIAL.
POLARITY, if applicable, must be complementary as follows:
HIGH <-> LOW
RISING_EDGE <-> FALLING_EDGE
DOUBLE_EDGE <-> DOUBLE_EDGE

Note: The INVERTED, NON_INVERTED attribute provides also a good substitution
of the phased-out POLARITY = INVERTED | NON_INVERTED | BOTH | NONE item.

Note: DIFFERENTIAL is a special case of PIN_PAIR. For instance, a flipflop
with dual-rail output can use the INVERTED, NON_INVERTED attribute for
Q and Qbar without Q and Qbar actually being differential signals.

API discussion
--------------

Concern for APIs: Compact definitions in ALF, such as GROUP, TEMPLATE,
get expanded in OLA. Maybe more efficient APIs are needed which preserve
the notion of GROUP, TEMPLATE etc.

Action items
------------

A.I. Gather attributes for logic building blocks from databook - Mike

A.I. give feedback or o.k. for bitmap proposal - Steve Pateras, Tim Ayres

A.I. Merge spec. - Wolfgang

A.I. define APIs for DFT - Dan
 
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: physalfnotes10may2000.txt
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 280

Conference call for physical ALF, May 9 2000, 2PM - 4PM

Participants:

Tom Belpasso	Cadence
Simon Favre	Monterey
Paul Zukowski	IBM
Joe Daniels	Intrinsix
Wolfgang Roethig	NEC

SYMMETRY statement
------------------
>> Reviewed the SITE statement. The ALF Symmetry statement was reworked to allow 
>> the definition of specific legal orientations. The ALF example needs to be 
>> updated to include multiple symmetry statements. It appears that we need to 
>> rework this one more time to make the flip and rotate commands independent of 
>> one another.
>> Today there is an implied "OR" which makes it impossible to exclude certain 
>> orientations.

>> A.I. modify SYMMETRY definition - Wolfgang

> The easiest way is to modify the semantics. FLIP and ROTATE within
> one SYMMETRY statement should be strictly interpreted as AND.
> Multiple values within a FLIP or ROTATE statement should be 
> strictly interpreted as OR.
> 
> Example:
> 
> SYMMETRY { FLIP { X Y } }
> means	FLIP X or FLIP Y
> 
> SYMMETRY { FLIP { X } ROTATE { 90 } }
> means	FLIP X and ROTATE 90
> 
> SYMMETRY { FLIP { X Y } ROTATE { 90 } }
> means	(FLIP X and ROTATE 90) or (FLIP Y and ROTATE 90)
> 

Erratum in the example: "X", "Y" should be "0", "90"

Tom Belpasso: The overloaded keyword SYMMETRY in LEF has created a lot
of confusion. The recommendation is to use two separate keywords:
SYMMETRY indicates the symmetry of an object.
ORIENTATION indicates the legal orientation of an object.

Proposal:

SYMMETRY statement shall be used for a SITE to indicate symmetry.
Multiple SYMMETRY statements shall be legal to enumerate all possible
combinations in case they cannot be described within a single SYMMETRY
statement.

ORIENTATION statement shall be used for a SITE and a CELL.
Multiple ORIENTATION statements shall be legal to enumerate all possible
combinations in case they cannot be described within a single ORIENTATION
statement. The ORIENTATION statement shall use the same constructs as the
SYMMETRY statement.

ORIENTATION of a CELL means the orientation of the cell itself.
ORIENTATION of a SITE means the orientation of rows that can be created
using that site.

Legal orientation of a cell within a site shall be defined as the
intersection of legal cell orientation and legal site orientation.
If there is a set of common legal orientations for both cell and site
without symmetry, the orientation of cell instance and site instance
must match.
If there is a set of common legal orientations for both cell and site
with symmetry, the cell may be placed on the side using any orientation
within that set.

Example 1: no symmetry
SITE has legal orientations "north" and "flip-north".
CELL has legal orientations "north" and "flip-north".
When the site is instantiated in "north" orientation, cell must be
placed in "north" orientation.

Example 2: symmetry
SITE has legal orientations "north" and "flip-north"
and symmetry between "north" and "flip-north".
CELL has legal orientations "north" and "flip-north".
When the site is instantiated in "north" orientation, cell may be
placed in either "north" or "flip-north" orientation.

Supplementary proposal:
(Wolfgang thinks this syntax change may make the library more
readable and compact)

Describe a set of predefined orientations at the library level.
All SYMMETRY and ORIENTATION statements shall refer to the
predefined set.

orientation_definition ::=
	ORIENTATION <orientation_name> {
		[ FLIP = <number>; ]
		[ ROTATE = <number>; ]
	}

orientation_reference ::= 
	ORIENTATION { <orientation_name> ... }

orientation_reference_for_symmetry ::= 
	SYMMETRY { <orientation_name> ... }

Example:

LIBRARY my_library {
	ORIENTATION north { ROTATE = 0; }
	ORIENTATION flip_north { ROTATE = 0; FLIP = 0; }
	ORIENTATION south { ROTATE = 180; }
	ORIENTATION flip_south { FLIP = 90; }
	SITE site1 {
		ORIENTATION { north flip_north }
	}
	SITE site2 {
		ORIENTATION { north flip_north south flip_south}
		SYMMETRY { north flip_north }
		SYMMETRY { south flip_south }
	}
	CELL cell1 {
		SITE { site1 site2 }
		ORIENTATION { north flip_north }
	}
	CELL cell2 {
		SITE { site2 }
		ORIENTATION { north south }
	}
}
/*
	cell1 may be placed on site1.
	Orientation of site1 and cell1 must match.

	cell1 may be placed on site2, provided that site2 is
	instantiated in either north or flip_north orientation.
	Orientation of site2 and cell1 need not match.	

	cell2 may be placed on site2, provided that site2 is
	instantiated in either north or south orientation.
	Orientation of site2 and cell2 must match.	
*/


ANTENNA statement
-----------------

Simon Favre: change wording "accumulative" into "cumulative"

Tom Belpasso: some new antenna features are in LEF 5.4
to cover antenna rule checking in hierarchical design.

Wolfgang: This is supported in ALF by the AREA statement in PIN
and a reference to an antenna rule (see example p. 78)

Simon: Example including diffusion may be useful as well.
Also need description capability for diodes.

Wolfgang: Diode is described as cell with CELLTYPE=special
and ATTRIBUTE { DIODE }
The pin has area on diffusion layer.

Example:

CELL my_diode {
	CELLTYPE = special; ATTRIBUTE { DIODE }
	PIN my_diode_pin {
		AREA = <number> {
			LAYER = diffusion;
			ANTENNA { <list_of_names_of_antenna_rules_with_diffusion> }
		}
	}
}

ARRAY statement
---------------
>> We reviewed the ARRAY statement. The statement allows the definition of 
>> routing grids and placement locations.  The REPEAT statement is used to 
>> allow for a compact description of complex definitions. The ARRAY should 
>> be able to be owned by an object (a hierarchical block). The SITE/ARRAY/CELL
>>  statements need to be updated to show an explicit origin.  The proposed 
>> mechanism was by the addition of a GEOMETRIC MODEL to define the bounding box.
>>  By default, the bounding box will be a rectangle with the origin at the lower 
>> left and the size of the rectangle defined by the width and height attributes.

>> A.I. update ARRAY definition - Wolfgang

> The following updates are proposed:
> 
> ARRAY statements may be
> 	inside a LIBRARY
> or	inside a SUBLIBRARY
> or	inside a CELL with PLACEMENT_TYPE=block.
> 
> CELL, ARRAY, SITE objects may have a geometric_model statement (in practice 
> restricted to RECTANGLE) to define the bounding box with self-defined origin.
> Per default, the WIDTH and HEIGHT statement within CELL, ARRAY, SITE defines 
> a rectangular bounding box with lower left corner 0/0.
> 
> Example:
> 
> <object> <object_name> { RECTANGLE { 0 0 10 20 } }
> 
> is equivalent to
> 
> <object> <object_name> { WIDTH = 10; HEIGHT = 20; }
> 
Proposal looks o.k.
Parametrizable array can be described using a template with placeholders.

FEEDTHROUGH statement
---------------------
>> The need and description of the FEEDTHROUGH keyword is unclear.  
>> A better understanding of how this keyword is currently used is 
>> needed prior to clarifying the spec.

> Found no corresponding construct in LEF. (Note: the SHAPE FEEDTHRU 
> statement in LEF is for a different purpose).
> Therefore the ALF definition (see page 53) mustbe justifiable by
> its own rights or it will be removed.

After review of the spec (pp. 53), the purpose was understood.
The recommendation is to keep it

Special spacing rule for blockages
----------------------------------
> Width-dependent spacing rules may not apply to blockages which are abstractions
> of smaller blockages collapsed together.
> The spacing rule between the constituents of the blockage and their neighboring
> objects should be applied instead.
> 
> Example: A blockage consists of two parallel vertical wires of width=1 and
> distance=1.
> They are collapsed to form a vertical blockage of width=3.
> Left and right of the blockage, the spacing rule should be based on the width of
> the constituent wires (i.e. 1) instead of the width of the blockage (i.e. 3).
> 
> Proposal: Allow a RULE statement inside a cell. ALLOW the RULE statement to
> refer to a predefined object within the cell, e.g. a blockage.
> 
> Example:
> 
> CELL <cell_name> {
> 	BLOCKAGE <blockage_name> { <blockage_definitions> }
> 	RULE {
> 		PATTERN <pattern_name> { <pattern_definitions> }
> 		LIMIT {
> 			DISTANCE {
> 				BETWEEN { <pattern_name> <blockage_name> }
> 				<distance_model>
> }	}	}	}

Idea looks good. Should be extended to port, since there may be special
spacing rules for ports as well.

However, syntax is verbose. Tom requested to have a simpler syntax for
simple rules, e.g. a constant spacing between an object and anything around
that object on the same layer.

Proposal:

A RULE statement may also be inside a BLOCKAGE or PORT statement.
That RULE statement shall have no BETWEEN statement. The RULE
shall apply between the object and any object around that object
on the same layer.

Example:

CELL <cell_name> {
	BLOCKAGE {
		LAYER = <layer_name>;
		RECTANGLE { <coordinates> }
		RULE {
			LIMIT {  DISTANCE { MIN = <number>; } }
}	}	}

RULE statements can be used for many purposes:
Spacing rules, as shown above, also overhang and extraction rules
(see various examples pp. 69).