problem with PCIe troughput in CIV GX DevKit

--- Quote Start ---

i have a problem with the PCIe in the cyclone IV FPGA:

i have implement the PCIe HIP using Qsys on Quartus II 11.0 with the modular SGDMA and a On-Chip-Memory.

i connect the CIV with my PC using windriver Application. i use some functions to mesure the throughput.

the problem is that i have the same throughput even if i use x1 or x4 implemention ( 208 MBytes/s), and normaly in x4 configuration that can be four times this result.

--- Quote End ---

Can you please look at the number of lanes the link negotiated to?

While testing the Qsys PCIe core in x4 mode, I found that the core negotiated to either x1, x2, or x4. I have not yet determined why. I'd be interested in hearing if you are facing the same issue.

Here's a thread with my test results. Look at the document. It has comments on using lspci to determine the link width.

http://www.alteraforum.com/forum/showthread.php?t=35678

Cheers,

Dave

Hi casamar and Dave,

I am currently also having this issue! Have either of you been able to find the answer to this? As for an actual solution, this is the closest I've found so far:

http://www.altera.com/support/kdb/solutions/rd03092011_589.html

Apparently you have to write to the Link Control register located at 0x90, but how?

Cheers,

Josef

Hi Josef,

--- Quote Start ---

I am currently also having this issue! Have either of you been able to find the answer to this?

--- Quote End ---

No, I went with a different PCIe solution (using an MPC8308 PowerPC).

--- Quote Start ---

As for an actual solution, this is the closest I've found so far:

http://www.altera.com/support/kdb/solutions/rd03092011_589.html

Apparently you have to write to the Link Control register located at 0x90, but how?

--- Quote End ---

Re-read the KB link again:

"software must set bit 5 of Link Control register in the root port to trigger retraining link"

If your board is PCIe device, the root-complex is the host PC. To trigger retraining there, you would have to trigger something using OS services, eg., under Linux use PCI hotswap to trigger re-enumeration. I've no idea how you would do something similar with Windows.

File a Service Request with Altera and see what they say. Perhaps there is something you can do with the core, or perhaps you can trace the negotiation phases and see why it decides to reduce the lane width, eg., did the host decide or the peripheral?

Cheers,

Dave

--- Quote Start ---

Can you please look at the number of lanes the link negotiated to?

Hello, Dave!

While testing the Qsys PCIe core in x4 mode, I found that the core negotiated to either x1, x2, or x4.

--- Quote End ---

Dit it happen on the same PC - one time the core negotiated to x1 and another time to x4?

I have an issue, that PCIe core in a custom board on one PC always negotiates to x4 and on the other - always to x1.

What could be the cause?

--- Quote Start ---

Dit it happen on the same PC - one time the core negotiated to x1 and another time to x4?

I have an issue, that PCIe core in a custom board on one PC always negotiates to x4 and on the other - always to x1.

What could be the cause?

--- Quote End ---

The PCIe board was plugged into a OneStopSystems external motherboard, which was in turn connected to a PCIe bridge over to a laptop. I didn't try a "regular" PC motherboard. The fact that I could not simulate with PCIe BFMs made me give up on using Altera's PCIe solutions. If that situation has changed, then I'll look at them again.

I'm not sure what causes the lane width error. If I cared enough (which I did not at the time), I would have used SignalTap II to look at the link training state machine and see if it produced errors. Basically you need to read the PCIe specification and find out where in the link training the width is determined, and then trace that sequence to see what is going wrong.

Cheers,

Dave