by support »
Hello,
It's not clear what you meant with the Refclk from the "original side". But if you mean that you're using a clock that is generated on the FPGA board instead of the clock that the Jetson generates, that a recipe for trouble of the sort that you describe. It works first, but then it doesn't.
PCIe is an excellent protocol, and it's very good at recovering from a whole range of problems. Therefore, a PCIe link often appears to work fine, when in fact there are a lot of problems that are hidden by the protocol.
As for my suggestions in the said link: None of the bits should be set. Bit 0 means Correctable Error. The fact that it's set means that something went wrong (usually errors in low-level packets), but the protocol managed to fix it. Sometimes this bit gets set because of early-stage issues. So I suggest clearing the bits as mentioned on the said web page, and see if bit 0 returns to 1. If it does, there's something that needs fixing.
As for the other two bits that became '1' in correlation with a visible problem, that gives the final confirmation that it's a low-level link problem. It's pointless to analyze why exactly these bits were asserted.
As for the changes you made in the timing constraints: I can't comment on those, because you didn't explain exactly what you did and why you did it. However, there shouldn't be a need to add a clock in the timing constraints, so the fact that you did that may indicate that you're hiding a different problem.
And a more general comment: This is FPGA design, not C programming. The goal is not to silence errors or warnings. Unlike programming, it's very much possible to obtain a completely malfunctioning design with the tool's blessing. The FPGA tools assume that you know what you're doing. Errors and warnings are a nice extra, but if you respond to them by going for the first solution that silences them, odds are that you didn't fix the problem at all.
So be sure that you understand exactly every change you did with the timing constraints. In fact, I would suggest not making any changes to the demo bundle, if possible. There's no problem if you connect only the first PCIe lane to the host, and the others remain physically disconnected. The PCIe protocol should automatically negotiate down the link to x1.
Regards,
Eli
Hello,
It's not clear what you meant with the Refclk from the "original side". But if you mean that you're using a clock that is generated on the FPGA board instead of the clock that the Jetson generates, that a recipe for trouble of the sort that you describe. It works first, but then it doesn't.
PCIe is an excellent protocol, and it's very good at recovering from a whole range of problems. Therefore, a PCIe link often appears to work fine, when in fact there are a lot of problems that are hidden by the protocol.
As for my suggestions in the said link: None of the bits should be set. Bit 0 means Correctable Error. The fact that it's set means that something went wrong (usually errors in low-level packets), but the protocol managed to fix it. Sometimes this bit gets set because of early-stage issues. So I suggest clearing the bits as mentioned on the said web page, and see if bit 0 returns to 1. If it does, there's something that needs fixing.
As for the other two bits that became '1' in correlation with a visible problem, that gives the final confirmation that it's a low-level link problem. It's pointless to analyze why exactly these bits were asserted.
As for the changes you made in the timing constraints: I can't comment on those, because you didn't explain exactly what you did and why you did it. However, there shouldn't be a need to add a clock in the timing constraints, so the fact that you did that may indicate that you're hiding a different problem.
And a more general comment: This is FPGA design, not C programming. The goal is not to silence errors or warnings. Unlike programming, it's very much possible to obtain a completely malfunctioning design with the tool's blessing. The FPGA tools assume that you know what you're doing. Errors and warnings are a nice extra, but if you respond to them by going for the first solution that silences them, odds are that you didn't fix the problem at all.
So be sure that you understand exactly every change you did with the timing constraints. In fact, I would suggest not making any changes to the demo bundle, if possible. There's no problem if you connect only the first PCIe lane to the host, and the others remain physically disconnected. The PCIe protocol should automatically negotiate down the link to x1.
Regards,
Eli