Re: XAUI Jitter Telco Protocol 14th Febuary 2001

["Tom Lindsay" <Tom.Lindsay@xxxxxxxxx>]

Anthony -

I just posted a response to the section 6.5.1 issue. I hope that gets more discussion going.

On the section 2.5.4 issue, I think you are on the right track by using the compliance channel, but more is required.

The Rx compliance eye should consider jitter, rise/fall times, and amplitude. The compliance channel contributes effects to all three terms, but does not define them completely.

• Jitter input should be consistent with the jitter budget and the sine jitter template. That is, some RJ and additional DJ may be required.
• Amplitude should be consistent with the Rx sensitivity specs (I assume at the center of the eye from the innermost traces). That is, some additional attenuation or source amplitude control may be required.
• Rise/fall times should be dominated by the channel model, but a little more slowing may be required - I don't expect that even worst case rise/fall times from the source make much difference.

Thanks, Tom Lindsay
Vixel
425/806-4074

Anthony Sanders wrote:

Please find attached

1) Protocol from XAUI Jitter Telco, 14th Febuary 2001
2) Updated Jitter Issue List

Please pay attention to two important items, which I would like to get
feedback concerning these item on the reflector asap.

Section 2.5.4; Compliance Receive Eye. My proposal is that we shall not
define a compliance eye directly for receiver tolerance testing, but
only the necessity of including a filter (equal to the polynomial of the
compliance channel), to limit the edge speed.

Section 6.5.1; Use of CJPAT for compliance testing of receiever and
transmitter.
                Does this requirement create too much restriction on the implementor
and testor?
                Is this requirement necessary to guarentee interopability between
devices?
                Is the current jitter specification correct, for CJPAT or K28.5
compliance testing.

Next telco, as always Wednesday, 10:30 (PST)

Best regards,

Anthony Sanders
Principal Engineer
Infineon Technologies
Munich, Germany
 

...rest deleted...