UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
8,613 Views
Registered: ‎01-28-2010

High-speed Frequency counter application

Jump to solution

I am working on an FPGA application that involves measuring the frequency of high speed single-ended and differential clocks. For this I obviously need a counter clocked on the clock-to-be-measured, enabled for a precise time period. The highest clock frequency is 500MHz and will be using a S3A part.

I am planning on using an asynchronous counter (Q-to-C) large enough to count to 500*10^6. The input clock would directly drive the LSB T flip-flop. I see the following bottlenecks with this design: 

  • the input buffer needs to be able to handle a 500 MHz signal
  • the CLB clock timing

As far as I can tell, the input buffer just introduces a delay into my clock signal, which is not an issue. The CLB toggle frequency for a -4 part is 667 MHz, so I see no issue there either.

 

Since I will be using an asynchronous counter I will have to wait for the count to settle before reading it out, this is also not a problem. I will have to use asynchronous resets for the counter, but again, I see no downside to this.

 

My only issue is with the global clock buffers ISE insists on inserting into the clock path, when using a single-ended signal. Oddly, the differential clock for which I add an IBUFGDS primitive is not routed through a BUFG, the IOB output is routed locally to the CLB.

As far as I can tell, I don't need a BUFG and global clock route for the clock-to-be-measured. It will only have to clock a single SLICE, where the LSB is located, so local routing should be perfectly fine. Moreover, the BUFG on S3 parts seem to limit the clock signal to 334 MHz (FBUFG). Is there an easy way to tell implementation not to use global clock routing? Would using a CLK or a general I/O pin make any difference in this case?

Also, are there any holes in my design plan or things that I overlooked?

Message Edited by martinlmartinl on 01-28-2010 05:20 AM
Tags (4)
0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
10,964 Views
Registered: ‎08-14-2007

Re: High-speed Frequency counter application

Jump to solution

It's easy enough to tell XST not to add a BUFG.

 

Here's a Verilog example:

 

// synthesis attribute clock_buffer of in_clk is none;
 

Remember that your ripple-carry counter will have long delays to the MSB,

so first you need to clock enable only the LSB, and second you need to wait

for the worst case settling time after you stop the clock enable before you

use the count value.

 

My suggestion is to only use the asynchronous counter approach for the

first couple of bits and then make a synchronous counter that runs on

the divided clock.  1/8 of your maximum toggle rate should be no problem

for building a long synchronous counter.

 

HTH,

Gabor

-- Gabor
0 Kudos
4 Replies
Instructor
Instructor
10,965 Views
Registered: ‎08-14-2007

Re: High-speed Frequency counter application

Jump to solution

It's easy enough to tell XST not to add a BUFG.

 

Here's a Verilog example:

 

// synthesis attribute clock_buffer of in_clk is none;
 

Remember that your ripple-carry counter will have long delays to the MSB,

so first you need to clock enable only the LSB, and second you need to wait

for the worst case settling time after you stop the clock enable before you

use the count value.

 

My suggestion is to only use the asynchronous counter approach for the

first couple of bits and then make a synchronous counter that runs on

the divided clock.  1/8 of your maximum toggle rate should be no problem

for building a long synchronous counter.

 

HTH,

Gabor

-- Gabor
0 Kudos
8,589 Views
Registered: ‎01-28-2010

Re: High-speed Frequency counter application

Jump to solution

Thanks for the synth attribute, I will try it. The clock divider and synchronous upper-part is a good idea, it'd crossed my mind too.

One more thing: Would it make any difference connecting these clocks to CLK vs. I/O pins?

 

PS: Kösz, Gábor :)

0 Kudos
Instructor
Instructor
8,582 Views
Registered: ‎08-14-2007

Re: High-speed Frequency counter application

Jump to solution

If you don't want a BUFG on the clock input from the pin, then any I/O should be good enough.

At your frequencies you'll probably need to hand place the first flip-flop very close to the pin to

reduce effects of routing.  I would not suggest using the IOB flip-flop, which doesn't have as

good toggle rates as the fabric.

 

Good luck,

Gabor

-- Gabor
8,517 Views
Registered: ‎01-28-2010

Re: High-speed Frequency counter application

Jump to solution

I successfully managed to synthesize and place the design. The first FF is right next to the IOB and the next counter bits also nearby. BUFGs are not inserted, the IOB output is locally routed to the clock pin of the first FF.

I am having trouble though with constraining the design. In my understanding, I need the following constraints:

- PERIOD for the clock-to-be measured. This will make sure that the output of the first FF can get back to its input pin (T-FF) before the next edge arrives. The next FFs in the counter are not important, since if the first meets this constraint, it is safe to assume that the next ones (with twice the clock period) will also meet it.

- TIG between the counter FFs (running on the gated clocks of the previous FF) and the count readout FFs (running on the system clock). I will make sure that the readout happens only when all the counter bits settled.

 

The trouble is with the asynchronous reset of the count FFs. I absolutely need reset for these and since they have gated clocks, it needs to be asynchronous. It is correctly synthesized being connected to the CLR pins.

I produce this reset for one full system clock period (it is synchronous with the system clock, around 60 ns long pulse). However, I am getting the following constraint failure:

 

 Component Switching Limit Checks: TS_G5_CLKDS = PERIOD TIMEGRP "G5_CLKDS" 400 MHz HIGH 50%;
--------------------------------------------------------------------------------
Slack: -0.692ns (period - (min low pulse limit / (low pulse / period)))
  Period: 2.500ns
  Low pulse: 1.250ns
  Low pulse limit: 1.596ns (Trpw)
  Physical resource: frqCnt4<0>/SR
  Logical resource: Inst_FrqCnt4/cnt_0/SR
  Location pin: SLICE_X66Y39.SR
  Clock network: ctlTmrRst

 

It seems to me that ISE complains about the pulse length of the reset signal (Trpw) on the SR pin of the first FF driven by the clock-to-be measured. Again, the reset should be asynchronous to this clock and asserted to a full system clock period, which is larger than Trpw. Am I missing something here?

0 Kudos