routing input clock to an output global clock pin

[spman]

Hello
I want to forward the clock of design (entered from a GCLK) to output of the FPGA(Spartan3).
When i use this code :

module Top(ClkIn, ..., XClk);
	input	ClkIn;
	output	XClk;
	
	assign	XClk = ClkIn;

	always	@(posedge ClkIn)
		...
endmodule

The post rout simulation gives x (unknown) for XClk ! i checked the FPGA Editor. the XClk net is directly routed from ClkIn Pin without passing from a BUFG. so i used this one:

module Top(ClkIn, ..., XClk);
	input	ClkIn;
	output	XClk;
	
	wire	Clk;
	BUFG	BUFG_Ins(.I(ClkIn), .O(Clk));
	assign	XClk = Clk;
	
	always	@(posedge Clk)
		...
endmodule

but after implementation this warning is given :

WARNING:Route:455 - CLK Net:XClk_OBUF may have excessive skew because 0 CLK pins and 1 NON_CLK pins failed to route using a CLK template.

and likewise the state of XClk in post route simulation is unknown!

help me please
thanks

 

[mrflibble]

Use a DDR output as your clock output. Feed it a '1' and a '0' on the two DDR inputs, and then use the XClk as the clock input. Et voila, Q is clock output. It even comes with the added bonus of making it easier to align your clock output with any data output you might have.

So something like this:

OFDDRRSE OFDDRRSE_example_clock_output (
    .Q  (CLK_OUTPUT_PIN), // Data output (connect directly to top-level port)
    .C0 (clk),       // 0 degree clock input
    .C1 (~clk),      // 180 degree clock input .. derived from 0 degree clock. should work for spartan-6
    .CE (1'b1),            // Clock enable input
    .D0 (1'b0),            // Posedge data input ... "Q" output is 180 degree version of "C0" + IOB delays
    .D1 (1'b1),            // Negedge data input ... also see xapp606.pdf
    .R  (1'b0),            // Synchronous reset input
    .S  (1'b0)             // Synchronous preset input
    );

This is from a spartan-6 design, but the same idea applies to spartan-3.

 

[permute]

This warning is given because the global clock buffers, as well as the output buffers, both incur some delay. In fact, for high speed designs there may be a delay of more than one clock cycle!

mrfibble's method is generally good for the application of sending out a clock aligned with data that has also been registered in the IOFF's (IOB attribute on a registered signal, ODDR, OSERDES, etc...).

The output clock will not necessarily be aligned to the input clock. If such an application is required, look into using the DCM (PLL/DLL/etc...) modules as well as any PCB changes required for a given clocking mode.

I'm not sure why simulations give x's. There may be some other issues.

 

[spman]

I haven't worked with DDR till now and don't have enough time.
Is it the only solution? :sad:
Alignment of the clock isn't necessary. i just want to supply clock of a module that is outside of the FPGA. In other words i haven't any oscillator for my module and i want to use the oscillator that is on the FPGA board.

 

[mrflibble]

In other words i haven't any oscillator for my module and i want to use the oscillator that is on the FPGA board.

I assume from your approach the only reasonable way to get at the oscillator is through the fpga? Anyways, like permute said, the warnings are because of delays. If you want to get rid of those you can add an entry to your .UCF file.

# UCF entry to Timing IGnore the XClk signal, to prevent those pesky warnings
NET "XClk" TIG;

Add that in your ucf and you should get rid of the warning. Might even change the routing a little, it depends. But since you're familiar with fpga editor that's easy to check.

The simulator giving X's sounds more like an initialization error in the testbench... Did you give the Clk register in the testbench an initial value?

Either way, if you haven't fixed it yet, for the X's problem best to post the testbench + a screenshot of the signal with the X's...

---------- Post added at 17:27 ---------- Previous post was at 17:09 ----------

Also, a DDR output register like this really isn't hard. If you ever have hand instantiated an IOB FF, then you have already done the "hard" part. The only difference is 2 data inputs and 2 clock inputs. And IIRC spartan-3 doesn't have local clock inversion, so that would mean having to go through a DCM to get clk_0 and clk_180.

All in all, if you don't have data going out then just do what you were already doing. Only real problem as far as I can tell is fix the testbench...

reg ClkIn; // I am assuming you have something like this in the testbench

initial begin
    ClkIn = 0; // If so, don't forget to initialize it like this...
end

// generate clock
always begin
    #100 ClkIn <= ~ClkIn;
end

Anyways, something like that... Hope that helps.

 

[spman]

Thanks for your attention mrflibble,

The testbench is right like your code. The clock and all of the design functionally work properly in behavioral simulation. The XClk is "X" only in post-route simulation! I attached the screenshot


Also that crazy warning is remaining even after adding "NET "XClk" TIG" into the UCF file!

i haven't instantiated an IOB FF till now. Where can i find the key words and parameters for hand instantiation of elements?

Regards

 

[mrflibble]

Strange that the XClk is X in that case. Are you sure you are not getting warnings during simulation? *takes another look at screenshot* AHA! So, what do you think your Clk clock period is? In that screenshot I count about 7 Clk periods in 300 ps, so that's in the 23 GHz ballpark. I think you may have lost a factor of 1000 somewhere. Probably you are specifying a ps timescale, and then actually using ns numbers.

So I'd say multiply that #.... number in the #... Clk <= ~Clk by 1000 and try again. I would have expected it to give some simulation warnings though, since you are violating the input timings of the BUFG. Oh, and also be sure you use the right signal there, because in your first post the INPUT to the "Top" module is named "ClkIn", and not "Clk". But you know your testbench better than I do... Anyways, apply factor of 1000 and it just might work.

As for instantiation, you can find that in the Xilinx Spartan-3 Libraries Guide for HDL Designs.

The OFDDRRSE element is on page 138.

Hope that helps!

 

[spman]

Wow !!
I forgot to define timescale !! i always use ns timescale...

thanks mrflibble
best wishes for you