X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Cam-AntiVirus:	no malware found
X-Cam-ScannerInfo:	http://www.cam.ac.uk/cs/email/scanner/
Message-ID:	<1424134290.18156.11.camel@cam.ac.uk>
Subject:	[geda-user] Debugging PCIe link (without expensive test equipment)?
From:	Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To:	geda-user AT delorie DOT com
Date:	Tue, 17 Feb 2015 00:51:30 +0000
X-Mailer:	Evolution 3.12.7-0ubuntu1
Mime-Version:	1.0
Reply-To:	geda-user AT delorie DOT com

Hi,

Thought I'd call on the collective wisdom here..

Does anyone know how to debug a PCIe link (without expensive test
equipment)?

I'm about two orders of magnitude out in frequency, regarding a scope
fast enough to actually look at the link eye by probing it.

I'm seeing some problems where the test machine my card is in hangs when
I access certain addresses mapped on its memory bus. PCIe is bridged to
a local bus with a PLX bridge chip, and I've disabled the various local
bus handshaking in our FPGA, so my gut feel is that the problem is
"probably" something to do with the PLX chip, or its link to the PCIe
slot.

There are a couple of bits of the PCIe diff-pair routing that are
slightly suspect (not my layout), but I'm unsure whether this is likely
to manifest with specific address reads or not.

I'm currently working under Windows 7, but could throw a Linux image at
the problem if anyone knows of any kernel level link diagnostics
available by doing so.

I was wondering if particular PCIe reads would result in repeatable
enough TLP packets to perhaps trigger certain symbols on the PCIe link
that (through ISI) lead to the link falling over and the machine
hanging.


Best regards,

-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics

- Raw text -