Re: clock management on SPARTAN2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
: Hi,

: I am having trouble with the GCLK feature in my design.

: Basically my code is a 4 way handshaking protocol between my PC and
: the FPGA on one hand and another 4 way handshaking with an
: asynchronous chip on the other.

: I am providing a clock to the system through the GCLK0 pin using an
: oscilltor.

: I further require edge tests on three lines that I receive from the
: computer and the chip - which means they are inferred as clock
: signals.

: A total of 4 clocks.

: However when I try to implement the design the engine complains that
: my design is too large

: Number of GCLKs:                   6 out of      4   150%
: Number of GCLKIOBs:                1 out of      4   25%

: I cannot understand why this is so. I take the input from my CLKIOB

Look at the synthesis report (*.syr) and at the graphical representation of
your circuit ("View RTL Schematics").  It will give you a glimpse of what is
going on. Then rethink the way you wrote your HDL implementation. In the
synthesis report, the "Clock information" might be the most important
thingto look at.

Bye
--
Uwe Bonnes                 snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
We've slightly trimmed the long signature. Click to see the full one.
Re: clock management on SPARTAN2
Quoted text here. Click to load it

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

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?

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

--
Uwe Bonnes                 snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
We've slightly trimmed the long signature. Click to see the full one.
Re: clock management on SPARTAN2
Quoted text here. Click to load it

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

Re: clock management on SPARTAN2
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:

Quoted text here. Click to load it

--



Re: clock management on SPARTAN2
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





Site Timeline