Re: clock management on SPARTAN2

SO I checked my design and removed the extra BUFG that was getting tagged to my divided clock output. However, since I would like to buffer my divided clock and the Synthesis engine automatically attaches a BUFG to the GCLKIOB pin input I am still left with one extra GCLK in my design being used up. Is there some way to get around that? Would a divide using the clk_dll still use up the extra GCLK resource?

Also when I do an edge test with my signal lines that arrive at regular IOBs and pass them through a BUFG the MAP report gives a warning that:

WARNING:NgdBuild:483 - Attribute "LOC" on "c_req" is on the wrong type of object. Please see the "Attributes, Constraints, and Carry Logic" section of the Libraries Guide for more information on this attribute.

What does this mean? I have tried looking up the Libraries Guide but without success.

Thanks

Udayan wrote: ... : SO I checked my design and removed the extra BUFG that was getting : tagged to my divided clock output. However, since I would like to : buffer my divided clock and the Synthesis engine automatically : attaches a BUFG to the GCLKIOB pin input I am still left with one : extra GCLK in my design being used up. Is there some way to get around : that?

Can't you use a Clock Enable and the original clock instead of the divided clock?

: Would a divide using the clk_dll still use up the extra GCLK : resource?

The DLL output will use a GCLK too, to my knowledge.

: Also when I do an edge test with my signal lines that arrive at : regular IOBs and pass them through a BUFG the MAP report gives a : warning that:

: WARNING:NgdBuild:483 - Attribute "LOC" on "c_req" is on the wrong type : of : object. Please see the "Attributes, Constraints, and Carry Logic" : section of : the Libraries Guide for more information on this attribute.

: What does this mean? I have tried looking up the Libraries Guide but : without success.

Perhaps you have an Output pin on a dedicated input or such. Recheck with the data sheet.

Bye

Udayan, Maybe you should try a different approach, like: state machine, with the running CLK some times faster than you fastest input signal, and be careful to add 2 (3) registers in the pipe for the inputs. only an idea... (depending how fast you want/need to sample)

Aurash

Udayan wrote:

Hi Uwe,

I sorted the GCLK problem out. Apparently if you use a clkdll it does not put a BUFG in front but an IBUFG and only the locked signal passes through a BUFG. That way the synthesizer does not infer a GCLK item for the input.

Still having trouble with the IOB warnings though....SOmehow the synthesiser has now concluded that they are GCLKIOBs but since they are not on the pins assigned for GCLKIOBs they are probably causing the trouble.

If you feel inspired and find an answer to my present query drop me a line.

Thanks

Udayan

Every signal, that is used in a " if rising_edge " (also falling edge) statement will be treated as if it was a clock signal. This means it gets a clock buffer by default. To avoid this, use IBUFs for the signals, you dont want to have BUFGs. . . component IBUF port(I: in STD_LOGIC; O: out STD_LOGIC); end component;

begin

-- force the usage of IBUF for Rd and Wr signals

-- Without the IBUF, XST uses an BUFGP by default.

U1: IBUF port map (I => Rd_in, O => Rd); U2: IBUF port map (I => Wr_in, O => Wr); . . .

Hint: You can replace the generic "IBUF" by a variant that meets your I/O Standard.

-Manfred Kraus

-mkraus

-at

-cesys

-dot

-com