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

...
: 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

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

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:

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