Hi Joe, thanks for taking up on this one.
Yes, I was referring to host testing based on CEM spec.
And for TX / RX testing I see similar results as you describe.
I was talking about Clock testing.
I know this is somehow a strange topic, as Clock jitter is covered in
the base spec. I had some discussions two years ago for Gen2 Clock and
the answer i got was: The clock compliance at the connector is not of
interest (I'm still not convinced on this ;-) ).
Although looking to the new Clock jitter tool the documentation of the
Gen2 / Gen3 templates says "to be measured at the connector".
And when now doing a clock compliance test (t-REFCLK_RMS_DC) with all
Bandwidth and peaking settings that are defined in the spec many of the
combinations fail.
Looking to the results: the SSC of the systems look clean, but after the
filtering some of the SSC is still remaining and is causing a fail in
the rms Jitter.
The spec is somehow not clear where to measure:
- Measure in the system at the connector (where for my Gen2 questions I
got the answer NO)
- How to measure ? Do I need to measure all combinations of peaking and
BW settings (what I would assume)?
Maybe I'm just overlooking some measurement documentation on this one.
Basically this would open another Question:
- If I verify TX compliance with dual port methodology (TX + Clock used
to generate the Eye) .. why should this give any answer for a Data
clocked RX architecture compliance ?
At least I would not see how the compliance test implementation (I only
know the dual port methodology) would verify a system with Data clocked
RX architecture (especially if the Clock Compliance is failing and I
assume similar jitter behavior on TX as on CLK...)
But I did not want to put this question into the same discussion as the
clock compliance question too keep thinks simple ...
Best regards
Hermann
EKH - EyeKnowHow
Signal Quality - Made in Bavaria
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@xxxxxxxxxxxxx
Itzlinger Strasse 21a
94469 Deggendorf
Tel.: +49 (0)991 / 29 69 29 05
Mobile: +49 (0)176 / 787 787 77
Fax: +49 (0)3212 / 121 9008
Am 02.06.2016 um 15:43 schrieb Joseph.Schachner@xxxxxxxxxxxxxxxxxx:
I am pretty sure you are thinking of Base spec. My answer is about
CEM form factors (add in cards and system boards).
I go to workshops to test using Teledyne LeCroy equipment, that is CEM
(Card Electro Mechanical form factors) testing. I participate on
PCIe's EWG, CEM and SEG. (roughly corresponding to base spec, CEM
spec and test spec).
Usually at the workshop I do TX testing, but I have also done RX and
even LEQ. What I personally have seen:
Almost everything passes TX. For TX testing, Add in cards are
inserted into a Compliance Base Board (CBB) fixture which produces a
spec compliant 100MHz clock without SSC. For TX testing systems, we
insert a Compliance Load Board (CLB) fixture into a slot of the system
and capture the data and the clock from the system; jitter is measured
between the data and the clock. The only failure we see with some
regularity on TX is that Preset 10 does not have at least 9.5dB of
de-emphasis. For some reason (probably phrasing of the base spec)
people don't seem to take that particular requirement seriously.
For RX testing we put a signal that makes the minimum eye opening into
the card or system, which is in loopback mode. What it transmits back
is compared to what was sent, 0 or 1 bit errors in 1e12 bits is
allowed. In this test, the transmitted signal uses Preset 7 (plus
noise and jitter). I just looked in our RX test script, for an Add In
Card it appears that we do not use SSC. For a System, of course, we
use the systems 100MHz clock so if the system has SSC turned on then
we have to follow it; if it does not have SSC turned on that's also
OK, we use its clock in either case.
LEQ is kind of like RX except that the Receiver and the transmitting
test equipment (PeRT3) actually go through the link training. The
transmitter uses whatever preshoot and de-emphasis the receiver told
it to use. If the receiver passed RX (proves that there is a TX
preset at which the receiver will work) but fails this part of LEQ
then clearly its training algorithm is sub-optimal! The LEQ test
also checks that if the RX is asked to transmit back using presets or
tap values we get the same waveform; and that when asked for presets
it returns the expected tap values. The Preset test is run again on
waveforms collected using the tap values the RX told us it was using
when each preset was requested. If the Preset test passed in TX and
passed using Presets in LEQ but doesn't pass this test, then the tap
values returned from the RX are not really the values in use. We have
seen that, too. I think LEQ does use SSC for add in cards (but I'm
not sure, I didn't write that script) and of course for systems we use
the system board's clock, so if it is SSC'd then the test equipment
follows that SSC.
So, about SSC in summary:
1) Add In Cards are not subjected to SSC in TX (where SigTest does
test all PLL corner cases), and in RX and LEQ only if the test
equipment chooses to use SSC. It is not required to do so. A CEM add
in card uses whatever PLL it is set up to use in its RX. We test
that it passes the PLL test. We don't (we can't) vary the Add In
Card's RX PLL to each corner, that's not the point. The point is to
make sure the AIC is using a PLL setting that is compliant and makes
it work.
2) System boards use SSC or not, as they choose. On TX, SigTest does
test all PLL corners and shows the worst results. Systems pass
anyway. On RX and LEQ the test equipment follows the System's clock.
I think I will venture an opinion: Many systems I've tested do use
SSC, some do not. I think it's about even. Although there is some
residual SSC (ie, jitter is slightly higher) on systems that use SSC,
they pass anyway. There is a PLL test that makes sure the System's RX
PLL is compliant. Once again, we don't (we can't) vary the PLL used
by the RX in the system board's root complex, and that is not the
point of testing. The point is to make sure that the system is using
a PLL setting that is compliant and makes it work.
--- Joe S.
From: Hermann Ruckerbauer <hermann.ruckerbauer@xxxxxxxxxxxxx>
To: si-list@xxxxxxxxxxxxx,
Date: 06/02/2016 04:41 AM
Subject: [SI-LIST] PCIe Gen3 clock compliance with SSC
Sent by: si-list-bounce@xxxxxxxxxxxxx
------------------------------------------------------------------------
Hello PCIe Experts,
maybe somebody can answer one= questions for PCIe Gen3 clock compliance
especially with SSC.
For Gen3 clocking the spec defines different behavior of RX PLL/CDR,
dependent on Data clocked or Common Clocked RX
architecture.
The spec just recommends with all unique combinations of bandwidth
and peaking.
But some of them just seem not to be able to follow SSC for Data clocked
RX architecture reasonably. For several different platforms I have seen
fails for this parameter when SSC is enabled. Based on these tests I do
not think this is a question of SSC implementation of the Cock source.
Even
for some complete different platforms I do see a similar risidual of SSC
after applying all filters/transfer functions.
did somebody else observe something similar ? (and if yes ..
what is your conclusion out of this fail? )
For data clocked it is necessary to compute the worst case T-Refclk-rms-DC
for all unique combinations of peaking/BW. With this requirement i guess
all systems that I have seen in the last time woudl fail.
For common clocked t is just recommended to test all combinations of
peaking/BW to characterize T-Refclk-RMS-CC jitter ... But seems not
required .. so is it allowed to select the settings that pass the Test ?
(but common clocked is anyhow not failing)
thanks and regards
Hermann=
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
