1. Home
  2. Field-Programmable Gate Arrays
  3. Re: clock management on SPARTAN2

Re: clock management on SPARTAN2

Udayan wrote: : 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                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes
Loading thread data ...

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

Reply to
Udayan

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

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes

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:

Reply to
Aurelian Lazarut

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

Reply to
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

Reply to
Manfred Kraus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.