IDDR probe for openXC7/nextpnr-xilinx#114
Two builds of the same design. The only intended difference between the two
bitstreams is the position of the ILOGIC IFFDELMUXE3 mux.
xc7a35tcsg324-1 (Digilent Arty A7-35T)
Any artix7 part works — the ILOGIC segbits are family-level, so an xc7a200t is equally good. If you retarget, please keep the pins identical between A and B.
| build | files | design | IFFDELMUXE3 position |
|---|---|---|---|
| A | A_direct_top.v + A_direct_top.xdc |
IDDR with D straight from the pad |
P1 ("direct") |
| B | B_idelay_top.v + B_idelay_top.xdc |
identical, but D through an IDELAYE2 |
P0 ("idelay") |
Both modules are named top. The two .xdc files are byte-identical — same pins:
clk=E3, d=A8, q1=H5, q2=J5 — taken from prjxray's own arty-a7 harness,
so they are known good.
Just the two .bit files. .dcps are equally welcome — I can pull
top_late.xdc out of those myself.
IFFDELMUXE3 is a three-position mux — Vivado's own site model says so
(nextpnr-xilinx-meta/artix7/site_type_ILOGICE3.json lists from_pin 0/1/2) —
and prjxray's fuzzer states what the positions mean
(fuzzers/035-iob-ilogic/generate.py:216-227):
'direct' -> P1=1 ; 'idelay' -> P0=1 ; 'none' -> all 0
segbits_lioi3.db documents only P0 (28_116). P1, the position a plain
IDDR needs, has no bit we can name — so nextpnr writes nothing, the mux sits in
none, the IFF has no data path selected, and that is #114.
Diffing A against B isolates exactly the missing bit. I have bitread/bit2fasm
and the artix7 database here and will do the disassembly and the differencing.
The database-side root cause is filed upstream as f4pga/prjxray#2569 —
fuzzers/035-iob-ilogic/bits.dbf is an empty file, which is why the all-zero
enum members never reach segbits.
Neither is needed for #114; both are things I cannot check without a vendor bitstream, and none of the four harnesses in prjxray-db contains a CMT.
- For #79 / PR #129 — an
MMCME2_ADVwithRSTdriven by an ordinary input port (not a constant). I found we emitZINV_RSTclear in that case, which per the fuzzer means the reset is inverted, i.e. the MMCM is held in reset for ever. - For #65 / PR #121 — an IDDR at
DDR_CLK_EDGE("SAME_EDGE_PIPELINED"). I claimed the encoding is bothDDR_CLK_EDGEbits clear, from a prjxray-db fork plus the fuzzer rather than from vendor output. This is one parameter value away from build A.