Difference between center,edge mmcm and edge direct allignments

Question

What is the difference between center, edge mmcm and edge direct allignments.

Answer 1

Both of these terms are used most often used (but not exclusively) when describing source synchronous interfaces.
Edge Aligned vs. Center Aligned
When a device uses source synchronous communication, be it a device that sends data to an FPGA (an input to the FPGA) or a an FPGA sending data to an external device (an output of the FPGA), the device needs to define and describe the timing relationship between the clock and the data that it is forwarding to the other device. The receiving data needs to know this timing relationship in order to devise a mechanism to capture the data.
The timing relationship can really be just about anything, but two types are common:
Edge Aligned:
This is the simplest for the transmitting device. The device simply generates the forwarded clock and data using the same mechanism. If the sending device is an FPGA, then it uses an internal clock to drive an ODDR that drives the forwarded clock, and uses the same clock to send the forwarded data, either using an IOB flip-flop (SDR) or an ODDR flip-flop (DDR).
Using this mechanism, the timing relationship is often (but not always) described as a skew; i.e. the data will change +/-200ps around the edge/edges of the clock.
Of course, this clock/data timing relationship can rarely be used "as is" by the recieving device, so the receiving device will be responsible for adding some delay or other mechanism to use the forwarded clock to capture the forwarded data (i.e. an MMCM shift or an IDELAY).
Center Aligned:
This is supposed to be the simplest mechanism for the receiver. The transmitter uses some internal structure to place the edges of the forwarded clock in the middle of the forwarded data valid window. In an FPGA (as a transmitter), an internal clock would drive an ODDR for the forwarded clock, but the forwarded data would be driven from either an IOB FF using an inverted clock (SDR) or an ODDR using a clock that is 90 degrees out of phase (DDR). (Or it could be vice versa - the data uses the normal clock, and the forwarded clock uses the inverted or 90 degree clock).
Using this mechanism, the clock/data relationship is often (but not always) defined as a provided setup/hold relationship around the forwarded clock; i.e. the data will be valid 1.5ns before the edge of the clock and remain valid for 1.5ns after the edge of the clock.
The idea is that using this timing relationship, the receiver should be able to use the forwarded clock as is to capture the forwarded data. In general, though, this is rarely true, since most devices don't have an equal required setup and hold time; so the receiver still needs to modify the clock/data relationship to center its required window in the provided window.
MMCM vs. Direct Capture
This is a different concept. Regardless of which alignment is used (edge, center or something in between), the receiver (now we are assuming it is the FPGA doing the reception) needs to implement some clocking mechanism to use the forwarded clock to capture the forwarded data. There are really two styles:
Direct Capture:
The forwarded clock is brought in and goes directly to a clock buffer (either BUFG/BUFH or BUFR/BUFIO), which is used to capture the incoming data. Generally (as I said above), the clock/data timing relationship needs to be changed, and when using this capture mechanism, this can only be accomplished using an IDELAY on the clock or data (or both). When done this way, the clock has a propagation delay through the delay element (the IDELAY)
MMCM Capture:
Here, the forwarded clock is brought in on a clock capable I/O, then through an MMCM and from there to a BUFG or BUFH (with feedback to the MMCM). When done this way, the "common" way of modifying the clock/data timing relationship is by adjusting the phase delay of the MMCM output clock.
There is a subtle but extremely important difference in Vivado (and SDC/XDC) between a propagation delay and a phase delay (or phase shift). It has to do with how the tool determines which clock edge will capture data that is generated by a particular clock edge.
When we use a set_input_delay, we describe to Vivado a data window associated with a particular clock edge. By default, that data window will be captured by the next edge of the clock. The definition of the next edge is different when using these two mechanisms.
When a clock edge is propagated through a delay element, the resulting clock is the same edge. Lets take the example of a 10ns clock (rising at 0ns, falling at 5ns) with a 2ns delay (using an IDELAY) capturing an SDR data. The rising edge at time 0ns will generate a data window. By default, it will be captured by the next clock edge, which is at 10ns. After the 2ns of propagation delay, the internal clock at 12ns will be used to capture the window.
When a clock is phase shifted, a new clock is generated. Using the same example using an MMCM, the output clock of the MMCM rises at 2ns and falls at 7ns (and rises again at 12ns). So, the data window defined by the first rising edge of the input clock (at time 0), will be captured by the next rising edge of the phase shifted clock, which is at 2ns (this 2ns rising edge of the phase shifted clock is the "next" edge after the 0ns edge that generated the data window). This is different than the previous example, where the internal edge at 12ns (not 2ns) would capture the first window.
As a result, the constraints you use to describe the timing relationship (the set_input_delay) needs to be different between these two styles. Its also a bit messy, since the constraints that are correct for an MMCM with 2ns (or even 0.01ns) of phase delay are not correct for an MMCM with 0ns of phase delay (which is a bit icky).
I hope that clears things up!
Avrum