Hello,
I am designing a PCIe daughter card and have a couple questions.
1. The PCIe specification states there is a 1.6 ns lane-to-lane skew budget, which allows the designer not to worry too much about length matching between pairs. The _p and _n channel of each lane need to be matched, but there are not stringent requirements on the intra lane skew. I've used Xillybus for years and very much enjoy the simplicity of the user interface, however, the Xilinx PCIe IP has quite a bit more 'bells and whistles', or options for customization. My question is will Xillybus be able to handle data shifting (if necessary) due to lane-to-lane skew, or is that an advanced option that it does not support?
2. I don't need to add any fancy functionality (such as WAKE#, PWR, etc) and as such am not using a lot of the PCIe auxiliary signals. Assuming that the PRSNT# signal is correctly set to indicate the number of lanes I'm using, can I get away with just routing PRSNT# and all of my TX/RX lanes? That's all Xillybus seems to use in the .xdc and .ucf files. And is PERST# absolutely required as well for initialization?
Thank you.
PCIe Daughtercard requirements and Xillybus
3 posts
• Page 1 of 1
Re: PCIe Daughtercard requirements and Xillybus
by support »
Hello,
The Xillybus IP core works on top of Xilinx' PCIe block, so the simple rule is that if the PCIe block is happy, so is the IP core. These questions are therefore unrelated to Xillybus, but how the PCIe block works under different circumstances.
The lane skew issue is handled by the PCIe block entirely. Its responsible for the deskewing, and present its user (Xillybus IP core in this case) with properly organized data. So this is really a question to Xilinx.
As for which signals to route: PERST# is absolutely necessary. If this input doesn't go all the way to the signal that the processor produces, you're going to find yourself producing it artificially, based upon your best guess on when the processor issues it. I know that some people have gotten away with this is in specific closed systems, but only as a last resort (in particular when some SOM motherboard didn't expose this signal, and it was too late to ditch it altogether).
Other than #PERST, it's just the reference clock and the lanes. PRSNT# is something you need only if you're going to have a card slot.
And one piece of bonus advice: Careful with clock and voltages. As for the clock, I guess you're using the host's reference clock directly, so there's no need for special attention on this matter. So be sure to feed the transceiver's dedicated voltage supplies with a clean source. Compare with the official development board -- I don't think just any switched power supply will do the job properly. There are PLLs on the FPGA that are driven by these power supplies, so if they're noisy, that might induce jitter on the gigabit-rate clock, and now you have a wobbling PCIe link.
Regards,
Eli
The Xillybus IP core works on top of Xilinx' PCIe block, so the simple rule is that if the PCIe block is happy, so is the IP core. These questions are therefore unrelated to Xillybus, but how the PCIe block works under different circumstances.
The lane skew issue is handled by the PCIe block entirely. Its responsible for the deskewing, and present its user (Xillybus IP core in this case) with properly organized data. So this is really a question to Xilinx.
As for which signals to route: PERST# is absolutely necessary. If this input doesn't go all the way to the signal that the processor produces, you're going to find yourself producing it artificially, based upon your best guess on when the processor issues it. I know that some people have gotten away with this is in specific closed systems, but only as a last resort (in particular when some SOM motherboard didn't expose this signal, and it was too late to ditch it altogether).
Other than #PERST, it's just the reference clock and the lanes. PRSNT# is something you need only if you're going to have a card slot.
And one piece of bonus advice: Careful with clock and voltages. As for the clock, I guess you're using the host's reference clock directly, so there's no need for special attention on this matter. So be sure to feed the transceiver's dedicated voltage supplies with a clean source. Compare with the official development board -- I don't think just any switched power supply will do the job properly. There are PLLs on the FPGA that are driven by these power supplies, so if they're noisy, that might induce jitter on the gigabit-rate clock, and now you have a wobbling PCIe link.
Regards,
Eli
- support
- Posts: 802
- Joined:
Re: PCIe Daughtercard requirements and Xillybus
by mwayne »
am using linear voltage regulators, not switching, so hopefully that does the trick.
I forgot to log in earlier, thank you for the helpful reply.
I forgot to log in earlier, thank you for the helpful reply.
- mwayne
- Posts: 16
- Joined:
3 posts
• Page 1 of 1