[ibis-macro] Re: FW: BIRD147.1 Concern
- From: <radek_biernacki@xxxxxxxxxxxx>
- To: <bob@xxxxxxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 10 Nov 2014 23:01:20 +0000
Hi All,
I have also promised to send my comments to Ambrish, though I expressed them
several times during ATM meetings.
1. The proposed AMI parameter "Training": (a) what is the rationale for the
type of training - increments vs. coefficients - to be in the AMI, rather than
in the BCI info, and (b) what is the rationale for the type of training -
in/decrements vs. coefficients - to be an "In" type of Usage - is it up to the
user to select it or to the protocol? I believe that the AMI info should be
concerned with the flow only, and not the details of the information exchanged
between the Tx and Rx.
2. All the information sent from Rx exclusively for the consumption by Tx (and
vice versa) should be in the form of data (strings) that would not require the
EDA platform to parse, interpret, etc. For that reason I suggested (long time
ago) that a clean way of achieving this would be by defining a separate API
like BCI_Init() and BCI_GetWave() functions.
Radek
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Bob Ross
Sent: Monday, November 10, 2014 2:20 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] FW: BIRD147.1 Concern
ATM Group:
This did not go out on the ATM reflector last week (I was not subscribed.)
Bob
-----Original Message-----
From: Bob Ross [mailto:bob@xxxxxxxxxxxxxxxxx]
Sent: Monday, November 03, 2014 5:44 PM
To: 'IBIS-ATM'
Cc: Ambrish Varma
Subject: BIRD147.1 Concern
ATM Group
From the last meeting, which I did not attend, I was asked to express my
concerns about BIRD147.1.
My main concern is that the back-channel protocol allows tap parameters with
one or two values for the Statistical Flow whereas the AMI syntax allows only
one value. I do not know if anyone else is bothered by this inconsistency.
Ambrish and I discussed this issue in the past, and I even had an alternative
proposal involving a new BCI file Reserved_Parameter (Tap_Range_Name...) to
define a Protocol_Specific parameter name to be used for passing the min and
max tap coefficient values for each tap coefficient using Format Table. (This
was similar to the earlier SiSoft proposal.)
We did not add this to BIRD147.1 at that time because Ambrish argued that it
made the protocol unnecessarily complicated and perhaps incomplete.
However, the notion that any new, standardized BCI file protocol can create new
rules (that conflict with IBIS-AMI parameter rules) as long as the Rx and Tx
understand each other still bothers me.
Bob
--
Bob Ross
Teraspeed Labs
http://www.teraspeedlabs.com
bob@xxxxxxxxxxxxxxxxx
Direct: 503-246-8048
Office: 971-279-5325
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
