Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 288 subscribers
  • Views 527 views
  • Users 0 members are here
Related

Maximum frequency xillinux

deaxman

Hi, I've heard it said that the maximum frequency that the zedboard can reach is dependant upon the quality of your code.  What does this mean?  If I am using the xillydemo.v file from the xillinux installation, how do I figure out what the maximum frequency is (besides trial and error) and how do I increase this maximum frequency?  Code "quality" is very subjective.  I feel that the maximum would be less dependant on efficiency of your code and more dependant on the number of resources that are being used.  Thanks!

  • 0

    Hi,

    There are certain FPGA design practices that help increasing the clock frequency that can be achieved. Most notably, adding pipelining registers (FIFOs) between combinatoric logic elements. The idea is to have as few steps of LUTs and other stuff between each pair of FIFOs, to minimize the settling time (so the next clock can arrive sooner).

    Finding the "maximal" clock is indeed a trial and error thing, with some implementation parameter tweaking coming along. You implement the design, asking for a certain clock in the timing constraints, and see how far you can push it until it fails. How to improve your situation is the subject of a two-day course given by Xilinx: "Designing for Performance".

    To get a general idea of where you stand, you can synthesize a specific module (and its submodules). There is a frequency estimation somewhere at the end of the report. To be taken with a grain of salt, but if often helps.

    Now to xillydemo: This module merely connects you with the Xillybus IP core through FIFOs. In the setting offered in the downloaded bundle, your logic runs on bus_clk, so the FIFOs only take a single clock. It's however common to use FIFOs with two clocks, one for each end (asynchronous FIFOs). If you do this, your logic can use whatever clock you want. So xillydemo isn't really a player here.

    I hope this gave an idea. Getting performance and reliability with proper clocking is what FPGA engineers get (well) paid for. ;)

       Eli

  • 0

    Thanks!  This answers pretty much everything!  When testing these clocks I would send them out of the pmod (w12) and check them with the o-scope.  At 250 and 300 (MHz) I still see the occilation but it doesn't get up to the 3.3v that one would expect.  Do this mean that this clock will also fail to register as a "high" on the internal logic or is it simply poor propagation through the pmod (I looked and see that the pmod vtc are not perfectly ideal, there are delays and attenuations)  It seems that if any ocillation can be seen then it must be going high and low within the logic and it's just having trouble when it tries to enforce that high or low on the pmod output.  I am using gclk or clk_100 which is the 100mhz internal clk.  What documentation should I look at to check this out?  I will look into taking the course, it sounds like a great option but it would be great if I could figure this out quickly and then come to a more long term solution through the course.  Thanks!!

  • 0

    Hi,

    The signals inside the chip are by far faster than those going out to copper wires on the board. 200-300 MHz are not high frequencies inside the logic fabric, even though it requires some skill to write logic that can work at this rate.

       Eli

  • 0

    What are some good resources I can look into regarding the clock rate to the copper vs the clock rate within the board?

  • 0

    For the maximal clock rate within the chip, it appears in the datasheet. More precisely, it's usually the maximal clock rate on the global clock wires. I would also suggest learning a bit about your device's clock resources in the User Guide for your device. I believe this is the relevant document:

    http://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf

    But odds are that the maximal clock is way too high to drive any useful logic with.

    As for the behavior of copper wire, that depends on the I/O standard, how well the PCB is crafted to support high frequencies (capacitances, reflections, you name it) and how you physically connect to the signal. And how low signal quality you're ready to tolerate. Plus, you can program the I/O block to drive the pin with different currents. And there are other considerations. In short, this is a bit of an art.

    Anyhow, the data sheet may also offer some hints on rise and fall times.

    Regards,
       Eli