DDR Mux - how does it work?

I'm looking at the IOB diagram for Spartan3. The output path has a block labled "DDR MUX" that seems like it should do the obvious thing.

It's got two inputs - the data bits.

How does it know when to switch? Does it get both clocks too, through some path that isn't shown?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray
Loading thread data ...

Try the Virtex II datasheet. It shows a block diagram where even the two data bits don't connect to the "DDR MUX" so it works with no inputs!

If you go into the FPGA editor you see something similar and while you hold your mouse over the mux the popup description includes the words black box.

I think Xilinx is trying to simplify the diagram to reduce clutter. The mechanism must have the clocks because it has to switch on the rising edge of each input clock (after the programmable inversion). If I had to code this in Verilog it would look like:

always @ (posedge FF1CLK) muxout

Reply to
Gabor Szakacs

The component template gives some insight on the connections. I used it to forward a clock in a VirtexII, and used the DCM phase adjust to optimize the timing.

I was excited about using this for clock forwarding. Others did not share my excitement. I must be a geek. Anybody got an extra Virtex-4 Xilinx T-Shirt they are willing to part with. I don't mind if it is wrinkled :}

- Newman

---------------------------------------------------------------- component FDDRCPE port( -- INPUTS-- C0 : in std_logic; C1 : in std_logic; CE : in std_logic; CLR : in std_logic; D0 : in std_logic; D1 : in std_logic; PRE : in std_logic;

-- OUTPUTS Q : out std_logic ); end component FDDRCPE; -- FDDRCPE

Reply to
newman

Just as a follow-up: The original question is a good one. When one sees a 2:1 mux, one may wonder if it is susceptable to static hazard one and static hazard zero glitches. I've seen that Xilinx recommends using this component for clock forwarding, which implies that it is not subject to such. When I reviewed the design in the FPGA editor, the inverter in the C1 path was apparently absorbed into the IOB. In some App note for high speed designs, it was recommended that the 180 DCM output be used for C1. Since my design was not high speed, and I was running out of clock buffers on that side of the chip, I opted for the merged inverter. Apparently the "DDR Mux" uses two clocks, and it is unclear exactly how it does that.

- Newman

Reply to
Newman5382

It's clear that the "mux" is really an integral part of the DDR flop design. It has been suggested that the individual flip-flops are not really wired as shown, but rather wired so that the outputs can be XORed together to form the final Q output. This method does not have a glitch if the Q doesn't switch. See VHDL code below.

The only reason I can see to use 180 DCM output (which uses extra global routing resources) is if the clock you're using is not

50% duty cycle. Normally DCM outputs are adjusted to 50% unless you tell the tools specifically not to. Thus using 0 phase clock and its inverse (yes the inverter is pulled into the IOB) gives just as good results. I think newer reference designs use this method instead of the 0 and 180 method.

I have used DDR flops as clock drivers because they make a good low skew (but not zero delay) copy of a global clock signal without extra routing resources related to using multiple DCM phases or

2x clocks. They also neatly match the data delay in DDR SDRAM designs.

From anonymous source:

There was a post a while back on comp.lang.vhdl about double edged clock circuits, and one of the responses included code for a double edged register built from two single edged registers and three XOR gates.

Basically, the way it worked was that the state of the DDR register was encoded as follows: Whenever the states of the two individial registers was different, the output was a '1', whenever they were the same, it was a zero. The following code will synthesize in synplify-pro, but might have to be split into separate processes for other tools. It creates a multiple-"bit" DDR "register", using SDR registers, with parameterizable size and reset value, through vhdl generics (it cannot puch this into an IOB's DDR register)

I don't know if this is the circuit that Xilinx uses or not (note that if one flop is held in reset, the circuit reverts to single edge functionality), but the output "mux" is really just an XOR gate, and no clocks are needed!

library ieee; use ieee.std_logic_1164.all; entity ddrff is generic (size : positive := 1; rstval : std_logic_vector := (0 => '0') -- unconstrained, defaults to 1 bit ); port (d : in std_logic_vector(size - 1 downto 0); q : out std_logic_vector(size - 1 downto 0); clk : in std_logic; rst : in boolean ); end ddrff;

architecture rtl of ddrff is signal qr, qf : std_logic_vector(d'range); begin -- Double Data Rate Flip Flop Circuit -- two bit state is encoded as follows: -- if flops differ, the 'value' is '1' -- if flops match, the 'value' is '0'; -- therefore either flop (on either edge) can change the state or -- keep it the same, and a simple xor gate decodes the state to -- produce the output -- output is glitch free main: process (rst,clk) is begin if rst then qr '0'); qf

Reply to
Gabor Szakacs

I started thinking along that line. I couldn't make it work.

Consider the case where the FFs are fed by 1/0 constants to make a clock. The value of the FFs never changes.

I'm sure the actual implementation has some interesting magic.

At least one place in the Xilinx documentation suggests using clk and clk180 in preferance to clk and clk-inverted for better results. I think the idea was that there is more skew on rising vs falling edges as compared to loaded and not-loaded clock distribution nets.

Might be fun to measure. I wonder how hard it would be to make something that balanced the clock loading. Probably doable in FPGA editor by hand for a one-shot experiment.

You could use a DLL with external feedback if you want to avoid that delay. But that delay doesn't matter for the normal clock forwarding case.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.