[ibis-macro] Re: New wording for what is in the parameter string
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 12 Jan 2011 11:32:49 -0800
Ambrish,
I didn't remove anything about Reserved and Model_Specific,
those are a few paragraphs above the words we are discussion.
I just didn't want to include too much of the unchanged text
in the email thread to help people to focus on the area that
is being discussed. But now that you mentioned this, I am
including the entire file in the attachment so that you can
look at the whole thing. Please look at it this way and
let me know if you still feel the same way after reading it.
Thanks,
Arpad
================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, January 12, 2011 1:14 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: New wording for what is in the parameter
string
Arpad,
There is nothing wrong with what you changed - just that I liked the
previous version because it gives a much clearer direction on what
should be included and how (to me, anyway) - for example - one of the
things that you removed is the clarification regarding including the
string "Reserved_Parameter" and "Model_Specific" in the string that goes
in the model.
Regarding the 3rd point I added - it will go before the statement in red
- so there is no question of contradiction.
Maybe it might make sense if I put the whole thing:
|* The EDA tool must process the content of the .ami file
so that
|* 1) the 'Reserved_Parameters' and 'Model_Specific'
branch
|* names and their associated open and close
parentheses "()"
|* are not included in the AMI_parameters_in string,
and
|* 2) the AMI Parameter branches with Usage In or Usage
InOut
|* are converted to leaf/value pairs for the
AMI_parameters_in
|* string, possibly incorporating user selections. In
this
|* conversion each AMI parameter branch name becomes a
leaf
|* name in the AMI_parameters_in string and each leaf
name
|* is followed by a white space, a value and a closing
|* parentheses ")".
|* 3) only parameters defined in the .ami file can be
included in the
|* AMI_parameters_in string.
|*
|* The EDA tool must include all Usage In and Usage InOut
AMI
|* parameters in the AMI_parameters_in string. The AMI
model will
|* ignore any parameter included in the AMI_parameters_in
string
|* that is not Usage In or InOut. The AMI
|* executable must return a string in AMI_parameters_out
|* which includes all AMI parameters of Usage InOut and
Usage
|* Out. The string must be in the parameter tree format
using
|* branches and leaf/value pairs.
It is just a suggestion - you may ignore it completely.
Thanks,
Ambrish.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 www.cadence.com <http://www.cadence.com>
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 12, 2011 1:41 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: New wording for what is in the parameter
string
Ambrish,
Thanks for your comment. I have a few problems with it.
The red text says that the AMI DLL will ignore anything that
is not Usage In or InOut. This statement doesn't prohibit
a Usage In or InOut parameter to be passed into the DLL by
the EDA tool which is not in the .ami file. It only says
that a Usage Out in the "in" string will be ignored by the DLL.
The sentence you say on the bottom of your email to add a "3)"
on the other hand contradicts the above somewhat (or is at least
inconsistent) because this says that nothing else other than
what is in the .ami file can be passed to the DLL.
Separating these two thoughts into two different paragraphs is
bothering me. It gives me the impression that here you are
saying this, there you are saying that, are you sure you know
what you are trying to say? Make up your mind...
I attempted to capture the same thoughts in one sentence. (I
worked really hard to get that sentence into the form it is).
You didn't say what you didn't like about it. At this point
I still refer my proposed sentence(s), but I am open for
suggestions if something is wrong with them.
Thanks,
Arpad
=================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, January 12, 2011 11:26 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: New wording for what is in the parameter
string
Arpad,
I actually like it the way it was. It gives a much clearer direction on
what should be included and how.
My suggestion is to change the second para (in the original text) to
something like this (changes in red):
|* The EDA tool must include all Usage In and Usage InOut AMI
|* parameters in the AMI_parameters_in string. The AMI model will ignore
any |* parameter included in the AMI_parameters_in string that is not
Usage In |* or InOut. The AMI executable must return a string in
AMI_parameters_out |* which includes all AMI parameters of Usage InOut
and Usage Out. The |* string must be in the parameter tree format
using branches and leaf/value |* pairs.
Also, we should add a 3rd point to para 1 with something like this:
3) only parameters defined in the .ami file can be included in the
AMI_parameters_in string.
Thanks,
Ambrish.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 www.cadence.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 12, 2011 1:43 AM
To: IBIS-ATM
Subject: [ibis-macro] New wording for what is in the parameter string
Hello,
According to our discussions in the ATM teleconference,
I rewrote the paragraph about what should be included
in the AMI parameter string and what shouldn't. Here
is that section of the BIRD draft:
|* The EDA tool must process the content of the .ami file
so that
|* 1) the 'Reserved_Parameters' and 'Model_Specific'
branch
|* names and their associated open and close
parentheses "()"
|* are not included in the AMI_parameters_in string,
and
|* 2) the AMI Parameter branches with Usage In or Usage
InOut
|* are converted to leaf/value pairs for the
AMI_parameters_in
|* string, possibly incorporating user selections. In
this
|* conversion each AMI parameter branch name becomes a
leaf
|* name in the AMI_parameters_in string and each leaf
name
|* is followed by a white space, a value and a closing
|* parentheses ")".
|*
************************************************************************
********
|* The EDA tool must include all Usage In and Usage InOut
AMI
|* parameters in the AMI_parameters_in string and the AMI
|* executable must return a string in AMI_parameters_out
|* which includes all AMI parameters of Usage InOut and
Usage
|* Out. The string must be in the parameter tree format
using
|* branches and leaf/value pairs.
************************************************************************
********
|* The following two paragraphs are to replace the previous one:
************************************************************************
********
|* The EDA tool must pass a string to the AMI executable
model
|* through the AMI_parameters_in argument which contains
all of
|* the leaf/value pair formatted Usage In and Usage InOut
AMI
|* parameters defined in the .ami file and nothing else.
|*
|* The AMI executable model must return a string to the EDA
tool
|* through the AMI_parameters_out argument which contains
all of
|* the leaf/value pair formatted Usage InOut and Usage Out
AMI
|* parameters defined in the .ami file and nothing else.
************************************************************************
********
|*
|* For Usage In, the value in the "AMI Parameter" leaves
are
|* determined by the EDA tool based on the "AMI Parameter"
|* branches in the .ami file. For Usage Out, the value in
the
|* "AMI Parameter" leaves are determined by the Algorithmic
|* Model. For Usage InOut, the value in the "AMI
Parameter"
|* leaves are first determined by the EDA tool based on the
|* "AMI Parameter" branches in the .ami file and passed
into
|* the Algorithmic Model which may return a new value in
the
|* "AMI Parameter" leaves after some processing.
|*
Please let me know whether this wording captures the thoughts
we discussed in the meeting, and make suggestions if not.
Thanks,
Arpad
==============================================================
---------------------------------------------------------------------
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
*****************************************************************************
*****************************************************************************
BIRD ID#:
ISSUE TITLE: IBIS-AMI Typographical Corrections
REQUESTER: Arpad Muranyi, Mentor Graphics, Inc.
DATE SUBMITTED:
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
*****************************************************************************
*****************************************************************************
STATEMENT OF THE ISSUE:
Section 6c of the IBIS v5.0 specification has numerous typographical or
editorial issues which may imply incorrect rules or could be confusing to
the reader.
In Section 6c, "ALGORITHMIC MODELING INTERFACE (AMI)", the use of the
keyword Format in parameter declarations is inconsistent with the common
use of parameter tree structures. Since the Format keyword really doesn't
serve a practical purpose and the existing IBIS AMI Check program does not
issue an error or warning when Format is not included, the suggestion is to
make the use of the keyword Format optional.
*****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
On pg. 140 replace the following lines:
| Usage: (required for model specific parameters)
| In Parameter is required Input to executable
| Out Parameter is Output only from executable
| Info Information for user or EDA platform
| InOut Required Input to executable. Executable may return different
| value.
with these lines:
|* Usage <usage>:
|*
|* Required, where <usage> must be substituted by one of the following:
| In Parameter is required Input to executable
| Out Parameter is Output only from executable
| Info Information for user or EDA platform
| InOut Required Input to executable. Executable may return different
| value.
|*
|* Note that the purpose of Usage Out or InOut is to provide a mechanism
|* for the Algrithmic Model to return a value to the EDA tool to either
|* report these values to the user, or to use these values as specified
|* by the IBIS-AMI specification if they are reserved parameters.
On pg. 140 replace the following lines:
| Type: (default is Float)
| Float
| Integer
| String
| Boolean (True/False)
| Tap (For use by TX and RX equalizers)
| UI (Unit Interval, 1 UI is the inverse of the data rate frequency,
| for example 1 UI of a channel operating at 10 Gb/s is 100 ps)
with these lines:
|* Type <data_type>:
|*
|* Required, where <data_type> must be substituted by one of the following:
| Float
| Integer
| String
| Boolean (True/False)
| Tap (For use by TX and RX equalizers)
| UI (Unit Interval, 1 UI is the inverse of the data rate frequency,
| for example 1 UI of a channel operating at 10 Gb/s is 100 ps)
On pg. 140 replace the following lines:
| Format: (default is range)
| Value <value> Single value data
| Range <typ value> <min value> <max value>
| List <typ value> <value> <value> <value> ... <value>
with these lines:
|* Format <data_format> <data>:
|*
|* Where Format is optional and <data_format> and <data> are required.
|* <data_format> and <data> must be substituted with one of the following:
|* Value <value> Single value data. Note that Value and Default
|* (defined below) are mutually exclusive, and must not be used
|* together for the same parameter.
| Range <typ value> <min value> <max value>
| List <typ value> <value> <value> <value> ... <value>
On pg. 141 replace the following lines:
| (Rx_Clock_PDF
| (Usage Info)
| (Type Float)
| (Format Table
| (Labels Row_No Time_UI Density)
| (-50 -0.1 1e-35)
with these lines:
| (Rx_Clock_PDF
| (Usage Info)
| (Type Float)
|* (Table
|* (Labels "Row_No" "Time_UI" "Density")
| (-50 -0.1 1e-35)
|
On pg. 141 reduce the indentation of the following lines:
| Gaussian <mean> <sigma>
| Dual-Dirac <mean> <mean> <sigma>
| Composite of two Gaussian
| DjRj <minDj> <maxDj> <sigma>
| Convolve Gaussian (sigma) with uniform Modulation PDF
On pg. 141 replace the following lines:
| Default <value>:
| Depending on the Type, <value> will provide a default value for the
| parameter. For example, if the Type is Boolean, <value> could be True
| or False, if the Type is Integer, the <value> can be an integer value.
with these lines:
| Default <value>:
|* Default and Value are mutually exclusive, and must not be used together
|* for the same parameter. Default is not allowed for Table, Gaussian,
|* Dual-Dirac and DjRj. Default is optional for Range, List, Corner,
|* Increment and Steps. If a Default <value> is specified, its value must
|* have the same Type as the parameter. For example, if Type is Boolean,
|* <value> must be either True or False, if Type is Integer, <value> must
|* be an integer. Also, if Default is specified, <value> must be a member
|* of the set of allowed values of the parameter. If Default is not
|* specified, the default value of the parameters will be the <typ> value.
On pg. 141 replace the following lines:
| Description <string>:
| ASCII string following Description describes a reserved parameter,
| model specific parameter, or the Algorithmic model itself. It is used
| by the EDA platform to convey information to the end-user. The entire
| line has to be limited to IBIS line length specification. String
| literals begin and end with a double quote (") and no double quotes are
| allowed inside the string literals.
with these lines:
| Description <string>:
|* The string following Description may describe a reserved parameter, a
|* model specific parameter, or the Algorithmic model itself. This string
|* is used by the EDA platform to convey information to the end-user.
|* Description <string> is optional, but its usage is highly recommended
|* for describing the Algorithmic model and the model specific parameters
|* of the Algorithmic model. The Description string may span mutliple
|* lines, but it is recommended that the text contained in the Description
|* string should not exceed 120 characters per line.
The following modifications assume that the section about Use_Init_Output
starting on pg. 144 will be removed as a consequence of the corrections
and simplifications made to the reference flow (BIRD 120).
On pg. 143 replace the following lines:
| The model parameter file must be organized in the parameter
| tree format as discussed in section 3.1.2.6 of ?NOTES ON
| ALGORITHMIC MODELING INTERFACE AND PROGRAMMING GUIDE?,
| Section 10 of this document. The file must have 2 distinct
| sections, or sub-trees, ?Reserved_Parameters? section and
| ?Model_Specific? section with sections beginning and ending
| with parentheses. The complete tree format is described in
| the section 3.1.2.6 of the Section 10 of this document.
with these lines:
| The model parameter file must be organized in the parameter
|* tree format as described in section 3.1.2.6 of "NOTES ON
| ALGORITHMIC MODELING INTERFACE AND PROGRAMMING GUIDE",
|* Section 10 of this document. The file must contain a distinct
|* section or sub-tree named 'Reserved_Parameters' beginning and
|* ending with parentheses. The file may also contain another
|* section or sub-tree named 'Model_Specific', beginning and
|* ending with parentheses. The sub-trees 'Reserved_Parameters'
|* and 'Model_Specific' are branches of the root of the tree.
|*
|* All leaves of the .ami file must begin with one of the
|* following reserved words:
|*
|* Type
|* Usage
|* Description
|* Default
|* <data_format> or Format <data_format>
|*
|* A branch in the .ami file is an "AMI Parameter" if it
|* contains the leaves Type, Usage, and any of the following
|* leaves:
|*
|* Default
|* <data_format> or Format <data_format>
|*
|* and does not contain another branch. Multiple leaves
|* containing the same reserved word are not allowed within an
|* AMI Parameter branch. A branch which contains one or more
|* sub-branches may only contain the (Description <string>)
|* leaf/value pair in addition to the sub-branches.
|*
|* The parameter string passed in and out of the DLL (described
|* in section 3.1.2.6 of Section 10 of this document) is
|* formatted the same way as the tree data structure in the .ami
|* file with the following exceptions.
|*
|* The EDA tool must process the content of the .ami file so that
|* 1) the 'Reserved_Parameters' and 'Model_Specific' branch
|* names and their associated open and close parentheses "()"
|* are not included in the AMI_parameters_in string, and
|* 2) the AMI Parameter branches with Usage In or Usage InOut
|* are converted to leaf/value pairs for the AMI_parameters_in
|* string, possibly incorporating user selections. In this
|* conversion each AMI parameter branch name becomes a leaf
|* name in the AMI_parameters_in string and each leaf name
|* is followed by a white space, a value and a closing
|* parentheses ")".
|*
********************************************************************************
|* The EDA tool must include all Usage In and Usage InOut AMI
|* parameters in the AMI_parameters_in string and the AMI
|* executable must return a string in AMI_parameters_out
|* which includes all AMI parameters of Usage InOut and Usage
|* Out. The string must be in the parameter tree format using
|* branches and leaf/value pairs.
********************************************************************************
|* The following two paragraphs are to replace the previous one:
********************************************************************************
|* The EDA tool must pass a string to the AMI executable model
|* through the AMI_parameters_in argument which contains all of
|* the leaf/value pair formatted Usage In and Usage InOut AMI
|* parameters defined in the .ami file and nothing else.
|*
|* The AMI executable model must return a string to the EDA tool
|* through the AMI_parameters_out argument which contains all of
|* the leaf/value pair formatted Usage InOut and Usage Out AMI
|* parameters defined in the .ami file and nothing else.
********************************************************************************
|*
|* For Usage In, the value in the "AMI Parameter" leaves are
|* determined by the EDA tool based on the "AMI Parameter"
|* branches in the .ami file. For Usage Out, the value in the
|* "AMI Parameter" leaves are determined by the Algorithmic
|* Model. For Usage InOut, the value in the "AMI Parameter"
|* leaves are first determined by the EDA tool based on the
|* "AMI Parameter" branches in the .ami file and passed into
|* the Algorithmic Model which may return a new value in the
|* "AMI Parameter" leaves after some processing.
|*
On pg. 144 add these lines before "Reserved Parameters:"
|*
|* All parameters must be in the following format:
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* ({Format} <data_format> <data>)
|* (Default <value>)
|* (Description <string>))
|*
|* Notes:
|* 1) The order of the entries is not important.
|* 2) The word Format is optional as indicated by the curly
|* braces "{" and "}" and may be ignored by the EDA tools.
|* (The examples do not show the word Format).
|* 3) Certain reserved parameter names allow only certain
|* <data_format> selections, as described below.
|* 4) The <data_format> selection of Value and Default are
|* always mutually exclusive. Certain parameters may require
|* Value or Default, but Value and Default are not allowed to
|* be present together for the same parameter.
|* 5) <data_format> is always required for selections other
|* than Value.
|* 6) Default is optional for <data_format> Range, List, Corner,
|* Increment and Steps.
|* 7) Default is not allowed for <data_format> Table, Gaussian,
|* Dual-Dirac and DjRj.
|*
On pg. 144 remove the following lines:
| Init_Returns_Impulse, Use_Init_Output, GetWave_Exists,
| Max_Init_Aggressors and Ignore_Bits
On pg. 144 replace the following lines:
| The following reserved parameters are used by the EDA tool
| and are required if the [Algorithmic Model] keyword is
| present. The entries following the reserved parameters
| points to its usage, type and default value. All reserved
| parameters must be in the following format:
|
| (parameter_name (Usage <usage>)(Type <data_type>)
| (Default <values>) (Description <string>))
with these lines:
| The following reserved parameters are used by the EDA tool
| and are required if the [Algorithmic Model] keyword is
|* present. The entries following the reserved parameter
|* names determine their usage, type and value. Their value
|* may be defined using either Default or Value but not both.
|* Description is optional.
On pg. 145 remove the following lines:
| The following reserved parameter provides textual description
| to the user defined parameters.
On pg. 145 remove the following lines under Tx_Jitter and Tx_DCD:
... If specified, they must be in the following format:
|
| (<parameter_name> (Usage <usage>)(Type <data_type>)
| (Format <data format>) (Default <values>)
| (Description <string>))
On pg. 146 replace the following lines:
| (Tx_Jitter (Usage Info)(Type Float)
| (Format Gaussian <mean> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
| (Format Dual-Dirac <mean> <mean> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
| (Format DjRj <minDj> <maxDj> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
| (Format Table
| (Labels Row_No Time Probability)
| (-5 -5e-12 1e-10)
| (-4 -4e-12 3e-7)
| (-3 -3e-12 1e-4)
| (-2 -2e-12 1e-2)
| (-1 -1e-12 0.29)
| (0 0 0.4)
| (1 1e-12 0.29)
| (2 2e-12 1e-2)
| (3 3e-12 1e-4)
| (4 4e-12 3e-7)
| (5 5e-12 1e-10) ))
with these lines:
| (Tx_Jitter (Usage Info)(Type Float)
|* (Gaussian <mean> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
|* (Dual-Dirac <mean> <mean> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
|* (DjRj <minDj> <maxDj> <sigma>))
|
| (Tx_Jitter (Usage Info)(Type Float)
|* (Table
|* (Labels "Row_No" "Time" "Probability")
| (-5 -5e-12 1e-10)
| (-4 -4e-12 3e-7)
| (-3 -3e-12 1e-4)
| (-2 -2e-12 1e-2)
| (-1 -1e-12 0.29)
| (0 0 0.4)
| (1 1e-12 0.29)
| (2 2e-12 1e-2)
| (3 3e-12 1e-4)
| (4 4e-12 3e-7)
| (5 5e-12 1e-10) ))
|
|* Note: Since the rows of the Table are leaves, the first
|* column in the Table is considered a parameter name which is
|* a string. For this reason Type Float applies to the second
|* and all remaining columns of each row.
On pg. 146 replace the following lines:
| (Tx_DCD (Usage Info)(Type Float)
| (Format Range <typ> <min> <max>))
with these lines:
| (Tx_DCD (Usage Info)(Type Float)
|* (Range <typ> <min> <max>))
|
On pg. 146 remove the following lines under Rx_Clock_PDF and
Rx_Receiver_Sensitivity:
... If specified, they must be in the
| following format:
|
| (<parameter_name> (Usage <usage>)(Type <data_type>)
| (Format <data format>) (Default <values>)
| (Description <string>))
On pg. 147 replace the following lines:
| Rx_Receiver_Sensitivity:
|
| Rx_Receiver_Sensitivity can be of Usage Info and Out and of
| Type Float and of Data Format Value, Range and Corner.
| Rx_Receiver_Sensitivity tells the EDA platform the voltage
| needed at the receiver data decision point to ensure proper
| sampling of the equalized signal. In this example, 100 mV
| (above +100 mV or below -100 mV) is needed to ensure the
| signal is sampled correctly. Examples of Rx_Clock_PDF
| declarations are:
with these lines:
| Rx_Receiver_Sensitivity:
|
| Rx_Receiver_Sensitivity can be of Usage Info and Out and of
| Type Float and of Data Format Value, Range and Corner.
| Rx_Receiver_Sensitivity tells the EDA platform the voltage
| needed at the receiver data decision point to ensure proper
| sampling of the equalized signal. In this example, 100 mV
| (above +100 mV or below -100 mV) is needed to ensure the
|* signal is sampled correctly. Examples of
|* Rx_Receiver_Sensitivity declarations are:
On pg. 147 replace the following lines:
| (Rx_Clock_PDF (Usage Info)(Type Float)
| (Format Gaussian <mean> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
| (Format Dual-Dirac <mean> <mean> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
| (Format DjRj <minDj> <maxDj> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
| (Format Table
| (Labels Row_No Time Probability)
| (-5 -5e-12 1e-10)
| (-4 -4e-12 3e-7)
| (-3 -3e-12 1e-4)
| (-2 -2e-12 1e-2)
| (-1 -1e-12 0.29)
| (0 0 0.4)
| (1 1e-12 0.29)
| (2 2e-12 1e-2)
| (3 3e-12 1e-4)
| (4 4e-12 3e-7)
| (5 5e-12 1e-10) ))
with these lines:
| (Rx_Clock_PDF (Usage Info)(Type Float)
|* (Gaussian <mean> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
|* (Dual-Dirac <mean> <mean> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
|* (DjRj <minDj> <maxDj> <sigma>))
|
| (Rx_Clock_PDF (Usage Info)(Type Float)
|* (Table
|* (Labels "Row_No" "Time" "Probability")
| (-5 -5e-12 1e-10)
| (-4 -4e-12 3e-7)
| (-3 -3e-12 1e-4)
| (-2 -2e-12 1e-2)
| (-1 -1e-12 0.29)
| (0 0 0.4)
| (1 1e-12 0.29)
| (2 2e-12 1e-2)
| (3 3e-12 1e-4)
| (4 4e-12 3e-7)
| (5 5e-12 1e-10) ))
|
|* Note: Since the rows of the Table are leaves, the first
|* column in the Table is considered a parameter name which is
|* a string. For this reason Type Float applies to the second
|* and all remaining columns of each row.
On pg. 147 replace the following lines:
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
| (Format Value <value>))
|
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
| (Format Range <typ> <min> <max>))
|
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
| (Format Corner <slow> <fast>))
with these lines:
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
|* (Value <value>))
|
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
|* (Range <typ> <min> <max>))
|
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
|* (Corner <slow> <fast>))
On pg. 149 remove the following lines:
| The user defined parameters must be in the following format:
|
| (<parameter_name> (usage <usage>) (Type <data type>)
| (Format <data format>) (Default <values>)
| (Description <string>))
|
On pg. 150 replace the following lines:
(Model_Specific | Required heading
(txtaps
(-2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Precursor Tap"))
(-1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default 0.2)
(Description "First Precursor Tap"))
(0 (Usage Inout)(Type Tap) (Format Range 1 -1 2)(Default 1)
(Description "Main Tap"))
(1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default2 0.2)
(Description "First Post cursor Tap"))
(2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
(tx_freq_offset (Format Range 1 0 150) (Type UI) (Default 0))
) | End Model_Specific
) | End SampleAMI
with these lines:
(Model_Specific | Required heading
(txtaps
* (-2 (Usage Inout)(Type Tap) (Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Precursor Tap"))
* (-1 (Usage Inout)(Type Tap) (Range 0.2 -0.4 0.4)(Default 0.2)
(Description "First Precursor Tap"))
* (0 (Usage Inout)(Type Tap) (Range 1 -1 2)(Default 1)
(Description "Main Tap"))
* (1 (Usage Inout)(Type Tap) (Range 0.2 -0.4 0.4)(Default2 0.2)
(Description "First Post cursor Tap"))
* (2 (Usage Inout)(Type Tap) (Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
* (tx_freq_offset (Range 1 0 150) (Type UI) (Default 0))
) | End Model_Specific
) | End SampleAMI
*****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
Careful reading of the specification revealed that these items are
misleading and/or redundant. The proposed changes take into account
the removal of the Use_Init_Output Boolean in the proposed reference
flow.
*****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
Reminders to editorial committee:
Make sure "data format" is spelled consistently as "Data Format" or
"data_format" or "Data_Format" or what have you...
Fix Table 1 and 3
- NA in Table 1
What does "Ambiguity about the relationship between 'Format' and text
strings" refer to?
*****************************************************************************
Other related posts:
