ICM Issue Resolution Document  (IIRD)

IIRD ID#:        3.1
ISSUE TITLE:     RLGC Matrix Clarifications
REQUESTOR:       Michael Mirmak, Intel Corporation
DATE SUBMITTED:  July 22, 2004
DATE REVISED:    August 27, 2004
DATE ACCEPTED BY IBIS OPEN FORUM: August 27, 2004

****************************************************************************
****************************************************************************

STATEMENT OF THE ISSUE:

The RLGC matrix format used in ICM 1.0 was heavily influenced by the 
package format used in IBIS 2.1 and later IBIS revisions.  However, several
critical rules regarding the Sparse_matrix type and the [Row] keyword as 
expressed in IBIS 2.1 were not explicitly stated in ICM 1.0

Further, ICM adds a new matrix type, Diagonal_matrix, which was not part
of IBIS 2.1.  Several rule descriptions copied from IBIS 2.1 require
modifications for use with the Diagonal_matrix type in ICM.

****************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Changes in IIRD3 are denoted by |*.
Changes in IIRD3.1 are denoted by |**.
 
The text of Section 8 should be changed as follows:

a) Under Sparse_matrix, add the text below:

|* Note that, while entries must be included for each and every [Row], column 
|* information listed for each row may be incomplete.  For example, [Row] 1 
|* may contain entries for columns 3, 4 and 5 while [Row] 3 may contain 
|* entries for columns 3, 6 and 7.
|*
|* Data for the entries of a row is given in a slightly different format,
|* than that used for other matrix types. For the entry [I, J] of each row I, 
|* the name of column J must be explicitly listed before the value of the 
|* entry is given. This indicates to the parser where the entry is put into 
|* the matrix.
|*
|* Note that each of the column indices listed for any row must be greater 
|* than or equal to the row index, because they always come from the upper 
|* half of the matrix. 
|
|* With this convention, please note that the Nth row of an N x N matrix has
|* just a single entry (the diagonal entry).


b) Under the [Row] keyword, delete following line:

Row 1 always has the most entries, and that each successive row has one fewer 
entry than the last; the last row always has just a single entry.

c) Under the [Row] keyword, change the following line:
Required: Yes

to:
|* Required: Yes, for Banded_matrix, Full_matrix and Sparse_matrix types

d) Under the [Row] keyword, add the following line:

|** Where [Row] is required (i.e., for the Banded_matrix, Full_matrix and 
|** Sparse_matrix types) [Row] entries must exist for each and every row 
|** number in the matrix, in increasing numerical order.


****************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Section (a) is added to enforce consistency with the examples given later in
the ICM 1.0 document.  This text also explains why Sparse_matrix data sets
include additional numerical arguments at the beginning of each line.
Note that the text is partially adapted from the IBIS 4.1 specification's 
PKG format description.

Section (b) addresses the formatting of [Row] for the various matrix 
types.  The original rule is incorrect for Sparse_matrix (at least, from 
the example shown later in the documet) and may not be true for 
Diagonal_matrix.

Section (c) modifies the [Row] keyword requirement rules from IBIS 2.1;
ICM should not require [Row] for all matrix data, because the Diagonal_matrix
data type does not need it (Diagonal_matrix does not exist in IBIS).

Section (d) clarifies the requirement that [Row] data must be ordered
numerically from lowest-to-highest and makes explicit the requirement for
[Row] data for each physical row in the interconnect being described. 

****************************************************************************

ANY OTHER BACKGROUND INFORMATION:

Section (d), in some form, may be needed in a future version of IBIS.

Changes in IIRD 3.1 made in response to comments from Bob Ross of Teraspeed 
Consulting Group during the August 27, 2004 IBIS Open Forum meeting.

****************************************************************************