[ibis-macro] clock_times .... yet again
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 13 Apr 2010 20:07:55 -0400
Fellow AMI travelers
In the specification for clock_times is the statement:
"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.*"
According to the discussion today, it has been agreed that all known
implementations of AMI dlls calculate the correct sample time and then
calculate clock_times as sample_times minus 1/2 the nominal clock
period. If this is truly the case, then there is a problem.
During startup the CDR is free-running, with no defined phase
relationship to the received data. In order to model this, the
period of the CDR would be set to it's free-running period, and the
phase of the CDR would need to be randomly initialized at INIT. The
location of the receiver sample point is then random within the
first UI data window, as it is in reality. No matter what the Tx
does, there will generally be a free-running sample occuring with no
phase relationship to anything, until the first received
differential transition occurs. If the first value of clock_times
is calculated as receiver sample time minus 1/2 the nominal clock
period, then clock_times can take any value from -0.5 UI to +0.5 UI.
The specification should be clarified to state that:
The clock times are referenced to the start of the simulation (the
first AMI_GetWave call). *The time is always
greater or equal to -0.5 nominal clock periods or symbol UI.*"
best regards,
Scott
--
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® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
