<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ASPM makes Spartan-6&#8242;s PCIe core miss TLP packets</title>
	<atom:link href="http://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/feed/" rel="self" type="application/rss+xml" />
	<link>https://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/</link>
	<description>Anything I found worthy to write down.</description>
	<lastBuildDate>Thu, 26 Mar 2026 13:15:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Gareth</title>
		<link>https://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/comment-page-1/#comment-842</link>
		<dc:creator>Gareth</dc:creator>
		<pubDate>Wed, 06 Feb 2013 17:21:04 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=1287#comment-842</guid>
		<description>This is an issue with the Virtex-5 Endpoint Block Plus for PCI Express core where turning on ASPM causes the core to cycle in and out of recovery periodically. 

This is a known issue with the GTPs in the Virtex-5.  The issue is thoroughly documented in UG341 in the &quot;Known Issues&quot; section.  The two issues that may come up are titled: &quot;Receive Path L0s Exit to L0&quot; and &quot;Transceiver Exit from Rx.L0s&quot;

The only workaround is to disable ASPM.

This issue has been resolved in 6-Series and 7-Series.</description>
		<content:encoded><![CDATA[<p>This is an issue with the Virtex-5 Endpoint Block Plus for PCI Express core where turning on ASPM causes the core to cycle in and out of recovery periodically. </p>
<p>This is a known issue with the GTPs in the Virtex-5.  The issue is thoroughly documented in UG341 in the &#8220;Known Issues&#8221; section.  The two issues that may come up are titled: &#8220;Receive Path L0s Exit to L0&#8243; and &#8220;Transceiver Exit from Rx.L0s&#8221;</p>
<p>The only workaround is to disable ASPM.</p>
<p>This issue has been resolved in 6-Series and 7-Series.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eli</title>
		<link>https://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/comment-page-1/#comment-558</link>
		<dc:creator>eli</dc:creator>
		<pubDate>Wed, 06 Jul 2011 14:50:42 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=1287#comment-558</guid>
		<description>Thanks a lot for your comment. I&#039;ve updated the post above.</description>
		<content:encoded><![CDATA[<p>Thanks a lot for your comment. I&#8217;ve updated the post above.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John McLean</title>
		<link>https://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/comment-page-1/#comment-557</link>
		<dc:creator>John McLean</dc:creator>
		<pubDate>Wed, 06 Jul 2011 11:09:39 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=1287#comment-557</guid>
		<description>Eli,

Sorry quick follow-up - did not check the Xilinx website thoroughly enough

In AR33871 the LL_ACK_TIMEOUT is mentioned and it also related this to PM state so it could be an alternative way of fixing your problem</description>
		<content:encoded><![CDATA[<p>Eli,</p>
<p>Sorry quick follow-up &#8211; did not check the Xilinx website thoroughly enough</p>
<p>In AR33871 the LL_ACK_TIMEOUT is mentioned and it also related this to PM state so it could be an alternative way of fixing your problem</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John McLean</title>
		<link>https://billauer.se/blog/2011/06/pci-express-sp605aspm-xilinx-spartan/comment-page-1/#comment-556</link>
		<dc:creator>John McLean</dc:creator>
		<pubDate>Wed, 06 Jul 2011 11:00:50 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=1287#comment-556</guid>
		<description>Eli,

Thanks for your posting; were experiencing problems with the S6 too and after reviewing your post it helped to focus in on an issue which may or may not be relevant to your issue.
The reason for posting here is that the errors we found were spookily similar to yours in that the Core was reporting EXACTLY the same correctable and fatal errors that you reported but the cause was different

Our board previously operated on lots of Motherboards with no issues but on some customer systems deploying large SuperMicro Xeon Motherboards a problem appeared when larger (256) payload sizes were used.  

If you look through the Xilinx site you find that there is an issue with LL_REPLAY_TIMEOUT in the wrapper on their reference design which when changed according to AR39548 fixes the problem.

As I said this may or may not be related to your problem but as I said it results in exactly the same symptoms !!!!!

Note AR39548 does not mention this but I believe the LL_ACK_TIMEOUT needs to be changed too.

Regards

John</description>
		<content:encoded><![CDATA[<p>Eli,</p>
<p>Thanks for your posting; were experiencing problems with the S6 too and after reviewing your post it helped to focus in on an issue which may or may not be relevant to your issue.<br />
The reason for posting here is that the errors we found were spookily similar to yours in that the Core was reporting EXACTLY the same correctable and fatal errors that you reported but the cause was different</p>
<p>Our board previously operated on lots of Motherboards with no issues but on some customer systems deploying large SuperMicro Xeon Motherboards a problem appeared when larger (256) payload sizes were used.  </p>
<p>If you look through the Xilinx site you find that there is an issue with LL_REPLAY_TIMEOUT in the wrapper on their reference design which when changed according to AR39548 fixes the problem.</p>
<p>As I said this may or may not be related to your problem but as I said it results in exactly the same symptoms !!!!!</p>
<p>Note AR39548 does not mention this but I believe the LL_ACK_TIMEOUT needs to be changed too.</p>
<p>Regards</p>
<p>John</p>
]]></content:encoded>
	</item>
</channel>
</rss>
