Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to avoid using clock trees in Zynq FPGAs?

Status
Not open for further replies.

msdarvishi

Full Member level 4
Joined
Jul 30, 2013
Messages
230
Helped
1
Reputation
2
Reaction score
1
Trophy points
18
Activity points
2,349
Dear all,

I am designing some ring oscillators implemented in a Zynq 7000 FPGA and I have designed a period counter in order to measure the frequency of each ring oscillator. The clock signal of period counter is the output signal of the ring oscillator. My period counter is a synchronous counter that means all of its D flip-flops change state at the rising edge of the clock signal.

My teacher said you HAVE TO come up with an Asynchronous period counter than a synchronous one since the number of clock trees in FPGA is limited and if you put for example 100 ring oscillators each individually connected to a period counter, you will see the problem of lack of the number of clock trees. First of all, is it correct??

He also says, you have to force Vivado (I use 2017.1 version) NOT TO USE clock trees in your design and you have to change your period counter to an asynchronous one designed with T flip-flops. Is it possible to avoid using clock trees in design by a command or constraint in Vivado? Can you please let me know how?

Also, my current period meter works very nice but I have no idea how to change it to an asynchronous by T flip-flops??!! Can anybody help me with those issues, please?

kind replies and help are in advance appreciated.

Regards,
 

My teacher said you HAVE TO come up with an Asynchronous period counter than a synchronous one since the number of clock trees in FPGA is limited and if you put for example 100 ring oscillators each individually connected to a period counter, you will see the problem of lack of the number of clock trees. First of all, is it correct??
there are only so many regional and global clocks in each clock region of the device (not going to look it up for you in the zynq documentation).

He also says, you have to force Vivado (I use 2017.1 version) NOT TO USE clock trees in your design and you have to change your period counter to an asynchronous one designed with T flip-flops. Is it possible to avoid using clock trees in design by a command or constraint in Vivado? Can you please let me know how?
probably use the -bufg 0 in the synthesis options. Tells the tool there are no bufg's available.

msdarvishi said:
Also, my current period meter works very nice but I have no idea how to change it to an asynchronous by T flip-flops??!! Can anybody help me with those issues, please?
pretty easy to find with a search...try that next time...
 

The FPGA has limited clocking resources. For example, a limit of 32 global clock buffers. It looks like the Zynq allows 12 BUFG and 4 BUFR connections per clock region. This limits the number of clocking resources to 32 + 4*Regions total clocks used.

That said, you might be able to increase this limit by some amount. The FPGA also has BUFIO -- these can clock IO resources like the ISERDES. This clock is intended to be routed to a BUFR for use beyond the IO. If the ring oscialltors are slow in comparison to the system clock, you may be able to infer the number of cycles the ring oscillator has performed using the ISERDES module and a LUT to form a johnson counter. This could increase the total number by 4*Banks.
 

How is the use of a clock tree meaningful for this experiment? I am lost.
 

How is the use of a clock tree meaningful for this experiment? I am lost.

Seems the OP is planning on having >100 ring oscillators in the Zynq and wants to put counters on all of them and is running out of clock domains (in the clock regions) in the FPGA.

Sometimes I don't get what the point of some of these university "designs" are.
 

Seems the OP is planning on having >100 ring oscillators in the Zynq and wants to put counters on all of them and is running out of clock domains (in the clock regions) in the FPGA.

Sometimes I don't get what the point of some of these university "designs" are.

Dear @ads-ee,

EXCELLENT !! You have conjectured correctly! That is my objective. Could you please help me out how to avoid using clock trees in this design??

Thank you,

- - - Updated - - -

there are only so many regional and global clocks in each clock region of the device (not going to look it up for you in the zynq documentation).

probably use the -bufg 0 in the synthesis options. Tells the tool there are no bufg's available.

pretty easy to find with a search...try that next time...

Dear ads-ee,

Thanks for your reply. Based on your hint, I have looked at the clock distribution in Zynq FPGA and I see the clock trees originate from BUFGs. So, if I understood your point correctly, probably we have to put a constraint on BUFGs in XDC file not to activate them and not the synthesis tool to exploit them. Am I right?

Thanks

- - - Updated - - -

The FPGA has limited clocking resources. For example, a limit of 32 global clock buffers. It looks like the Zynq allows 12 BUFG and 4 BUFR connections per clock region. This limits the number of clocking resources to 32 + 4*Regions total clocks used.

That said, you might be able to increase this limit by some amount. The FPGA also has BUFIO -- these can clock IO resources like the ISERDES. This clock is intended to be routed to a BUFR for use beyond the IO. If the ring oscialltors are slow in comparison to the system clock, you may be able to infer the number of cycles the ring oscillator has performed using the ISERDES module and a LUT to form a johnson counter. This could increase the total number by 4*Banks.

Dear @vGoodtimes,

Thanks for your reply. Really , I did not understood your point and explanation ! Can you please explain me in more details? Also the formula that you have said : "32 + 4*Regions" isn't it 12 instead of 32as you described?

Regards,
 

Thanks for your reply. Based on your hint, I have looked at the clock distribution in Zynq FPGA and I see the clock trees originate from BUFGs. So, if I understood your point correctly, probably we have to put a constraint on BUFGs in XDC file not to activate them and not the synthesis tool to exploit them. Am I right?

I already told you how to do this in post #2...
-bufg 0 in the synthesis options. Tells the tool there are no bufg's available.
This is done in synthesis it is NOT an XDC constraint.
 

My advice was based on the clocking guide. The FPGA is divided into a number of clock regions. Each region appears to have 12 BUFG nets and 4 BUFR nets. A more accurate version would be max(12*Regions, MaxBufgCount) + 4*Regions. The smallest devices could be limited to 12+4 or 24+8 BUFG+BUFR. Larger devices would have 32+4*Regions. I'm not certain if you can clock logic from fabric clocks without routing to a BUFG/BUFR. That is something you should determine first as that might allow more clocks. You are doing something that is not normally done in an FPGA. I'm not certain you can even source every clock buffer from independent fabric sources. I don't think I've ever needed more than one fabric-routed clock source in any design. Fabric-routed clocks are normally the result of a mistake during the design phase.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top