Hi Radek,
We can discuss this during the editorial committee meeting and ATM
meeting, but your point seems to reflect the implied intent documented
in BIRD152.2.
Bob
From: radek_biernacki@xxxxxxxxxxxx [mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Thursday, April 02, 2015 11:45 AM
To: bob@xxxxxxxxxxxxxxxxx; fangyi_rao@xxxxxxxxxxxx; wkatz@xxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Updated PAM4 BIRD rev 5
Hi Bob,
I think we should allow any reserved parameter that is currently, or in the
future, considered as potentially "Out" to also be "Dep".
If a parameter is considered potentially "Out" it means that the its value
is intentionally passed to the EDA platform. Then, if that value is devised
to be dependent on the other input to DLL, then it needs to be designated as
"Dep".
Radek
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Thursday, April 02, 2015 10:43 AM
To: RAO,FANGYI (K-USA,ex1); wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Updated PAM4 BIRD rev 5
Fangyi,
Thanks.
Regarding approved BIRD155.2, do all 18 of the existing Reserve Parameters
for jitter and noise that support (Usage Out) [See Table 24, pg. 218
or Table 30, pg. 227] also support (Usage Dep)?
BIRD155.2 suggests that we change Out to Out/Dep in the table.
[The actual implementation in the tables is left to the editorial committee.
For example, the current column Out can be renamed to Out/Dep.]
[Tables 17-19 will be modified to add Resolve_Exists and to include Dep in
allowed usage types of jitter parameters.]
Now we should create a new column for just Dep so that we can document
(Usage Out) and (Usage Dep) independently
to handle the PAM4 cases below.
Bob
From: fangyi_rao@xxxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxxx]
Sent: Thursday, April 02, 2015 10:07 AM
To: bob@xxxxxxxxxxxxxxxxx; wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Updated PAM4 BIRD rev 5
Bob,
We probably don't need the Dep type for the new parameters. They are not
used in the analog channel characterization, so their dependencies on other
parameters can be resolved by model in AMI_Init and AMI_GetWave.
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, April 01, 2015 2:58 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updated PAM4 BIRD rev 5
Walter,
Here are some editorial comments to conform with IBIS Version 6.1
conventions:
Where the Type is String, use Default: <string_literal>
Where the Type is Float, use Default: <numeric_literal>
In most, if not all cases, the default value assignments are given in the
Usage Rules
sections.
For Modulation, only the enumerated strings "NRZ" and "PAM4" should be
legal. Any
other string is an error. The default "NRZ" applies if the Modulation
parameter is
not included in the .ami file.
For PAM4_Mapping, the additional rule should be that the Value consists of a
four
digits: 0, 1, 2, and 3. None of these can be repeated in the four character
string.
(While this rule is implied, it should be spelled out. Thus "0223" and
"3125" would
be flagged as an error.)
Should we also include Usage: Dep for those Reserved Parameters that support
Usage: Out?
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, March 31, 2015 1:31 PM
To: IBIS-ATM
Subject: [ibis-macro] Updated PAM4 BIRD rev 5
All,
I am enclosing an update PAM4 BIRD (now at rev5). Please review carefully. I
plan on submitting this formally to the IBIS Open Forum meeting on April 10.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
