Clock constraints in ucf file for DCM generated and input clocks

[doovie]

Hi There,

I have a system with a few different clocks and I'm failry new to the ucf constraints world especially when it comes to multiple clocks and clocks based on DCMs.

My system contains:

1.  System clock at 100 MHz - "clk"

2.  VGA clock @ 40 MHz -- this clock is used to process vga display data -- "vga_pix_clk" 

3.  VGA clock @ 40 MHz -> output to video DAC -- "vga_dac_clk"

4.  Camera clock @ 13 MHz -> input to system -- "cam_clk"

The 100 Mhz clock is generated by an on board 100 MHz oscillator.  I use this clock as an input to a DCM and use clk0 output as my system clock.  I also use the DCM to create the 40 MHz vga clock:

 dcm_test dcmClockGen (// Outputs

 .CLKFX_OUT(vga_pix_clk), 

 .CLKFX180_OUT(vga_pix_clk_180), 

 .CLKIN_IBUFG_OUT(CLKIN_IBUFG_OUT), 

 .CLK0_OUT(clk),

 // Inputs

 .CLKIN_IN(clk_in));

In order to output the 40 MHz clock to my video DAC I'm using an oddr2 block per some forum browsing I've done:

  ODDR2 #(

   .DDR_ALIGNMENT("NONE"),

   .INIT(1'b0),

   .SRTYPE("SYNC")

   ) ODDR2_inst (

 .Q   (vga_dac_clk), // 1-bit DDR output data

 .C0  (vga_pix_clk),     // 1-bit clock input

 .C1  (vga_pix_clk_180),    // 1-bit clock input

 .CE  (1'b1),         // 1-bit clock enable input

 .D0  (1'b1),

 .D1  (1'b0),

 .R   (1'b0),  // 1-bit reset input

 .S   (1'b0));

The camera clock is fed from a camera, wherein the clock signal is routed to a global clock pin on my device.

I'd like to put into my ucf file the various period constraints for these different clocks.  Here's what I have so far:

NET "cam_clk" TNM_NET = cam_clk;

TIMESPEC TS_cam_clk = PERIOD "cam_clk" 37.5 ns HIGH 50%;

NET "clk" TNM_NET = clk;

TIMESPEC TS_clk = PERIOD "clk" 10 ns HIGH 50%;

NET "vga_pix_clk" TNM_NET = vga_pix_clk;

timespec TS_vga_pix_clk = PERIOD "vga_pix_clk" 25 ns HIGH 50%;

Is this correct?  Given that clk and vga_pix_clk are generated by a DCM are teh latter two constraints needed (I'd imagine that since the DCM wizard asked me what clock frequencies I'm using these constraints are almost implicit?)?

Anything else I should add vis-a-vis the clocking constraints?  Thanks!

D

[avrumw · Accepted solution]

D,

The Xilinx tools understand the DCM. Therefore it is recommended that you only constrain the input of the DCM, and let the tools generate the proper constraints on the outputs. In general, this is done by specifying the clock at the input port of the FPGA.

In this case, you have a 100MHz clock coming in from an external oscillator on a pin of the FPGA (we don't have the name of the top level port of your design from what you have given us). Therefore, you should only have one constraint

NET <top_level_port> TNM_NET = tnm_<top_level_port>;

TIMESPEC TS_<top_level_port> = PERIOD tnm_<top_level_port> 10ns;

The tools will then propagate this constraint forward to the DCM, and generate new constraints for all the outputs. You will be able to see these new constraints in the .bld file after ngdbuilt is run.

By doing what you did (independently declaring the outputs of the DCM), you are defining them as unreleated clocks. What this means is that the tool will consider any path between the different outputs of the DCM as false paths - it will not perform timing analysis of them - they will show up in the unconstrained path report.

The way ngdbuild defines them, they will end up as related clocks - ngdbuild will relate the period and phase of the different clocks to eachother so that the paths between them will be properly constrained for synchronous clock crossing. Thus, there will effectively be a 5ns constraint on paths between the 10ns and 25ns clocks.

As for cam_clk, your comments say cam_clk is at 13MHz, but the constraint says 26.7 - which is correct? Since it comes from a separate oscillator (inside the camera), and comes in on a different port, it will need its own constraint - again, it should be applied to the top level port of your design. The cam_clk and other clocks will be unrelated - this means that you will need some sort of clock crossing circuit (maybe an asynchronous FIFO) to bring data from the cam_clk domain into one of the other domains.

The ODDR looks right.

Avrum

[doovie]

Hi Avrum,

Thanks so much for the reply!  Interesting.  Makes sense that the DCM should know about the outputs, but shouldn't it also know what the input is?  Afterall in the wizard I specified that the input to the DCM is 100 MHz.  I guess I'm a little surpirsed that it knows about one, but not the other.  In any event I will roll in the change you suggest into my ucf.

Good catch -- originally I was using a 26.66 MHz clock for the camera, but switched to a 13.33 MHz clock.  Fixed accordingly.

You are very right -- I'm utilizing an asynchronous fifo to pass data across the two clock domains. 

Thank you very much for your help!

D

[avrumw]

D,

There's "know" and there's "know".

The information given to the clocking wizard is purely used to build the proper clock structure. In the case of the DCM, the frequencies of the inputs and outputs is mostly used to determine the proper multipliers and dividers. The DCM does have an attribute for the input clock frequency, though, so the input frequency specified by the wizard is stored in the DCM.

The clock wizard information does not influence to the constraint mechanism (well, sort of). For static timing analysis, the constraints are taken from the UCF file. When a PERIOD constraint reaches a DCM, ngdbuild uses the PERIOD constraint and the multipliers and dividers of the DCM to determine the clock outputs.

So, the tool doesn't know the input clock frequency of the DCM from the clocking wizard, it knows it from the PERIOD constraint on the input clock.

I believe that ngdbuild does do a check between the input clock frequency specified by the PERIOD constraint and the one specified to the clocking wizard - but if they don't match, then it issues a warning (not an error).

Avrum

[doovie]

Thank you so much, Avrum!