Implement XDR buffer factories for all platforms #78
Comments
|
I've looked at several FPGA families (S7, ECP5, XO2) to see how they implement XDR for X>2. It looks like there are two common motifs: an additional clock is used and there is CDC from low-speed clock to high-speed clock, with an associated latency. This is probably the only realistic way to implement this so I'd expect all other families to work the same. So, a minimal change to the buffer factories to enable this would be to add Most realistic applications will also need fixed or configurable delay elements, which will also need to be exposed via |
|
Huge thanks to @jfng for doing the work on Xilinx series 6 and 7. |
|
I've implemented the ECP5 buffers. MachXO2 buffers are basically the same, so I think this is all done! Of course, we can look at more platforms in the future, but I think 3 families are demonstrating the viability of the concept quite well. |
This issue is primarily informational and used to collect design choices for the XDR buffer factories for all interesting platforms.
The XDR buffer factory cannot possibly cover every conceivable permutation of modes that the platform can provide. It also shouldn't. It would be very hard to validate an abstraction for even 2-3 different XDR mode combinations, and it would not even be particularly useful for writing robust code because inevitably there will be combinations of platforms, modes and gearings that are not supported, and portable code would avoid it.
Instead, I choose to select a specific mode that would be the only one supported when using
platform.request(..., xdr=n). This mode is selected so that it is supported on the maximum amount of platforms (hopefully, every single one) and presents the least amount of timing difficulties.Specifically, XDR factories should instantiate a buffer that:
o0,o1, ... at the rising clock edge;i0,i1, ... at the rising clock edge, with one cycle of latency.This way, no additional timing constraints are added:
o*need to be valid for one cycle before the edge, andi*are valid for one cycle after the edge.This can be implemented as follows for each FPGA family we support, considering only DDR (XDR=2) primitives:
D_OUT_1, and re-registerD_IN_0as well asD_IN_1in fabric.DDR_ALIGNMENT=C0and re-registerQ0in fabric.DDR_CLK_EDGE=SAME_EDGE_PIPELINEDforIDDR, and useDDR_CLK_EDGE=SAME_EDGEforODDR.See also this IRC discussion.
The text was updated successfully, but these errors were encountered: