Using BUFG to drive clock loads

时光总嘲笑我的痴心妄想 提交于 2019-12-06 08:23:41

This doesn't directly answer your question, but it looks like you're trying to use a DDR output primitive to drive an external differential clock pin. This is a good thing to do, but the way you have done it seems unconventional. The standard way to do this would look more like this:

EDIT: I've realised that I misunderstood the question, and have incorporated the differential output instantiation from @StuartVivian

pxclk_inverted <= not pxlclk;

ODDR_pxlclk_p : ODDR2
    generic map(
        DDR_ALIGNMENT => "NONE",
        INIT          => '0',
        SRTYPE        => "SYNC")
    port map(
        Q  => PXLCLK_OUT,
        C0 => pxlclk,
        C1 => pxclk_inverted,
        CE => '1',
        D0 => '1',
        D1 => '0',
        R  => '0',
        S  => '0'
    );

inst_obufds : OBUFDS 
generic map (
  IOSTANDARD=>"LVDS_25"
) 
port map 
(
  O => PXLCLK_OUT_P, 
  OB  => PXLCLK_OUT_N, 
  I   => PXLCLK_OUT
);

In IO assignment, PXLCLK_OUT_N/P will then be set to use a differential IO standard. In a graphical pin assignment window, this port will then use two pins, and will only allow you to assign them to a valid positive/negative pair. What you're trying to do is manually create the positive and negative signals before the DDR output primitive, which is not the way it's supposed to work.

I think if you use this technique, and get rid of your BUFG, your problem should go away. If not, maybe update the question with this, and whatever the new problem might be.


Now that you've updated the question, I can see that your pixel output data also seems to be a DDR bus. You are trying to infer a DDR output behavior by implementing a multiplexer using a clock signal as the select line.

The more standard way to do this would be to instantiate n DDR output primitives, one for each bit of the parallel DDR output. According to the latest VHDL standard (VHDL2008) it is possible to infer a DDR output, but the problem with this is that this technique does not yet have widespread toolchain support.

After that error message there would have been a list of up to 30 pins in the design that the tool believes you are driving with the clock but are not actual clock pins.

The C0 and C1 pins should be treated as clocks, so I doubt it's complaining about those. As the clock signal goes to other blocks which we haven't got the code for, could these contain end points for the clock that aren't clock pins?

I agree with scary_jeff's answer regarding the use of the ODDR2. To make a differential output from the output of the ODDR you need to instantiate a differential driver in the code i.e. LVDS_25 or LVDS in Xilinx architecture, and then set the logic standard in the ucf or xdc/sdc constraints files. The tools documentation should give clear examples of this.

inst_obufds : OBUFDS 
generic map ( IOSTANDARD=>"LVDS_25" ) 
port map 
(    O => DIFF_P, 
     OB  => DIFF_N, 
     I   => internal_signal
);

The message is reported because pxlclk is used to drive the multiplexer in the component of DVI_MUX and this multiplexer is placed before the flipflop. To reach the select signal of the multiplexer, the signal pxlclk must use the general purpose routing instead of the dedicated clock tree. Please read UG381 from Xilinx, pp. 61/62 on how the Spartan-6 supports DDR outputs.

I recommentd to use the ODDR2 component also for the data pins. The inputs D0 and D1 just provide the data which should be output with the rising edge of clock C0 and C1 respectivly. Please lookup the UG615 from Xilinx for a thruth table and more information. If the documentation seems to be unclear, I recommend to simulate the component DVI_MUX standalone first.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!