Spartan® Family FPGAs

[mahdi_harp]

hi

I am working  on a Nexis 2 broad (its FPGA is Spartan 3E 1200)

every things was OK until my project grown bigger and bigger, now when i finish compiling the project its occupied slice is something about 38% and i face whit poor performance of design,, it means that fpga some times doesn't do what i write in codes!!

i guess i have a poor management in clock resources. as when i check the Clock report,   see that one of my BufG clocks is routed as local clock (Despite its fanout is 190)

maybe there is some better ways of clock management that i am not aware of it. so i will be thankful if some one help me. i attach my own clock management an my clock report and waiting for your helps.

thanks a lot

Mahdi

my clock report:

and my clock management:

[gszakacs]

You have too many clocks.

I see no reason to have multiple clocks of the same phase and frequency.  A BUFG

is capable of driving every flip-flop in the FPGA with sufficiently low skew to have no

hold-time problems.  So start by dumping clk50MI, clk50MII.

Related clocks (in your case created with dividers) are best implemented using clock enables

instead of additional clocks.  So instead of creating a divide-by-4 whose output has 50%

duty cycle and drives a BUFG, make a divide-by-4 whose output is on for only 1 of 4 cycles

and use it as a clock enable while clocking the loads on the same clock as the input to

the divider.

In fact, all of the clocks in your block diagram (and there are more in the report) are related to clk200.

So ou could run the entire design on clk200 with clock enables.  Alternately you can place a BUFG

on each of the three DCM outputs: clkfx_out, clk2x_out, and clk0_out to make clk200, clk100, and

clk50 respectively.  These will all be in phase.  Then for all slower clocks that are a simple integer

division of clk50, run everything on clk50 with clock enables.  This may reduce power and help to

meet timing on the clock enable signal.

HTH,

Gabor

[mahdi_harp]

hi gszakacs

Thanks for your answer. as you said i start whit dumping Duplicated clocks (such as Clk50MI and Clk50MII)

but i have 2 questions:

 
1- if i use  Clk50M in many modules , its fanout is grown up (maybe here it reaches 500) doesn't this make some problems?? and totally how much is upper limit for a clock fanout??

2- what is the clock enable exactly?

as i understand it is a kind of divider but not whit 50% cycle.. if this was your purpose i write a simple code for it. if you think it is OK tell me to use it in my design. if you had another purpose and i am misunderstood of "Clock Enable"  i will be thankful if you tell me what is the clock enable exactly

my simple code for clock enable:

always @(posedge Clk_In)
if(Count < 3)
 begin
  Count <= Count + 1;
 Clk_Out <= 0;
 end
else
 begin
  Count <= 0;
 Clk_Out <= 1;
end

[mcgett]

The global clock BUFG networks in FPGAs are dedicated resources and are capable of driving all clock loads in the device. There is no difference between a BUFG driving 10 registers and 1,000,0000 registers.

A clock enable is function that enables the clock and allows it to be used. There are two types in FPGA the first is on the global buffer BUFGCE that will enable the clock to propagate through the buffer to all destinations. The second is the local clock enable and is coded like this in Verilog.

always @ ( posedge clock)
begin
   if (ce) myreg <= mydata;
end

The code example that you posted was for a fabric based clock divider and his will cause timing problems in your design due to unknown phase relationships between the generated clock and the original clock.

[gszakacs]

Just to clarify what McGett is saying.  In the code you posted:

always @(posedge Clk_In)
if(Count < 3)
 begin
  Count <= Count + 1;
 Clk_Out <= 0;
 end
else
 begin
  Count <= 0;
 Clk_Out <= 1;
end

Clk_Out should not be used as a clock, but as a clock enable.  Perhaps it would be better to

re-name it ClkEna (or ce) to avoid confusion.  The above code is appropriate for use as

a clock enable as McGett showed in his post.

-- Gabor

[mahdi_harp]

Hi

thanks for your answers...it was very useful.
as i read your notifications and search web, i understand that there is 2 ways to use these "clock enables", first use BUGCE and second use this code:

always @(posedge Clk)
if(ce)
 begin
  myreg <= mydata
 end

So i write a simple code to drive a simple counter in each two ways, and i attach my schematic, if it is possible for you, mention me that if my designs of "clock enable" are correct or not

and if they are correct,i just want to know which of this two method of using clock enable is more suitable and lead to best performance of design

thanks a lot
Mahdi

[rcingham]

The lower one.

[gszakacs]

First, I want to second RCIngam on using the lower one.

I was not aware that BUFGCE is available on Spartan 3E. I thought it came later with the Spartan 6.

In any case, using the top schematic, while saving some power, will not reduce the clock buffer issues

you started with. When using a high frequency clock with a much lower frequency clock enable, you

should help the tools meet timing by adding multi-cycle constraints on the signals using the clock enable.

The clock enable itself must meet timing at the high clock frequency, and havinv a large fanout, this

becomes easier if you buffer it at each module.  Because it doesn't realy matter which of the 4 cycles of

your divide by 4 counter is used as the clock enable, a cheap way to buffer the clock enable locally at

each module is to use a flip-flop to delay the CE input by one clock.  As long as all modules use the

same delay, the circuit will run as intended.  Then the global CE only has one load per module, and the

local CE signals only drive the loads within a module.

Of course you can always let the tools try to meet timing at 200 MHz for all paths, but in Spartan 3E

this may be difficult to achieve.

-- Gabor

[rcingham]

> Then the global CE only has one load per module, and the local CE signals only drive the loads within a module.

Unless the tools decide to merge identical registers...

[gszakacs]

---

rcingham wrote:
> Then the global CE only has one load per module, and the local CE signals only drive the loads within a module.

Unless the tools decide to merge identical registers...

---

That's true, but the extra register pipeline delay makes it easy for the back-end tools

to re-replicate the signal when it doesn't meet timing :-)

-- Gabor