At what frequencies is it acceptable to generate a clock from a register?

How would one best judge when it is acceptable to generate a clock from the outputs of an internal register instead of using the standard blocks such as DCM's? My design will go onto an XC2V8000-5 part, and I'd like to use registers to generate up to a 10MHz clock if that is alright. Any information would certainly be appreciated. I am basically trying to save DCM's for the low frequency clocks if possible.

Reply to
bwilson79
Loading thread data ...

The DCMs have a somewhat restricted frequency range. Take a look at the "DCM Timing Parameters", and particularly the "Operating Frequency Ranges" in the Virtex2 data sheet.

Reply to
Duane Clark

The short answer is simply when it can be guaranteed that all flip flops that receive and are clocked by the 'register generated clock' will meet all timing requirements.

For FPGAs, what generally ends up happening when you generate a clock signal from some internal register is that the clock to output delay of the flop plus the routing delay to get that clock to wherever it is you want to use it, causes too much skew on that clock signal relative to the other inputs to the flip flop and those inputs violate setup or hold time requirements.

Within the FPGA world, generally the best approach is to use that 'register generated clock' not as a clock signal but as a clock enable to the flops. If you're starting from scratch, it's usually not a problem to write the code in that fashion. If you're starting from pre-existing IP you would have to modify that code to insert the clock enables on every clocked process/component.

KJ

Reply to
KJ

Judging by the size of part, I'm guessing you're doing ASIC prototyping. Generally there is no difference in the frequency the part can handle between DCM generated or other clocks. In any case the important thing is to use the BUFG or BUFGMUX to drive all of the clock loads on the net.

That being said, If you're generating multiple clocks related in frequency and you need the clock edges to be coincident, the DCM can get your skew into the range where the clocks are somewhat usable. However it is generally safer to run the global clock nets at the higher frequency (least common multiple) that the clocks were generated from and use clock enables to get the frequencies you need.

By the way 10 MHz is generally considered very slow in the Virtex 2 world, but I'm guessing you're looking at logic with many levels of gating between clock edges. You generally won't have problems with the speed of the clock, but with multiple clocks you need to be careful of the relative phase, since the routing delays before the global buffers can be significant, leading to hold-time violations.

If your clocks are considered asynchronous for the design usage (whether or not you use a common frequency source to generate them), then you don't really need to worry about the routing delays up to the global buffers. Then you just need to make sure you have enough clock routing resources for all the quadrants.

Reply to
Gabor

Reply to
Peter Alfke

Yeah, my chips are failing timing with huge scores and I'm seeing many nasty hold time violations. I'm driving my counters with outputs from BUFG's, so I'm not exactly sure what's going on. I originally tried a

7-DCM approach, but ran into problems because I can only have 6 of them on a single side of the die, and in one case they need to be cascaded unfortunately. Now I'm generating most of the clocks with DCM's except for 4 of them that are under 10MHz. My current design uses a total of 3 DCM's and 6 BUFG's, and I've LOC'd everything down to the bottom half of the die. I have 2 6:1 muxes implemented in normal logic in which case 4 of the inputs are clocks from DCM's and 2 are from my registers. I then run the output of the muxes to a BUFG. Any help would certainly be appreciated because I'm honestly running out of things to try. I'd be willing to share my current implementation if that would help.
Reply to
bwilson79

You obviously think you need all these different clocks. But it might help to be self-critical... And to what extent does the logic interact across clock boundaries? That's most likely your problem (hold-time violations). To what extent are your clocks totally asynchronous to each other, or are they just divided by integers? Peter Alfke

Reply to
Peter Alfke

colleague with more knowledge, it seems that the clocks can be safely treated as being asynchronous to one another. It also seems that all these different clocks are needed to avoid major logic changes. I was hoping that I could add both period and cross-clock constraints w.r.t. the outputs of the 4 BUFG's and also include 'DATAPATHONLY' on the cross-clock constraints and be done with it. However, the timing analyzer looks like it's analyzing more paths because of the 6 "clocks" going into my MUX before the BUFG. I tried doing a TIG on the inputs to the 2 BUFG's after my logic MUX, but that was bad in that more things than I intended were placed in this TIG in the analysis. The system has 4 clocks but I don't think I'm constraining it properly. Below is a simple diagram of my setup. You'd want to view this ugly diagram definitely with a fixed-point font. The reg clk's I show in the diagram are generated from the 40 BUFG and 60 BUFG respectively.

(40 out) (80 out) | | | | DCM_0 | | | ------------------ | | |--->|FB 0 |--40--|---|------------------

| | | | |

40 ----|------>|IN 2X |--80------|------------------

| | | | 6:1 | | | DV |--20-------------------------

| | | | |-------> Selectable clock 1 | | FX |--120----| |-----------10---

| ------------------ | | | | | | | reg clk 5 ---

