Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
Re: clock management on SPARTAN2
- 07-08-2003
- Uwe Bonnes
July 8, 2003, 7:25 pm

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

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

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:

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:

--

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
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
- » Re: scaling fixed point fft
- — Next thread in » Field-Programmable Gate Arrays
-
- » Re: About BRAM in VirtexII
- — Previous thread in » Field-Programmable Gate Arrays
-
- » Communist Chinese Military Companies
- — Newest thread in » Field-Programmable Gate Arrays
-
- » Gowin - This Just Got Real
- — Last Updated thread in » Field-Programmable Gate Arrays
-
- » Was man alles so ausrechnen kann ...
- — The site's Newest Thread. Posted in » Electronics (German)
-