ODDR2 usage found in auto-generated xilinx wrapper VHDL file

Question

I'm using the TEMAC IP core to generate a 1gb ethernet MAC, and came across an interesting piece of code:

-- DDr logic is used for this purpose to ensure that clock routing/timing to the pin is
-- balanced as part of the clock tree
   not_rx_clk_int <= not (rx_clk_int);

  rx_clk_ddr : ODDR2
    port map (
      Q  => rx_clk,
      C0 => rx_clk_int
      C1 => not_rx_clk_int,
      CE => '1',
      D0 => '1',
      D1 => '0',
      R  => reset,
      S  => '0'
      );

So according to my understanding, what's happening here is that a "new" clock is being generated by two clocks that are 180 degrees out of phase by using each clock as a select line input to the mux. (See very useful diagram below taken from page 64 in this document!)

When C0 is '1' then Q <= D0 which gives rx_clk <= '1', and if C1 is '1' then Q <= D1 which gives rx_clk <= '0'. During reset both flipflops are reset giving rx_clk <= '0' while reset = '1'

---

So I have a few questions:

1. Are the two clocks (not_rx_clk_int and rx_clk_int) going to be precisely 180 degrees out of phase when generated in this way? (by this way, I mean not_rx_clk_int <= not (rx_clk_int)). I assume not due to delta time? What are the implications of this?
2. What is the benefit of using the ODDR2 in the first place (why isn't rx_clk <= rx_clk_int adequate)? (Which leads to...)
3. What does it mean for a clock to be "balanced" as part of the clock tree? (clock tree mentioned briefly on page 59 here.)
4. Isn't rx_clk being gated during reset? Isn't this bad?
5. Is this the "standard" way of using a ODDR2 and/or performing this operation? Are there better options? (and hence, should I add this to my arsenal of useful VHDL bits and pieces? )

Feel free to suggest recommended reading and/or other resources. I don't want to blindly copy/paste this code into my project without knowing exactly what's going on here.

Answer 1

1) Are the two clocks (not_rx_clk_int and rx_clk_int) going to be precisely 180 degrees out of phase when generated in this way? (by this way, I mean not_rx_clk_int <= not (rx_clk_int)). I assume not due to delta time? What are the implications of this?

Yes, they will be pretty well exactly phased.

Delta-delays are not at issue here. They only apply to HDL simulations, standing in place of unknown "real" delays. I would hope that Xilinx got their model correct so that both edges change in the same delta cycle! ie. they do something like:

not_rx_clk <= not (rx_clk_int);
rx_clk <= rx_clk_int;

to match the deltas.

2) What is the benefit of using the ODDR2 in the first place (why isn't rx_clk <= rx_clk_int adequate)? (Which leads to...)

It ensures that the delay is predictable relative to the other IOs that you no doubt have synchronised with this clock. If you just drive the clock signal out of a pin, it has to come off the clock distribution network, through some routing, and then to the pin (as there's no direct route for a clock net to get to the IO pin. That's a delay which is unpredictable and likely to vary from one compile to another.

3) What does it mean for a clock to be "balanced" as part of the clock tree? (clock tree mentioned briefly on page 59 [here.][3])

As I understand it, it means that the clock tree makes sure that the clock goes the same distance (approximately) to every destination.

4) Isn't rx_clk being gated during reset? Isn't this bad?

Yes it is being turned on and off (I'd hesitate to use the word 'gated' as that means a specific thing - being fed through an AND gate - which this isn't). Only you can say if that matters - it depends on where it goes to.

5) Is this the "standard" way of using a ODDR2 and/or performing this operation? Are there better options? (and hence, should I add this to my arsenal of useful VHDL bits and pieces? )

Three questions in one, sneaky :)

• Yes, it's (a) standard way of using ODDR2 (the other standard use is for actual DDR data of course).
• No, I don't know of a better way to simply get a clock out.
• Yes, add it to your arsenal.