| |----------------------| | | | | | | | | | reg clk 2.5 ---

| | DCM_1 | | | | | ------------------ | | | | |--->|FB 0 |--40--| | | | | | |--|-------------------------------------| |------>|IN 2X | | | | | | | | | | DV |--10-----|--| | | | | | | FX | | |----------

-----------| | ------------------ | | | | | | DCM_2 | | | |

------------------ | | | |-->| FB 0 |--60--|--| |----->|------| | | | | | | |---120-->| IN 2X | |--------->| | | | | 6:1 | | DV |--15--------------->| MUX | | | | |------->

Selectable clock 2 | FX |--30--------------->| |

------------------ | | (CLKIN_DIV_BY_2) reg clk 7.5 --->| | | | reg clk 3.75 --->|------|

Reply to
bwilson79

I would run the whole design on the 120 MHz clock, and then use a synchronous divider (counter + decoder) to enable the various sections appropriately. That way you have a synchronous design, no hold-time issues, and you don't have to worry too much about the distribution delays. This is going to save you a lot of headaches. You could of course also run most of the circuit on a 40 MHz clock in a similar fashion. Everything to avoid your clocking mess... Peter Alfke

Reply to
Peter Alfke

Here's one thing I'm trying to figure out. I'm using my same clocking module and building two chips, one with much more utilization than the other. The constraints are the same in both builds. The less utilized design shows only 4 clocks as expected when looking at the clock report section of the .par file. However, the more utilized design shows those 4 as well as several clocks showing up as "local." Can someone please explain what this means? I've copy-pasted both clock reports below.

************************** Generating Clock Report **************************

+---------------------+--------------+------+------+------------

+-------------+ | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)| +---------------------+--------------+------+------+------------ +-------------+ |DataConv1xClock40Out | | | | | | | | BUFGMUX5S| No | 16 | 0.287 | 2.406 | +---------------------+--------------+------+------+------------ +-------------+ |DataConv2xClock80Out | | | | | | | | BUFGMUX3S| No | 5 | 0.156 | 2.338 | +---------------------+--------------+------+------+------------ +-------------+ | PHYClock4xOut | BUFGMUX1S| No | 47 | 0.304 | 2.494 | +---------------------+--------------+------+------+------------ +-------------+ | PHYClock6xOut | BUFGMUX6P| No | 47 | 0.366 | 2.494 | +---------------------+--------------+------+------+------------ +-------------+

************************** Generating Clock Report

**************************

+---------------------+--------------+------+------+------------

+-------------+ | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)| +---------------------+--------------+------+------+------------ +-------------+ |dcm_80_to_20_and_100 | | | | | | | _0_CLK0_OUT | BUFGMUX1P| No | 1644 | 0.784 | 2.696 | +---------------------+--------------+------+------+------------ +-------------+ |interFPGA_fixed_80MH | | | | | | | z_clk | BUFGMUX6P| No | 288 | 0.499 | 2.535 | +---------------------+--------------+------+------+------------ +-------------+ | clk_120_MHz | BUFGMUX4S| No | 1389 | 0.562 | 2.608 | +---------------------+--------------+------+------+------------ +-------------+ |filter_fixed_40MHz_c | | | | | | | lk | BUFGMUX7S| No | 1869 | 0.455 | 2.613 | +---------------------+--------------+------+------+------------ +-------------+ | clocks_1_clk1 | BUFGMUX5P| No | 6286 | 0.785 | 2.697 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_1 | Local| | 7419 | 6.832 | 8.947 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_11 | Local| | 250 | 1.244 | 7.358 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_10 | Local| | 254 | 2.044 | 7.111 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_2 | Local| | 289 | 2.028 | 7.566 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_14 | Local| | 246 | 5.646 | 8.785 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_13 | Local| | 251 | 1.938 | 8.431 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_6 | Local| | 257 | 2.709 | 7.238 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_9 | Local| | 254 | 1.280 | 6.727 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_3 | Local| | 248 | 2.161 | 4.204 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_7 | Local| | 246 | 1.016 | 6.781 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_5 | Local| | 252 | 1.316 | 5.791 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_8 | Local| | 237 | 1.117 | 7.405 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_12 | Local| | 239 | 2.247 | 7.950 | +---------------------+--------------+------+------+------------ +-------------+ |VariableBWClockGenVi | | | | | | | rtex2_inst_4 | Local| | 236 | 3.172 | 5.255 | +---------------------+--------------+------+------+------------ +-------------+ |phycore_with_mpi_ins | | | | | | |t/phycore/tx_top_ins | | | | | | |t/legacy_preamble_in | | | | | | | st.sym_count(2) | Local| | 10 | 0.007 | 1.496 | +---------------------+--------------+------+------+------------ +-------------+
Reply to
bwilson79

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.