How to NON_CLK pin that messes my clock

JL, The BUFGMUX is what's causing the warning. Try using the double data rate (DDR) registers in the IOBs to send the clock out instead. D0

In case it helps anyone, you can get the list of pins driven by a net just selecting the net and clicking Edit->Properties of Selected Items. You can even view the delay from the net to each pin.

Now my problem is that I only find 2 non-clk nets:

C15.I, reported as an "output", which is the driver pin where dsp_clk_a comes from, and BUFGMUX3P.I0 which is the clock that I export to an output pad of the Virtex-2.

I don't see why ISE complains about a non-clk net, can anyone explain me if I'm using BUFGMUX in a wrong way?

Thanks. JL.

Thanks Syms, it actually helped. This warning could not be ignored because it led my dsp_clk_a clock signal to be implemented as a local net, instead of a dedicated clock net. This induced a huge skew in the circuit. Now it works as expected (well, with other errors not related to this one...) :)

Thanks again. JL.

No, BUFGMUX is the component to the clock "enter" a global clock distribution line. Do you feed any output pin?

Yes jpdull, that's what I thought, and this was the instantation of my component:

i_br_clk_out_BUFGMUX : BUFGMUX_1 port map(O => br_clk_out, I0 =>

dsp_clk_a, I1 => zero, S => o_BR.output_nTri);

I replaced it with the following (as suggested by Syms):

i_br_clk_out_BUFGMUX : FDDRCPE port map( Q => br_clk_out, C0 => dsp_clk_a, C1 => not(dsp_clk_a), CE => o_BR.output_nTri, CLR => rst, D0 => '1', D1 => '0', PRE => zero );

Now it detects dsp_clk_a as a global clock using dedicated clock lines.

How can we explain that?

JL.

Sorry, I didn't mention that you'll find the aforementioned option in Xilinx FPGA Editor.

Why don=B4t you use a "BUFG" instead of "BUFGMUX"?

JP Dullius

Yes, I feed a clock output pin.

I tried with BUFG and BUFGCE and they don't work. I guess the reason is that they are only used to distribute the clock signal to synchronous elements, not to output pads.

For the moment, the only solution I found to work is the FDDRCPE suggested by Symon. I just wonder if there is anything simpler than that.

Regards. JL.

Yes, I feed a clock output pin.

I tried with BUFG and BUFGCE and they don't work. I guess the reason is that they are only used to distribute the clock signal to synchronous elements, not to output pads.

For the moment, the only solution I found to work is the FDDRCPE suggested by Symon. I just wonder if there is anything simpler than that.

Regards. JL.

Easier? Really, it is not that hard is it ;)

Anyway, you probably want to use the DDR method. There is no direct connection from the clock net to the output PADs, so what ends up happening if you don't use the DDR method is that the clock signal gets routed over some local routing paths. And the delay to the pad then depends on the pin getting routed to, and even can vary from one PAR session to the next.

Assuming you are also outputting some other signals (usually the case), you now have the problem of having an unpredicatable relation between the output clock and the other signals.

With the DDR method, the delay will never vary, regardless of the pin or PAR session. And the relation to other signals will be fixed; that is, one edge of the clock will almost exactly match the data transition, and the other edge will always fall almost exactly in the middle of the data.

Yes, I feed a clock output pin.

I tried with BUFG and BUFGCE and they don't work. I guess the reason is that they are only used to distribute the clock signal to synchronous elements, not to output pads.

For the moment, the only solution I found to work is the FDDRCPE suggested by Symon. I just wonder if there is anything simpler than that.

Regards. JL.