Thanks for responding. Sorry for the long delay.
I saw that there are pins labeled for DQS connection on the chip. These pins are not “clock-capable” in a sense recognized by the router.
get_property IS_CLK_CAPABLE [get_package_pins B15]
0
What I’m trying to do is probably not very common. Most people would just use the MIG to get an interface to SDRAM. But if you want to build one from scratch, you have a problem because the DQS pins are not Clock Capable, so they can’t be routed directly to BUFIOs. For DDR reads through IDDR/ISERDES, this means each DQS read-clock (UDQS/LDQS) has to be routed by some other means to the 8 corresponding ILOGIC cells, next to the individual IOBs.
If they can’t be connected directly to a BUFIO, then they can’t be routed with low latency and jitter directly to the IDDRs for the data DQ lines. Here are some solutions.
(1) Just do what the MIG does
The MIG uses the hardware PHASER_{IN/OUT}_PHY units. Each DQS drives a PHASER_IN_PHY, which then drives ISERDES clocks on the associated DQ lines.
https://docs.amd.com/r/en-US/ug586_7Series_MIS/Overall-PHY-Architecture
As far as I can tell, these units are inaccessible to us outsiders. There are no primitives. So, this seems unworkable.
(2) Route the DQS through BUFR → BUFIO → IDDR/C(B). This has the advantage that each DQS clock arrives at roughly the same time at all the IDDRs. Unfortunately, it also means there’s a latency of >5 ns in the clock signal. For any reasonable memory clock-rate, this far exceeds the delay that can possibly be added to the DDR data coming to the IDDR/D from the IOBUFDS through the local IDELAY. So, this seems unworkable.
[Idea: Maybe I could just depend on there always being 1 “wasted” clock of SDRAM read-preamble (no data), and I could just plan to always lose the first DQS clock-cycle of (empty) read-data, and the IDDRs would simply latch the actual DQ data (after preamble) with the long-delayed DQS read-clock. That requires tuning the DQS->IDDR latency to be exactly 1 clock cycle, which seems like it would boil down to requirement for a single possible SDRAM clock-frequency.]
(3) Route the DQS clocks directly to the IDDR/C(B) pins. This works, but it has significant variation in latency. I couldn’t find constraints that made any difference in how these lines are routed. (I tried set_min/max_delay and set_bus_skew, but all were ignored. Maybe I have some other constraints that are interfering?) The latency on these DQS clock routes is large enough that it seems to require adding a DELAY on the individual DQ lines, but also varied enough that (for reasonably-fast clocks) it also requires a different custom delay on each line.
These custom delays can be computed from examining the timing-paths on the DQS lines to IDDRs. Then the processing of parallel input (bytes) from SDRAM reads downstream of the IDDRs also requires custom delays to decompensate the delays upstream of the IDDRs, but that seems like it should be workable with constraints, after measuring the (different) timing-paths from DQS to the downstream parallel work.
(4) Maybe there are simpler/smarter approaches? I’m new to this stuff, and I’m open to learning from others. Maybe my goal is just not reasonable?
(5) Revised Suggestion:
Your comment about the need to connect SDRAM to the specified DQS pins on the chip makes sense, and that’s probably what the vast majority of your customers want. I don’t know whether it is difficult to do (e.g., expensive, complicated, technically difficult, too much time needed), but would it be feasible to add a simple solder-able jumper on the board, so that users could select between normal SDRAM pin-connections and DQS->CC connections? It’s a great board, anyhow.
Thanks.