[ibis-macro] IBIS-ATM teleconference - Agenda for 3/29/2011
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 29 Mar 2011 10:37:22 -0700
Time: March 29, 2011 Noon US Pacific Time
=====
Audio:
======
Voice dial-in: (800) 637-5822
International: +1 (647) 723-3937 <--- (For Canada)
0114501530 <--- (For Sweden)
0201400572 <--- (For Sweden Toll Free)
069509594672 <--- (For Germany)
08001014542 <--- (For Germany Toll free)
Access Code: 685-0440
Web
===
Click Here to Join Live Meeting:
http://tinyurl.com/yvmesj
or:
https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j
%23-%25%7E5
Mentor Global Crossing Teleconference commands:
http://www.globalcrossing.com/customer/collaboration/cust_ready_access_t
ips.aspx
FIRST TIME USERS: To save time before the meeting, check your
system to make sure it is compatible with Microsoft Office Live
Meeting.
---------------------------------------------------------------------
Agenda
======
1) Opens
2) Call for any related patent disclosures
3) Review of ARs:
Bob: Write a BIRD on correcting Table 1-3 in the spec.
(Row 23 in the Task List).
- in progress
Any other AR-s?
Old ARs:
Arpad: Review the documentation (annotation) in the macro libraries.
- deferred until a demand arises or we have nothing else to do
4) Discuss Bob's question on Parser Bugs
5) Cross talk BIRD draft
- discuss recent changes made to the BIRD draft based on
comments from Radek, Vladimir, Fangyi and finalize it
for voting (attached)
6) Define relationship between Type and Format (Row 25)
- discuss BIRD draft from Ambrish (attached)
7) (Format) Table Syntax Clarification (Row 21, 22)
from Ambrish and Walter
- which one are we working on (see attached files)
8) Model_Specific parameters Usage Out/InOut
- Since we do not know the meaning of these, what is
the EDA tool expected to do with them?
- Type Tap has a unique meaning, we could allow this,
but something should be mentioned in the spec on what
the tool is expected to do (plot, log file, etc).
- how about the rest of the Types? Does it make sense
to allow them?
- discuss Walter's Out/InOut clarifications BIRD draft
(attached)
9) Back-channel proposals from SiSoft and Sigrity
- introduce updated BIRD draft (attached)
10a) BIRD 123, jitter parameters
- how do we deal with Usage Out? (includes Row 37)
- remove it from the spec?
- specify that only the Init function can return values?
- discuss Walter's BIRD 123.1
- was this officially submitted? (see attachment)
10b) BIRD 121, data management parameters (file support)
- questions, comments?
10c) BIRD 124, dependency table
11) Introduce Arpad's BIRD 117.3 and 118.2 changes
http://www.eda.org/pub/ibis/birds/bird117.3.txt
http://www.eda.org/pub/ibis/birds/bird118.2.txt
12) Introduce Arpad's BIRD 129
http://www.eda.org/pub/ibis/birds/bird129.txt
13) Discuss Walter's BIRD 122.1 draft (attached)
Remaining Task List items:
==========================
Row 18: What is the ambiguity between Format and Text Strings?
- answer: See row 25
Row 21: According to the BNF, the Format = Table syntax is invalid.
- If Format is removed, this s not a problem, but if Format
is there the problem still exists. Do we need to fix this?
- we will address this when talking about Table
Row 22: The syntax for a leaf is:
(Row 22 in Task List)
<leaf>: ( <parameter name> whitespace <value list> )
So in a Table which is written like this: (-50 -0.1 1e-35),
-50 is actually a parameter name, i.e. a string, not a value.
-deprecate Table back to List?
- we will address this when talking about Table
Row 23/24: Fix the two tables to reflect what is in the text
- Bob started a BIRD draft which will be finalized
as other BIRDs are completed
Row 25: Define relationship between Type and Format
- discuss Walter's suggestions
Row 26: This is basically the same as the items in Row 46-47.
Row 33: Is AMI_Init restricted to change first column of impulse_matrix
only?
- Sigrity is writing a BIRD draft on this (Ken)
Row 35: Clarify questions about impulse response
- this needs to be discussed
Row 37: Usage Out for reserved (jitter) parameters
- which function (Init or GetWave) can return these?
Row 46/47: Remove certain parameters and keywords
- this needs to be discussed
Thanks,
Arpad
=====================================================================
****************************************************************************
****************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: {TBD}
ISSUE TITLE: Clarification of the Table Format for IBIS AMI.
REQUESTOR: Ambrish Varma, Cadence Design Systems, Inc.
DATE SUBMITTED: March 22,2011
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
****************************************************************************
****************************************************************************
STATEMENT OF THE ISSUE:
The definition of Format Table is unclear when there is only 1 row in the
Table in the 5.0 version of the IBIS spec.
****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
On pg. 140 replace the following lines:
| Table The parameter name "Table" names a branch of the parameter
| tree rather than a single leaf. One of the leaves of this
| branch can be named "Labels" and, if provided, is to be
| assigned a string value containing a list of column names.
with these lines:
| Table The parameter name "Table" names a branch of the parameter
|* tree rather than a single leaf. For Usage In, if the table
|* has more than one row, the first column will be considered
|* to be the Parameter Name for that row. If the table has only
|* 1 row, parameter name for that row is not expected and the
|* entire row will be passed as value to the parent parameter.
|* One of the leaves of a Table can be named "Labels" and,
|* if provided, is to be assigned a string value containing
|* a list of column names.
A single-row table example:
(fwd (Usage In) (Type Float)
(Table ( RowName -0.169324 1.40308 0.33024 ))
)
In this case, the AMI model will expect a paramter string:
( fwd ( RowName -0.169324 1.40308 0.33024 ))
A multi-row table example:
(fwd (Usage In) (Type Float)
(Table ( myRow -0.169324 1.40308 0.33024 )
( yourRow -0.738358 -0.293473 -0.06912 ))
)
In this case, the AMI model will expect a paramter string:
( fwd ( myRow -0.169324 1.40308 0.33024 )( yourRow -0.738358 -0.293473 -0.06912
))
****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
The existing IBIS specification lacks clear definition the Format 'Table'
and how it should be treated when used as a format for a Usage 'In'
parameter. Because of prior use, and possible future use, distinction has
to be made between a single-row table and a multi-row table. A single row
table does not need a parameter name for the row and the parent parameter
is used in the string that gets passed back to the model. However, if
there are multiple rows in the table, the first column of the row is
considered to be a parameter name for that row.
****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
**************************************************************************** Buffer Issue Resolution Document (BIRD)
BIRD ID#: {TBD}
ISSUE TITLE: Defining Relationships between Type and Format
REQUESTOR: Ambrish Varma, Cadence Design Systems, Inc.
DATE SUBMITTED: March 08,2011
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
****************************************************************************
****************************************************************************
STATEMENT OF THE ISSUE:
The relationship between parameter type and their format is unclear in the
5.0 version of the IBIS spec.
****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Add the following text and table after Table 3 in Section 6c.
| The following table defines the relationships between the
different Format
| and Data Types for Reserved or Model Specific Parameters
|
|
| +-------------------------------------------------+
| | Data Type |
| =============================================================================
| | Format | Float | UI | Integer | String | Boolean | Tap |
| +-------------------------+-------+------+---------+--------+---------+-----+
| | Value | X X X X X X |
| | Range | X X X X |
| | Corner | X X X X X X |
| | List | X X X X X X |
| | Increment | X X X X |
| | Steps | X X X X |
| | Gaussian | X X X |
| | Dual-Dirac | X X X |
| | DjRj | X X X |
| | Table | X X X X X |
| +-------------------------+-------------------------------------------------+
|
| Table 4: Allowed Data Types for Format Values
|
|
****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
The existing IBIS specification lacks clear definition of the relationship
between AMI parameter types and their format. This BIRD proposes a table with
all the possible allowed combinations for Reserved as well as Model Specific
AMI Parameters.
****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
********************************************************************************************************************************************************
****************************************************************************
BIRD ID#: {TBD}
ISSUE TITLE: Crosstalk clarification w.r.t. AMI
REQUESTOR: Ken Willis, Sigrity, Inc.
Arpad Muranyi, Mentor Graphics, Inc.
DATE SUBMITTED: February 23,2011
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
****************************************************************************
****************************************************************************
STATEMENT OF THE ISSUE:
The description of how crosstalk is to be handled with respect to AMI models
is unclear in the 5.0 version of the IBIS spec.
****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Replace the following text in Section 3.1.2.1:
| 3.1.2.1 impulse_matrix
| ======================
|
| 'impulse_matrix' is the channel impulse response matrix. The impulse values
| are in volts and are uniformly spaced in time. The sample spacing is given
| by the parameter ?sample_interval?.
|
| The impulse_matrix is stored in a single dimensional array of floating point
| numbers which is formed by concatenating the columns of the impulse response
| matrix, starting with the first column and ending with the last column. The
| matrix elements can be retrieved/identified using
|
| impulse_matrix[idx] = element (row, col)
| idx = col * number_of_rows + row
| row ? row index , ranges from 0 to row_size-1
| col ? column index, ranges from 0 to aggressors
|
| The first column of the impulse_matrix is the impulse response for the
| primary channel. The rest are the impulse responses from aggressor drivers
| to the victim receiver.
|
| The AMI_Init function may return a modified impulse response by modifying
| the first column of impulse_matrix. If the impulse response is modified,
| the new impulse response is expected to represent the filtered response.
| The number of items in the matrix should remain unchanged.
|
| The aggressor columns of the matrix should not be modified.
With the following text:
| 3.1.2.1 impulse_matrix
| ======================
|
********************************************************************************
|* 'impulse_matrix' points to a memory location where the collection of
|* channel impulse responses, called the "impulse response matrix" is stored
|* in the form of a single dimensional array of floating point numbers. The
|* impulse values are in volts per second and are uniformly spaced in time.
|* The sample spacing is given by the parameter ?sample_interval?.
|*
|* The first column of the impulse response matrix is the impulse response
|* for a through channel, a channel that serves as a communication path
|* between a transmitter/receiver pair. The rest of the columns contain the
|* impulse responses of crosstalk channels. Crosstalk channels describe
|* the path between aggressor transmitters and victim receiver(s).
|* Transmitters which do not belong to a through channel are all considered
|* aggressor transmitters.
|*
|* The single dimensional array of 'impulse_matrix' is formed by concatenating
|* the columns of an impulse response matrix, starting with the first column
|* and ending with the last column. The matrix elements can be retrieved or
|* identified using the following relationships:
|
| impulse_matrix[idx] = element (row, col)
| idx = col * number_of_rows + row
|* row: row index , ranges from 0 to row_size-1
|* col: column index, ranges from 0 to aggressors
|*
|* Each column in the impulse response matrix must have the same sample
|* spacing and the same length.
|*
|* To include any crosstalk effects in the Reference Flows described in
|* this section of this specification, the crosstalk impulse responses
|* must be included in the 'impulse_matrix' and passed to the transmitter and
|* receiver AMI_Init functions. If present, any filtering in the transmitter
|* and/or receiver AMI_Init function(s) must also be applied to the crosstalk
|* impulse responses to properly account for the crosstalk effects. If the
|* 'impulse_matrix' is modified by the AMI_Init function(s), the modified
|* 'impulse_matrix' at the victim receiver is expected to represent the
|* filtered response of the through channel and the crosstalk channels.
|*
|* Note that when 'impulse_matrix' includes crosstalk impulse responses, the
|* transmitter's and receiver's 'impulse_matrix'-es will contain different
|* data sets, even for a transmitter/receiver pair of the same through
|* channel. A transmitter's AMI_Init function operates on all of those
|* impulse responses which originate from it (including the through and
|* all crosstalk channel impulse responses). A receiver's AMI_Init function,
|* however, operates on all of those impulse responses which are received by
|* it (including the through and all crosstalk channel impulse responses).
|*
|* As an illustration, consider a crosstalk analysis with five channels,
|* where channel 3 in the center is the through channel (victim) and channels
|* 1, 2 and 4, 5 are the aggressors. If the five 'impulse_matrix'-es of the
|* five transmitters' AMI_Init functions contain the following data:
|*
|*************************************
|* impulse_matrix impulse_matrix
|* column 1 column 2
|*
|*Tx1 IR1_1 IR1_3
|*Tx2 IR2_2 IR2_3
|*Tx3 IR3_3
|*Tx4 IR4_4 IR4_3
|*Tx5 IR5_5 IR5_3
|*************************************
|*
|* then the 'impulse_matrix' passed into the victim receiver's (Rx3) AMI_Init
|* function will contain the following data:
|*
|*********************************************************************************
|* impulse_matrix impulse_matrix impulse_matrix impulse_matrix
impulse_matrix
|* column 1 column 2 column 3 column 4 column 5
|*
|*Rx3 Tx3Init(IR3_3) Tx1Init(IR1_3) Tx2Init(IR2_3) Tx4Init(IR4_3)
Tx5Init(IR5_3)
|*********************************************************************************
|*
|* where "IRi_j" represents the impulse response from the transmitter on
|* channel i to the receiver on channel j, Tx1Init() .. Tx5Init() represents
|* the output of a transmitter's AMI_Init function which modified the impulse
|* response denoted inside the parentheses. Note that while the
|* 'impulse_matrix' of each transmitter's AMI_Init function contains at most
|* one crosstalk impulse response, the victim receiver's 'impulse_matrix'
|* contains four crosstalk impulse responses. Also, using the above notation
|* note that the first index number of each impulse response passed to the
|* transmitter's AMI_Init function matches the transmitter's channel number,
|* and the second index number of each impulse response passed to the
|* receiver's AMI_Init function matches the receiver's channel number.
|*
|* It is the EDA tool's responsibility to rearrange the content of the
|* 'impulse_matrix' between the transmitter and receiver AMI_Init calls.
|*
|* The EDA tool is also responsible to limit the number of crosstalk channel
|* impulse responses in 'impulse_matrix' so that they shall not exceed
|* 'Max_Init_Aggressors' as specified in the corresponding .ami parameter
|* file of the algorithmic model. Consequently, the 'aggressors' parameter
|* of the AMI_Init function shall never contain a greater value than the
|* value provided in 'Max_Init_Aggressors' of the corresponding .ami parameter
|* file. While the allocated memory space for 'impulse_matrix' may be larger,
|* it is assumed that there is no meaningful data in that space beyond the
|* last column of the impulse response matrix that is stored in it.
|*
|* The AMI_Init function must not change the size or organization of
|* 'impulse_matrix' that it was given in any way.
|*
****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
Discussion within the IBIS-ATM committee provided many important inputs to
this BIRD. It was desirable to clarify that the impulse_matrix columns
populated by the aggressor channels should include any impulse response
modification that is to be made by the respective aggressor transmitters.
****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
The following documents are provided as supporting material for this BIRD:
- "CrossTalk_IRmatrix.pdf", provided by Arpad Muranyi of Mentor Graphics
- "CrossTalk_Sparams.pdf", provided by Walter Katz of SiSoft
****************************************************************************
Other related posts:
- » [ibis-macro] IBIS-ATM teleconference - Agenda for 3/29/2011 - Muranyi, Arpad
