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 To: geda-user AT delorie DOT com Date: Tue, 17 Feb 2015 00:51:30 +0000 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Clifton Electronics