Using Vivado create_generated_clock

[btremaine]

I'm fairly new at FPGA code and am trying to develop Verilog code for a Basys 3 board using Vivado. For several days I have struggled with getting the 'create_generated_clock' command to work. I have a large program but reduced it to a simple divider and want to declare the Q output of a DFF as a generated clock. The program passes behavioral sim with a test bench as well as synthesis and implementation with no errors. A warning in the Report Methodology reports 'TIMING #1 Critical Warning The clock pin Led_reg.C is not reached by a timing clock'

The clock commands I have in my XDC file are:

create_clock -period 10.000 -name sys_clk -waveform {0.000 5.000} -add [get_ports CLK100MHZ]
create_generated_clock -name Q_out  -source (get_pins Q_out_reg/C )  \
                       -divide_by 8 (get_pins Q_out_reg/Q )

The ultimate source is the CLK100MHZ coming in on an external pin.

 

Do I have an error in my command for create_generated_clock?

    My intent was to specify Q_out as the generated clock and CLK100MHZ as the source, but I have some confusion in using Vivado to identify the net, source, or port to use in the command.

Using the TCL command report_clocks shows only the 100MHZ clock;

   Clock    Period(ns)  Waveform(ns)   Attributes  Sources
   sys_clk  10.000      {0.000 5.000}  P           {CLK100MHZ}

[zygot]

You have a few misconceptions going on here.

The create_clk and create_generated_clock tcl commands are for timing constraints, not generating physical clocks in a design.

In programmable logic, clocks are different than other signals in an HDL design. FPGA resources and routing resources for clocks are separate from other signal in a design. Most PFGA devices don't have on-board clock resources. So, a clock begins life in a clock module that is external to the FPGA and is connected by a clock-capable ( for Xilinx ) pin. From there it can be used to clock the user internal design logic or can go to an MMCM or PLL, which in turn can generate multiple output clocks that can be used in a design. This is how you should create a clock. You can use Verilog, System Verilog, or VHDL to instantiate a primitive or use the vendor IP; it's up to you. Until you know what you are doing, I'd suggest using the Clocking Wizard.

While you can create a clocked signal using a counter or divider, or whatever suits your fancy to create a logic signal that you may want to use as a clock for the purpose of clocking other logic this is a very very bad idea. Don't do it. The correct way to create a custom clock with a specific frequency is to use an MMCM or PLL. That's what they are there for.

Going back to your original tcl commands. Let's say that your FPGA has an external clock module that puts out a 100 MHz clock on a pin assigned the name sysclk. In your constraints file you can create a timing constraint that tells the tools some basic information about sysclk using the create_clock command. At a minimum the tools need to know period and duty cycle as your create_clock command does. Now, if you instantiate a PLL and run sysclk into the PLL and have the PLL create a 10 MHz clk_out that you name clk10, you can also use the create_generated_clock to create a new timing constraint for clk_10. If you use the Clocking Wizard, it will also create it's own timing constraints file in addition to yours with pertinent information. In recent version of Vivado, this can cause issues, or at least a warning that you are over-writing a timing constraint.

In order for the synthesis and routing tools to properly create an implementation and place it, it need basic timing information for the clocks that create signals in a deign.

Its possible to create a VIvado project and generate a bitstream using tcl but, except for constraints, an HDL is better for describing your design to the tools. Edited January 13, 2023 by zygot

[btremaine]

Thanks for your response. I am aware that the create_generated_clock is only for setting constraints for static timing. I considered using an MMCM but the IP generator wizard would not accept an output of 100kHz with an input of 100MHz. The minimum output allowed was very much larger (>1Mhz). In this case, is it feasible or even advisable to cascade MMCM's? Seems like a waste of resources. The 100kHz clock is used for a seven-segment LED display in which I'm using a 120Hz refresh rate. In this application, the jitter between the CLK100MHZ and the 120Hz refresh rate is not of important. I was trying to give the synthesis guidelines on the timing and avoid warnings of 'bad practice'.

Thanks,

 

[zygot]

33 minutes ago, btremaine said:

I considered using an MMCM but the IP generator wizard would not accept an output of 100kHz with an input of 100MHz.

MMCM/PLL resources have limitations on what they can produce from a given input clock.

There are a lot of ways to do what you want to do.

One way would be to find a clock-capable input pin and connect a 100 KHz clock to it. This might be a good idea if you needed a very specific clock frequency of exactly 107.2038 MHz. But there is a better approach.

You can clock your LED display logic at 100 MHz, or whatever the system_clock module for your board, or the derived global clock is. Then you can slow down the rate at which the logic gets updated by using enables in your logic. A typical way to do this is to use a counter clocked at the global logic clock frequency in your design as one process. In the processes for your LED display logic, you only change outputs when the counter count is a specific value. If the counter is allowed to overflow, you will get what's essentially an repeating enable strobe signal that your logic can use to slow down signal changes to any rate that you desire. This is different than using a clock enable signal, which actually prevents a derived clock from toggling. That is a technique for controlling power consumption for energy sensitive applications. Clock enables can be complicated and are not normally used in logic designs; but they do have their place. This technique can produce signals that have very odd duty cycles. If that's a problem, the there are easy ways to fix that.

Most modern FPGA device support clock enables. All programmable logic can be updated at an arbitrary rate that is slower than the clock frequency used to clock the logic.

If what I've said is confusing don't hesitate to ask more questions.

 

Edited January 13, 2023 by zygot

[btremaine]

UPDATE: My original problem was that I was not meeting the timing requirements with a 100Mhz clock in a 15-bit down counter, or even an 8-bit down counter. The total timing slack was about -4.5nsec. This was running the external pin 100MHz into a down counter. What I learned was that running the external 100MHZ into an MMCM with a 100MHz output routes the clock signal through a special 'array' optimized for clock timing. I used the MMCM 100MHz output to run my 15-bit down counter and now achieve a total timing slack of +6.07nesc. I did not need to generate 100kHz at the MMCM output; a 100MHz output with the down counter did the trick.

I also did not need to use the create_generated_clock command or create_clock command. I only used the pin assignment:

    set_property -dict {PACKAGE_PIN W5 IOSTANDARD LVCMOS33} [get_ports CLK100MHZ]

Thanks to all who contributed suggestions.

I would suggest reading the ug472-7Series_Clocking.pdf app note.

ug472_7Series_Clocking (1).pdf

[zygot]

I'm highly doubtful that any Series7 FPGA is going to produce failing timing paths for a 15-bit counter clocked at 100 MHz. I suspect that you problem is connecting and external clock source to a pin that doesn't support clock inputs. As you now realize, FPGA clocking resources are separate from logic resources. This includes routing and pin assignments. Use clock capable pins to bring an external clock signal into your design.

You are correct that understanding how your FPGA is designed and functions is a prerequisite to trying to implement a design in hardware. Read all of the User Reference Manuals related to the FPGA family that you are working with. At a minimum understand the architecture and have copies of the Clocking, IO, and CLB User Manuals handy in case you forget the basic rules that, if you follow, will allow your design to work.

Sometimes, you don't want to put an MMCM or PLL between your external clock source and whatever is clocking your logic design.

This comment isn't directed at you specifically: Modern FPGA devices are very complicated. When learning how to use particular features it's not uncommon to learn new things and draw the wrong conclusions about why what you did to change your design improved an aspect of how it function s in hardware. Getting going in the right direction will always be better than going in the wrong direction. As your designs get more complex your understanding will get sharper and the inferences that you draw will become more "correct". It's a journey of increments. By the time that you start thinking that you've mastered all there is to logic design a new device family will come along and there will be a new journey. Edited January 28, 2023 by zygot