02-11-2020 09:59 AM
We are using Vivado 2019.1 and a xcku060-ffva1517-2-e device. The FPGA has a 218MHz edge-aligned DDR interface to multiple ADCs, each consisting of a 6-bit bus. We know that trace lengths on the board are relatively well matched. The DDR busses are on pairs of nibbles within a bank, and we configured the bitslice through through the HSSIO wizard (Edge DDR with a Bitslice Serialization Factor of 4). The interface meets timing. A partial schematic is attached for reference.
We require that the data for the multiple ADCs be aligned in time at the HSSIO output.
1. Documentation states that bitslip may be required to align bits when using the HSSIO. In our case, we are not using the RIU interface and have chosen a RIU clock (which drives clk_rst_top_inst) which is synchronous to the data clock. Can anyone confirm that because reset to RX_BITSLICE and BITSLICE_CTRL is removed synchronously to all bits, the data bits are aligned and bitslip is not required?
2. We are using the RX_BITSLICE FIFO on the back-end to transition from the source synchronous clock domain to a common clock domain derived from the same clock source (i.e. the fifo_rd_clk is the common clock). We expected to see the DCO to common clock domain crossing to show up in the Inter-Clock Paths report, but we don't see the CDC reported. Is the RX_BITSLICE FIFO clock domain crossing considered by the static timing analyzer?
02-12-2020 08:19 AM
Regarding #1, testing so far is demonstrating that bitslip is not necessary in this case (that is, the bits in the bus always come out of reset aligned). This makes sense, assuming the IDDR 'component' uses the same or similar hardware as the BITSLICE 'primitive'; however, I'm looking for confirmation from Xilinx that this is indeed the case.
03-04-2020 01:18 AM
You need a bitslip as RXPLL is sourced from the RX clock from ADC.
Please check this answer record
03-06-2020 06:01 AM
Thanks for the reply!
In our case, we must align data from multiple banks, but we do not have the ability to insert an aligned training pattern on multiple banks; therefore, bitslip is not an option. And again, I stress the RIU and RX clock are frequency locked and their phase skew is bounded (i.e. they are from the same source, but different physical paths).
We have also implemented the interface using IDDR using component primitives (see schematic attached); however, as expected, timing performance is much worse (because it does not got through Built-in Self Calibration). On the surface, it appears the bitslice has the same clock and reset connections in both modes, so given the same or similar routing, one would think both would behave the same exiting reset and bitslip would not be required for either... or would be required for both. Can you please clarify source of the misalignment which occurs in the native verse component primitive bitslice implementation?
I apologize for belaboring the point, but we must make a design decision on which approach to pursue for production, and I suspect the IDDR has <10ps margins while the HSSIO approach has >100ps...
03-11-2020 01:36 AM
The clocking path are fundamentally different between IDDR and the RX_BITSLICE.
They both can utilize BISC. The IDELAY in TIME Mode uses BISC (COUNT does not).
What is different for the clocking is that for an IDDR the clock is routed on through a BUFG which is powered by Vccint and has a variable path. For the RX_BITSLICE (in source synch mode / SERIAL_MODE = FALSE) is that the capture clock comes in on a QGC or DBC pin and is routed to the capture flops in that bank, the PLL feeds the deserializer circuit with the CLKOUTPHY path, both are powered by Vccint_io which is an isolated rail.
The RX clock that the AR is referring too is the Clk that is transmitted with the data. You said you are using a multi-bank interface so you must have multiple capture clock (RX CLKs). If you cannot stop these clocks until the VTC_RDY goes high then the design need to be able to realign the data. Even within a bank you need to be able to stop the capture clock until after VTC_RDY is high to ensure the channels are aligned.