[ibis-macro] FW: Re: The two BIRDs and the updated Task List are posted on the ATM web site
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 13 Apr 2010 09:32:42 -0700
For those who are unable to join the meeting via
LiveMeeting, here is the latest version of the
clock_times BIRD draft from Scott. This is the
version we will discuss in today's IBIS-ATM
teleconference.
Arpad
==================================================
________________________________
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Tuesday, April 13, 2010 11:21 AM
To: Muranyi, Arpad
Subject: Re: [ibis-macro] Re: The two BIRDs and the updated Task List
are posted on the ATM web site
sure, but 7 is the only one posted on the website
Muranyi, Arpad wrote:
Thanks, but this should be #9... Could you
please rename it on your end, so we would be
in synch?
Thanks,
Arpad
=============================================
-----Original Message-----
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Tuesday, April 13, 2010 8:36 AM
To: Muranyi, Arpad
Subject: Re: [ibis-macro] Re: The two BIRDs and the updated Task
List
are posted on the ATM web site
Arpad
A newer edited version of the bird
Muranyi, Arpad wrote:
Ken,
Thank you for your feedback on the "Flow BIRD".
As I stated in the last ATM teleconference, I was
debating the
question myself whether "Init_Returns_Filter" is a new
feature
or a correction to the existing feature in the IBIS v5.0
spec.
The position I took is that this is still a correction,
because
without it, deconvolution would be necessary to
accomplish some
of the calculations in the corrected flow, and as we all
know,
deconvolution is numerically unstable operation which
may result
in bad waveforms. Providing a numerically stable
alternative is
a correction in my mind. I agree, "Init_Returns_Filter"
is a new
keyword, but it doesn't accomplish anything new, it is
only there
to help accomplish what the intended flow was in the
first place.
However, your suggestion of further simplifying the flow
in the
spec seems to be more of a NEW FEATURE type change,
since your
suggestions are making significant changes to the
existing flow.
The reasons behind these changes seem to be different
from making
a correction to a flaw.
Either way, we can certainly discuss this topic in the
meeting
tomorrow and see how everyone else feels about them, but
I have
to express my serious concern that by reopening this
topic we
are putting about three months worth of hard work in
jeopardy.
Everyone seemed to be in an agreement last fall, and I
don't
see any reason for having to go back and start the
discussions
on this topic all over again. My goal with this BIRD
draft and
the call for a vote on it tomorrow is to formalize what
we have
done last fall (so that we can claim the we have a
process) and
not to start everything all over again from scratch.
Thanks,
Arpad
==================================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
Ken Willis
Sent: Monday, April 12, 2010 10:28 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: The two BIRDs and the updated
Task List are
posted on the ATM web site
Hello all,
Some feedback on the provided documents; regarding the
"Flow_BIRD",
the
clarification of the flow with respect to AMI_Getwave in
the TX is an
excellent addition. This was much needed.
But Sigrity strongly disagrees with some other aspects
of the
"Flow_BIRD".
Quoting Arpad's presentation from March 30th, "The
process and goal of
the
AMI BIRD", the "Conclusion" slide states very clearly
"Adopt a
minimalistic
approach" and "make a checklist with the absolutely
necessary
changes".
This
intimates:
- Focus first on clean up and clarification of existing
functionality
- Focus second on new functionality, and put them in
their own,
subsequent
BIRDs
Unfortunately, this concept is violated with this
"Init_Returns_Filter"
addition. This is NEW functionality, and does NOT belong
in a
clarification
BIRD. It should be in its own BIRD, once the
clarification of the
existing
flow is in place. I thought that was the approach that
was generally
agreed
upon by the group. Trying to add new functionality at
the same time as
clarifying the existing flow makes things much more
complex. Looking
at
the
multiple "If/Then" scenarios in Step 8 of the proposed
reference flow
illustrates this. "Init_Return_Filter" complicates the
reference flow
significantly.
In fact, a counterproposal Sigrity would like the
members to consider
is
that we further simplify the current 5.0 flow so that a
given AMI
model
should be allowed to EITHER:
- pass back a modified impulse response
(Init_Returns_Impulse); or
- pass back modified waveforms (Getwave_Exists)
but NOT both. That would really make it much more
straightforward, for
both
the model developer, and the EDA tools. The filtering
functionality in
a
Serdes will either require detailed waveform processing
or not. If it
does,
and AMI_Getwave is used, then in practicality it should
not need to
also
return impulse responses, filters, or anything else.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
Muranyi, Arpad
Sent: Friday, April 09, 2010 3:19 PM
To: IBIS-ATM
Subject: [ibis-macro] The two BIRDs and the updated Task
List are
posted
on
the ATM web site
Hello everyone,
Just in time for the weekend...
The two BIRD drafts and the updated Task List we
discussed
in the last ATM teleconference are posted on the
IBIS-ATM
web site:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100406/arpadmurany
i/AMI_Flow_BIRD_draft.zip
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100406/scottmcmorr
ow/clock_times_BIRD_draft.zip
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100406/arpadmurany
i/IBIS%20AMI%20BIRD%20Task%20List/IBIS50AMI_TaskList_2010_04_06.pdf
I am hoping to vote on the Flow BIRD in the upcoming
meeting,
since this is the flow we discussed in the fall of 2009
and
we seemed to have an agreement on it then.
I would like to have a meaningful discussion on the
clock_times BIRD in the next meeting to address any
questions and comments, and hope to put it up for vote
for the following week's meeting.
I would also like to spend a few minutes in each meeting
on the Task List to make sure we don't miss anything,
and to know what BIRDs we still need to write.
The text of the two BIRDs are included in the body of
this
message and the PDF and TXT files are also attached with
this message. Hopefully you will be able to read them
one way or another...
Thanks, and have a nice weekend.
Arpad
************************************************************************
*****
************************************************************************
*****
BIRD ID#:
ISSUE TITLE: IBIS-AMI Flow Correction
REQUESTER: Arpad Muranyi, Mentor Graphics, Inc.
DATE SUBMITTED:
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
************************************************************************
*****
************************************************************************
*****
STATEMENT OF THE ISSUE:
In Section 10, "NOTES ON ALGORITHMIC MODELING INTERFACE
AND
PROGRAMMING
GUIDE", sub-section 2 describes a flawed reference flow.
The intent
was
to make non-LTI simulations possible using the GetWave
functions of
AMI
models, however the order of Step 4 and Step 5, as
described in the
IBIS
v5.0 specification will only work properly with LTI
GetWave functions.
************************************************************************
*****
Replace this text:
| 2 APPLICATION SCENARIOS
| =======================
|
|
| 2.1 Linear, Time-invariant Equalization Model
| =============================================
|
| 1. From the system netlist, the EDA platform
determines that a
given
| [Model] is described by an IBIS file.
|
| 2. From the IBIS file, the EDA platform determines
that the
[Model]
is
| described at least in part by an algorithmic
model, and that
the
| AMI_Init function of that model returns an
impulse response for
that
| [Model].
|
| 3. The EDA platform loads the shared library
containing the
algorithmic
| model, and obtains the addresses of the AMI_Init,
AMI_GetWave,
and
| AMI_Close functions.
|
| 4. The EDA platform assembles the arguments for
AMI_Init. These
arguments
| include the impulse response of the channel
driving the
[Model],
a
| handle for the dynamic memory used by the
[Model], the
parameters
for
| configuring the [Model], and optionally the
impulse responses
of
any
| crosstalk interferers.
|
| 5. The EDA platform calls AMI_Init with the
arguments previously
prepared.
|
| 6. AMI_Init parses the configuration parameters,
allocates dynamic
| memory, places the address of the start of the
dynamic memory
in
| the memory handle, computes the impulse response
of the block
and
| passes the modified impulse response to the EDA
tool. The new
| impulse response is expected to represent the
filtered
response.
|
| 7. The EDA platform completes the rest of the
simulation/analysis
using
| the impulse response from AMI_Init as a complete
representation
of the
| behavior of the given [Model].
|
| 8. Before exiting, the EDA platform calls AMI_Close,
giving it the
address
| in the memory handle for the [Model].
|
| 9. AMI_Close de-allocates the dynamic memory for the
block and
performs
| whatever other clean-up actions are required.
|
| 10. The EDA platform terminates execution.
|
|
| 2.2 Nonlinear, and / or Time-variant Equalization
Model
|
=======================================================
|
| 1. From the system netlist, the EDA platform
determines that a
given
block
| is described by an IBIS file.
|
| 2. From the IBIS file, the EDA platform determines
that the block
is
| described at least in part by an algorithmic
model.
|
| 3. The EDA platform loads the shared library or
shared object file
| containing the algorithmic model, and obtains the
addresses of
the
| AMI_Init, AMI_GetWave, and AMI_Close functions.
|
| 4. The EDA platform assembles the arguments for
AMI_Init. These
arguments
| include the impulse response of the channel
driving the block, a
handle
| for the dynamic memory used by the block, the
parameters for
| configuring the block, and optionally the impulse
responses of
any
| crosstalk interferers.
|
| 5. The EDA platform calls AMI_Init with the arguments
previously
prepared.
|
| 6. AMI_Init parses the configuration parameters,
allocates dynamic
| memory and places the address of the start of the
dynamic memory
in
| the memory handle. AMI_Init may also compute the
impulse
response
| of the block and pass the modified impulse
response to the EDA
tool.
| The new impulse response is expected to represent
the filtered
| response.
|
| 7. A long time simulation may be broken up into
multiple time
segments.
| For each time segment, the EDA platform computes
the input
waveform to
| the [Model] for that time segment. For example,
if a million
bits
are
| to be run, there can be 1000 segments of 1000 bits
each, i.e.
one
time
| segment comprises 1000 bits.
|
| 8. For each time segment, the EDA platform calls the
AMI_GetWave
function,
| giving it the input waveform and the address in
the dynamic
memory
| handle for the block.
|
| 9. The AMI_GetWave function computes the output
waveform for the
block. In
| the case of a transmitter, this is the Input
voltage to the
receiver.
| In the case of the receiver, this is the voltage
waveform at the
| decision point of the receiver.
|
| 10. The EDA platform uses the output of the receiver
AMI_GetWave
function
| to complete the simulation/analysis.
|
| 11. Before exiting, the EDA platform calls AMI_Close,
giving it the
address
| in the memory handle for the block.
|
| 12. AMI_Close de-allocates the dynamic memory for the
block and
performs
| whatever other clean-up actions are required.
|
| 13. The EDA platform terminates execution.
|
|
| 2.3 Reference system analysis flow
| ==================================
|
| System simulations will commonly involve both TX and
RX algorithmic
| models, each of which may perform filtering in the
AMI_Init call,
the
| AMI_Getwave call, or both. Since both LTI and
non-LTI behavior can
be
| modeled with algorithmic models, the manner in which
models are
| evaluated can affect simulation results. The
following steps are
| defined as the reference simulation flow. Other
methods of calling
| models and processing results may be employed, but
the final
simulation
| waveforms are expected to match the waveforms
produced by the
reference
| simulation flow.
|
| The steps in this flow are chained, with the input to
each step
being
| the output of the step that preceded it.
|
| Step 1. The simulation platform obtains the impulse
response for
the
| analog channel. This represents the combined
impulse
response
| of the transmitter's analog output, the
channel and the
| receiver's analog front end. This impulse
response
represents
| the transmitter's output characteristics
without filtering,
for
| example, equalization.
|
| Step 2. The output of Step 1 is presented to the TX
model's
AMI_Init
| call. If Use_Init_Output for the TX model is
set to True,
the
| impulse response returned by the TX AMI_Init
call is passed
| onto Step 3. If Use_Init_Output for the TX
model is set to
| False, the same impulse response passed into
Step 2 is
passed
| on to step 3.
|
| Step 3. The output of Step 2 is presented to the RX
model's
AMI_Init
| call. If Use_Init_Output for the RX model is
set to True,
the
| impulse response returned by the RX AMI_Init
call is passed
| onto Step 4. If Use_Init_Output for the RX
model is set to
| False, the same impulse response passed into
Step 3 is
passed
| on to step 4.
|
| Step 4. The simulation platform takes the output of
step 3 and
combines
| (for example by convolution) the input
bitstream and a unit
| pulse to produce an analog waveform.
|
| Step 5. The output of step 4 is presented to the TX
model's
AMI_Getwave
| call. If the TX model does not include an
AMI_Getwave
call,
| this step is a pass-through step, and the
input to step 5
is
| passed directly to step 6.
|
| Step 6. The output of step 5 is presented to the RX
model's
AMI_Getwave
| call. If the RX model does not include an
AMI_Getwave
call,
| this step is a pass-through step, and the
input to step 6
is
| passed directly to step 7.
|
| Step 7. The output of step 6 becomes the simulation
waveform output
at
| the RX decision point, which may be
post-processed by the
| simulation tool.
|
| Steps 4 though 7 can be called once or can be called
multiple times
to
| process the full analog waveform. Splitting up the
full analog
waveform
| into mulitple calls minimized the memory requirement
when doing
long
| simulations, and allows AMI_Getwave to return model
status every so
many
| bits. Once all blocks of the input waveform have
been processed,
TX
| AMI_Close and RX AMI_close are called to perform any
final
processing
| and release allocated memory.
----------------------------------------
with the following text:
(Due to the high percentage of modified or new text, the
changes are
not
marked by the usual "*" characters at the beginning of
each line).
| 2 APPLICATION SCENARIOS
| =======================
|
|
| 2.1 Linear, Time-invariant Equalization Model
| =============================================
|
| 1. From the system netlist, the EDA platform
determines that a
given
| [Model] is described by an IBIS file.
|
| 2. From the IBIS file, the EDA platform determines
that the
[Model]
is
| described at least in part by an algorithmic
model.
|
| 3. The EDA platform loads the shared library or
shared object file
| containing the algorithmic model, and obtains the
addresses of
the
| AMI_Init, AMI_GetWave, and AMI_Close functions.
|
| 4. The EDA platform assembles the arguments for
AMI_Init. These
| arguments include the impulse response of the
channel driving
the
| block, a handle for the dynamic memory used by
the block, the
| parameters for configuring the block, and
optionally the
impulse
| responses of any crosstalk interferers.
|
| 5. The EDA platform calls AMI_Init with the
arguments previously
| prepared.
|
| 6. AMI_Init parses the configuration parameters,
allocates dynamic
| memory, places the address of the start of the
dynamic memory
in
the
| memory handle. Depending on the value of
Init_Returns_Filter,
it
| either computes and returns the filter response
of the block,
or
| computes the impulse response of the channel
modified by the
filter
| response of the block.
|
| 7. The EDA platform completes the rest of the
simulation/analysis
using
| the impulse response from AMI_Init as a complete
representation
of
| the behavior of the given block combined with the
channel, or
makes
| use of the filter response returned by AMI_Init
to compute the
| behavior of the given block combined with the
channel.
|
| 8. Before exiting, the EDA platform calls AMI_Close,
giving it the
| address in the memory handle for the block.
|
| 9. AMI_Close de-allocates the dynamic memory for the
block and
performs
| whatever other clean-up actions are required.
|
| 10. The EDA platform terminates execution.
|
|
| 2.2 Nonlinear, and / or Time-variant Equalization
Model
|
=======================================================
|
| 1. From the system netlist, the EDA platform
determines that a
given
| block is described by an IBIS file.
|
| 2. From the IBIS file, the EDA platform determines
that the block
is
| described at least in part by an algorithmic
model.
|
| 3. The EDA platform loads the shared library or
shared object file
| containing the algorithmic model, and obtains the
addresses of
the
| AMI_Init, AMI_GetWave, and AMI_Close functions.
|
| 4. The EDA platform assembles the arguments for
AMI_Init. These
| arguments include the impulse response of the
channel driving
the
| block, a handle for the dynamic memory used by
the block, the
| parameters for configuring the block, and
optionally the
impulse
| responses of any crosstalk interferers.
|
| 5. The EDA platform calls AMI_Init with the
arguments previously
| prepared.
|
| 6. AMI_Init parses the configuration parameters,
allocates dynamic
| memory and places the address of the start of the
dynamic
memory
in
| the memory handle. Depending on the value of
Init_Returns_Filter,
| it either computes and returns the filter
response of the
block,
or
| computes the impulse response of the channel
modified by the
filter
| response of the block. The EDA platform may make
use of the
| impulse response or the filter response returned
by AMI_Init in
its
| further analysis if needed.
|
| 7. The EDA platform generates a time domain input
waveform
(stimulus)
| bit pattern. A long simulation may be broken up
into multiple
time
| segments by the EDA platform. For example, if a
million bits
are
| to be simulated, there can be 1000 segments of
1000 bits each,
i.e.
| one time segment comprises 1000 bits.
|
| 8. For each time segment, the EDA platform calls the
transmitter
| AMI_GetWave function, giving it the input
waveform and the
address
| in the dynamic memory handle for the block.
|
| 9. Depending on the value stored in the
Use_Init_Output
parameters,
| the EDA platform combines the output of the
transmitter
AMI_GetWave
| function with the output(s) of the AMI_Init
function(s) with
the
| impulse response of the channel and passes this
result to the
| receiver AMI_GetWave function for each time
segment of the
| simulation.
|
| 10. The output waveform of the receiver GetWave
function represents
the
| voltage waveform at the decision point of the
receiver. The
EDA
| platform uses this waveform to complete the
simulation/analysis.
|
| 11. Before exiting, the EDA platform calls AMI_Close,
giving it the
| address in the memory handle for the block.
|
| 12. AMI_Close de-allocates the dynamic memory for the
block and
performs
| whatever other clean-up actions are required.
|
| 13. The EDA platform terminates execution.
|
|
| 2.3 Reference system analysis flow
| ==================================
|
| System simulations will commonly involve both TX and
RX algorithmic
| models, each of which may perform filtering in the
AMI_Init call,
the
| AMI_Getwave call, or both. Since both LTI and non-LTI
behavior can
be
| modeled with algorithmic models, the manner in which
models are
evaluated
| can affect simulation results. The following steps
are defined as
the
| reference simulation flow. Other methods of calling
models and
| processing results may be employed, but the final
simulation
waveforms
| are expected to match the waveforms produced by the
reference
simulation
| flow.
|
|
| Step 1. The simulation platform obtains the impulse
response for
the
| analog channel. This represents the combined
impulse
response
| of the transmitter's analog output, the
channel and the
| receiver's analog front end. This impulse
response
represents
| the transmitter's output characteristics
without filtering,
for
| example, equalization.
|
| Step 2. The output of Step 1 is presented to the TX
model's
AMI_Init
| call. If Init_Returns_Filter for the TX
model is set to
True,
| the model returns the impulse response of the
TX filter.
If
it
| is set to False, the TX AMI_Init call returns
the modified
| impulse response of the channel. The output
of TX AMI_Init
is
| returned to the EDA tool which decides how to
make use of
it
| depending on the transmitter's
Init_Returns_Filter and
| Use_Init_Output parameters.
|
| Step 3. If the transmitter's Init_Returns_Filter
parameter is set
to
| False, the output of Step 2 is presented to
the RX model's
| AMI_Init call. If the Init_Returns_Filter is
set to True,
the
| EDA tool will combine the output of Step 2
with the output
of
| Step 1 (for example by convolution) before
presenting it to
the
| RX model's AMI_Init call.
|
| Step 4. The output of Step 3 is presented to the RX
model's
AMI_Init
| call. If Init_Returns_Filter for the RX
model is set to
True,
| the model returns the impulse response of the
RX filter.
If
it
| is set to False, the RX AMI_Init call returns
the filtered
| response of the channel. The output of RX
AMI_Init is
returned
| to the EDA tool which decides how to make use
of it
depending
| on the receiver's Init_Returns_Filter and
Use_Init_Output
| parameters.
|
| Step 5. If the receiver's Init_Returns_Filter
parameter is set to
| False, the output of Step 4 may be presented
to the user of
the
| EDA tool, or the EDA tool can further process
the results
using
| statistical algorithms. If the
Init_Returns_Filter is set
to
| True, the EDA tool will combine the output of
Step 4 with
the
| output of Step 3 (for example by convolution)
before
presenting
| it to the user of the EDA tool, or before
continuing with
the
| statistical processing of these results.
|
| Step 6. The simulation platform produces a digital
stimulus
waveform.
A
| digital stimulus waveform is 0.5 when the
stimulus is
"high",
| -0.5 when the stimulus is "low", and may have
a value
between
| -0.5 and 0.5 such that transitions occur when
the stimulus
| crosses 0.
|
| Step 7. The output of step 6 is presented to the TX
model's
AMI_Getwave
| call. If the TX model does not include an
AMI_Getwave
call,
| this step is a pass-through step, and the
input to step 7
is
| passed directly to step 8.
|
| Step 8. The EDA simulation platform combines (for
example by
| convolution) the output of step 7 with the
output of
several
| different previous steps depending on the
value of the
| transmitter's and receiver's
Init_Returns_Filter and
| Use_Init_Output settings as follows:
|
| If TX Use_Init_Output = False, combine the
outputs of Step
7
| and Step 1.
|
| If TX Use_Init_Output = True and TX
Retuns_Filter = False,
| combine the outputs of Step 7 and Step 2.
|
| If TX Use_Init_Output = True and TX
Retuns_Filter = True,
| combine the outputs of Step 7, Step 1 and
Step 2.
|
| In addition, the EDA simulation platform will
also combine
the
| output of Step 4 with the above if RX
Use_Init_Output =
True.
| When RX Init_Returns_Filter = True, this is a
relatively
straight
| forward operation, but when RX
Init_Returns_Filter = False,
the
| EDA simulation platform will have to take
additional steps
to
| prevent the duplication of the content that
is present in
the
| output of Steps 2 and/or 3 (for example by
deconvolution).
This
| is why RX Init_Returns_Filter = True is
preferred when RX
| Use_Init_Output = True.
|
| Step 9. The output of step 8 is presented to the RX
model's
AMI_Getwave
| call. If the RX model does not include an
AMI_Getwave
call,
| this step is a pass-through step, and the
input to step 9
is
| passed directly to step 10.
|
| Step 10. The output of step 9 becomes the simulation
waveform output
at
| the RX decision point, which may be
post-processed by the
| simulation tool or presented to the user as
is.
|
| Steps 6 though 9 can be called once or can be called
multiple times
to
| process the full analog waveform. Splitting up the
full analog
waveform
| into multiple calls reduces the memory requirements
when doing long
| simulations, and allows AMI_Getwave to return model
status every so
many
| bits. Once all blocks of the input waveform have been
processed, TX
| AMI_Close and RX AMI_close are called to perform any
final
processing
and
| release allocated memory.
************************************************************************
*****
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
The IBIS-ATM Task Group spent several meetings to
discuss the AMI flow
problem and the best solution for it in the months of
September,
October
and November of 2009. The IBIS-ATM Task Group arrived
to the final
version
of the proposed flow on November 17, 2009.
A graphical representation of the flow that is in
described in the
IBIS
v5.0 specification can be found on the first page of the
following
presentation:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20090921/arpadmurany
i/AMI%20flows:%20IBIS%205.0%20and%202009%20Sept%208,15%20proposals/AMI_F
lows.pdf
The yellow highligted symbols on the second page
indicate what the
order
should have been to achieve the goal of simulating
non-LTI sysmtems
with
the GetWave functions.
The ATM Task Group also discovered during the
discussions that certain
conditions would require a deconvolution operation which
is known to
be
a challange due to its numerical instability. To remedy
this
oversight,
a new Boolean parameter "Init_Returns_Filter" was also
introduced in
the
proposed flow to provide a mechanizm to eliminate the
need for using
deconvolution in the flow.
The graphical representation of the new proposed flow
can be found in
the following presentation:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20091118/arpadmurany
i/Final%20AMI%20flow%20for%20IBIS%205.1/AMI_Flows_5_final.pdf
************************************************************************
*****
ANY OTHER BACKGROUND INFORMATION:
************************************************************************
*****
************************************************************************
*****
************************************************************************
*****
BIRD ID#:
ISSUE TITLE: IBIS-AMI clock_times Clarification
REQUESTER: Scott McMorrow, Teraspeed Consulting
Group
DATE SUBMITTED:
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
************************************************************************
*****
************************************************************************
*****
STATEMENT OF THE ISSUE:
In the Section, "NOTES ON ALGORITHMIC MODELING INTERFACE
AND
PROGRAMMING
GUIDE", the paragraph describing clock_times has led to
inconsistent
and
incorrect model implementation.
The suggestion is to clarify usage of the parameter
consistent with
the
original intent.
************************************************************************
*****
Replace this text:
|
| 3.2.2.3 clock_times
| ===================
|
| Vector to return clock times. The clock times are
referenced to the
start
| of the simulation (the first AMI_GetWave call). The
time is always
| greater or equal to zero. The last clock is indicated
by putting a
value
| of -1 at the end of clocks for the current wave
sample. The
clock_time
| vector is allocated by the EDA platform and is
guaranteed to be
greater
| than the number of clocks expected during the
AMI_GetWave call. The
clock
| times are the times at which clock signal at the
output of the clock
| recovery loop crosses the logic threshold. It is to
be assumed that
the
| input data signal is sampled at exactly one half clock
period after
a
| clock time.
|
--------------
With the following text with changes noted by "|*"
lines:
|
| 3.2.2.3 clock_times
| ===================
|
| Vector to return clock times. The clock times are
referenced to the
start
| of the simulation (the first AMI_GetWave call). The
time is always
|* greater or equal to zero. The clock_time
|* vector is allocated by the EDA platform and is
guaranteed to be
greater
|* than the number of clocks expected during the
AMI_GetWave call.
The
clock
|* times are the times at which the clock signal at the
output of the
clock
|* recovery loop crosses the logic threshold in a full
data rate CDR
clocking
|* system (i.e clock period equals UI). The effective
receiver
sampling
|* point is equal to the clock_times plus 1/2 the
nominal UI period.
The
last
|* valid clock of the current GetWave call is indicated
|* by placing -1 after the last valid clock in the
clock_time vector.
|*
|* The clock ticks represented by clock times should be
strictly
monotonic,
|* both within the clock_times array returned from a
single call to
GetWave
|* and between successive calls to GetWave. That is,
within a given
clock_times
|* array each successive valid value is greater than the
value that
preceded it,
|* and the first valid value from a given call to
GetWave must be
greater than
|* the last valid value from the preceding call to
GetWave.Any
non-strict-monotonic
|* behavior of clock times (including two identical
values) should be
considered
|* by EDA platform as a DLL failure and should lead to
simulation
termination
|* with respective message.
|*
|* Each valid pair of values in the clock_times array
shall be used to
sample the output
|* waveform as previously described, regardless whether
that waveform
sample occurs
|* in the waveform segment being returned by the current
call to
GetWave, or the
|* waveform segment to be returned by the next GetWave
call.
|*
|* Although clock_times will generally be related to the
UI interval
for
the
|* primary SerDes channel being simulated, there is no
requirement
that
there is
|* any relationship between the clock ticks generated by
clock_times
and
the actual
|* waveform returned in the primary channel. It is
possible for the
CDR
to go out
|* of lock, resulting in clock_ticks that have no
definite
relationship
to the output
|* wave.
|*
|* There is no requirement that clock times should be
integer
multiples
of the
|* sample interval (or time step used to represent the
waveforms).There
is also
|* no requirement that there be a relationship between
clock_times in
the
|* primary channel, and any additional waveform
components in the wave
vector, such
|* as crosstalk. Crosstalk channels shall not be
constrained to any
timing
|* relationship to the primary channel, or to the
clock_times vector.
|
************************************************************************
*****
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
Additional notes regarding correct clock_times usage
have been
included
as part
of this BIRD, distilled from discussions on the
ibis-macro reflector.
Additional notes regarding clock_times
* Internal to a device, the sampling time tick
"sees" the part of
the waveform
that immediately precedes and follows that tick,
within some
sampling uncertainty window.
* That point, is the true center of the eye for that
interval.
* The AMI spec requires the clock tick to be placed
1/2 UI before
the actual
sample point, essentially at the differential
crossing.
* Then it requires the EDA tool to shift the tick by
1/2 UI.
o the assumption here is that there is always
a fixed
relationship to the UI.
o Thus the DLL must calculate the sampling
point, then move
it
back by 1/2 UI
to create a clock tick that can then be
moved back by the
EDA platform to
the same sampling point that it first
calculated.
* It is therefore a requirement that the DLL move
the sample point
back by 1/2 the
nominal UI, and not the instantaneous UI,
otherwise there will
be
inadvertent
jitter in the clock_times.
* Clock_times + 1/2 nominal UI is always the center
of every eye
interval.
************************************************************************
*****
ANY OTHER BACKGROUND INFORMATION:
This is an editorial correction to clarify the usage of
clock_times.
************************************************************************
*****
---------------------------------------------------------------------
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
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed(r) is the registered service mark of
Teraspeed Consulting Group LLC
****************************************************************************
*****************************************************************************
BIRD ID#:
ISSUE TITLE: IBIS-AMI clock_times Clarification
REQUESTER: Scott McMorrow, Teraspeed Consulting Group
DATE SUBMITTED:
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
*****************************************************************************
*****************************************************************************
STATEMENT OF THE ISSUE:
In the Section, "NOTES ON ALGORITHMIC MODELING INTERFACE AND PROGRAMMING
GUIDE", the paragraph describing clock_times has led to inconsistent and
incorrect model implementation.
The suggestion is to clarify usage of the parameter consistent with the
original intent.
*****************************************************************************
Replace this text:
|
| 3.2.2.3 clock_times
| ===================
|
| Vector to return clock times. The clock times are referenced to the start
| of the simulation (the first AMI_GetWave call). The time is always
| greater or equal to zero. The last clock is indicated by putting a value
| of -1 at the end of clocks for the current wave sample. The clock_time
| vector is allocated by the EDA platform and is guaranteed to be greater
| than the number of clocks expected during the AMI_GetWave call. The clock
| times are the times at which clock signal at the output of the clock
| recovery loop crosses the logic threshold. It is to be assumed that the
| input data signal is sampled at exactly one half clock period after a
| clock time.
|
--------------
With the following text with changes noted by "|*" lines:
|
| 3.2.2.3 clock_times
| ===================
|
| Vector to return clock times. The clock times are referenced to the start
| of the simulation (the first AMI_GetWave call). The time is always
|* greater or equal to zero. The clock_time
|* vector is allocated by the EDA platform and is guaranteed to be greater
|* than the number of clocks expected during the AMI_GetWave call. The clock
|* times are the times at which the clock signal at the output of the clock
|* recovery loop crosses the logic threshold in a full data rate CDR clocking
|* system (i.e clock period equals UI). The effective receiver sampling
|* point is equal to the clock_times plus 1/2 the instantaneous UI period,
|* which is the midpoint of two adjacent clock ticks. The last
|* valid clock of the current GetWave call is indicated
|* by placing -1 after the last valid clock in the clock_time vector.
|*
|* The clock ticks represented by clock times should be strictly monotonic,
|* both within the clock_times array returned from a single call to GetWave
|* and between successive calls to GetWave. That is, within a given clock_times
|* array each successive valid value is greater than the value that preceded
it,
|* and the first valid value from a given call to GetWave must be greater than
|* the last valid value from the preceding call to GetWave.Any
non-strict-monotonic
|* behavior of clock times (including two identical values) should be
considered
|* by EDA platform as a DLL failure and should lead to simulation termination
|* with respective message.
|*
|* Each valid pair of values in the clock_times array shall be used to sample
the output
|* waveform as previously described, regardless whether that waveform sample
occurs
|* in the waveform segment being returned by the current call to GetWave, or
the
|* waveform segment to be returned by the next GetWave call. Care should be
taken
|* in implementation of clock_times to insure that the calculations used always
maintain
|* full double-precision floating point accuracy across multi-million bit
simulations.
|*
|* Although clock_times will generally be related to the UI interval for the
|* primary SerDes channel being simulated, there is no requirement that there is
|* any relationship between the clock ticks generated by clock_times and the
actual
|* waveform returned in the primary channel. It is possible for the CDR to go
out
|* of lock, resulting in clock_ticks that have no definite relationship to the
output
|* wave.
|*
|* There is no requirement that clock times should be integer multiples of the
|* sample interval (or time step used to represent the waveforms).There is also
|* no requirement that there be a relationship between clock_times in the
|* primary channel, and any additional waveform components in the wave vector,
such
|* as crosstalk. Crosstalk channels shall not be constrained to any timing
|* relationship to the primary channel, or to the clock_times vector.
|
*****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
Additional notes regarding correct clock_times usage have been included as part
of this BIRD, distilled from discussions on the ibis-macro reflector.
Additional notes regarding clock_times
* The previous specification was vague with respect to the meaning of one
half clock
period. As a result, implementations have interpreted this as being one
half
of a Unit Interval (UI), which is erronious.In reality, the CDR clock is
generally used to recover a stable clock from the data stream and use
that
as the basis for sampling (latching) the incoming waveform. Since the
CDR
locks on differential crossings at the edge of an eye, the sampler in a
full
rate CDR architecture uses the opposite edge of the recovered clock to
generate
the sample point. In a locked system under steady state conditions, the
mean
of the clock period is also the nominal period (UI) of the data stream.
However,
even under steady state conditions, random fluctuations in the CDR loop
will
cause clock deviation that can be seen as jitter, along with a
subsequent shift
in sample point. Under these conditions, the clock period (and sample
point)
will vary over time. The instantaneous clock period can be
significantly less
than or greater than the nominal period.
* The current specification of clock times, and any implementations
flowing from this, are technically wrong, resulting in a difference
between the actual sample point in a receiver, and the calculated sample
point. Our first order calculations at Teraspeed consulting indicate
that this is at the minimum an error of ± 5% of a nominal UI.
Depending on the CDR, and the way it responds to stressful data
patterns, this can be larger. For any particular time slice, this means
that the center of the eye for a given single bit of data can be
incorrect if the nominal UI is used for calculation of the receiver
sample point, causing a skew in any derived statistics.
*****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
This is an editorial correction to clarify the usage of clock_times.
*****************************************************************************
Other related posts:
- » [ibis-macro] FW: Re: The two BIRDs and the updated Task List are posted on the ATM web site - Muranyi, Arpad
