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!

Showing results for 
Search instead for 
Did you mean: 
Scholar helmutforren
Registered: ‎06-23-2014

I don't understand no_clocks

I'm using Vivado 2017.1.


I've pruned down to a very simple project (that happens to use a PicoBlaze processor).  On the Timing Report section for "no_clock", I get 267 High Severity warnings.

no_clock 20170811.jpg

and report_clocks gives me:

Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
| Tool Version : Vivado v.2017.1 (win64) Build 1846317 Fri Apr 14 18:55:03 MDT 2017
| Date         : Fri Aug 11 08:42:34 2017
| Host         : Madison running 64-bit major release  (build 9200)
| Command      : report_clocks
| Design       : Top
| Device       : 7k325t-ffg900
| Speed File   : -2  PRODUCTION 1.12 2017-02-17

Clock Report

  P: Propagated
  G: Generated
  A: Auto-derived
  R: Renamed
  V: Virtual
  I: Inverted

Clock   Period(ns)  Waveform(ns)   Attributes  Sources
SYSCLK  5.000       {0.000 2.500}  P           {SYSCLK_P}

Generated Clocks

User Uncertainty

User Jitter

Yet when I look at the clock_divide signal, it's obviously derived from SYSCLK_P, which is defined.  So what's up?


Archive of project is attached.  PLEASE IGNORE PROJECT NAME.  I reused an old stripped down project framework.


0 Kudos
3 Replies
Registered: ‎06-24-2013

Re: I don't understand no_clocks

Hmm ... what's going on here?

Parsing XDC File [M:/Nu-Trek/Src/Artemis_FPGA/TestNoClocks/IDELAYCTRL_error/.Xil/Vivado-12496-Madison/dcp3/Top.xdc]
CRITICAL WARNING: [Constraints 18-1056] Clock 'SYSCLK' completely overrides clock 'SYSCLK_P'.



-------------- Yes, I do this for fun!
0 Kudos
Guide avrumw
Registered: ‎01-23-2009

Re: I don't understand no_clocks

Your SYSCLK drives down through the hierarchy, and ends up (only) at the following process:


 clock_generation: process(clk200)
    if clk200'event and clk200 = '1' then
      clock_divide <= not(clock_divide);
    end if;
  end process clock_generation;

You then use clock_divide as the clock for the rest of your system.


The reason that you have this problem is that clock_divide is not a clock as far as static timing analysis is concerned; you have created a clock called SYSCLK, but it does not propagate through this "divider", and hence there is no clock object associated with the clock_divide network. Anything clocked on that, therefore is a no_clock.


So first. You should never use a fabric divider for a clock. When you do so, the phase of the divided clock with respect to any input or output signal or any other clock in the system cannot be determined. The clock will also have worse jitter characteristics than other clocks.


If you need to divide a clock, do it using a more supported mechanism - either using an MMCM or PLL, or using a BUFGCE.


Regardless of how you do it (including the fabric clock), you need to make sure that STA understands the divided clock. If you use an MMCM/PLL, then the tools automatically understand this - no extra constraints are required. If you use a fabric clock or a BUFGCE, then you need to tell the tools about this divided clock. This would be done with a create_generated_clock command.


For you fabric divider (which, again, I don't recommend), it would be done something like this


create_generated_clock -name divided_clock -source [get_pins Communications_Manager/CLUI/clock_divider_reg/C] -divide_by 2 [get_pins Communications_Manager/CLUI/clock_divider_reg/D]

It would be similar for a BUFGCE clock (although, without a constraint the BUFGCE will behave differently than this fabric divider without a constraint).



0 Kudos
Scholar helmutforren
Registered: ‎06-23-2014

Re: I don't understand no_clocks

@hpoetzl, yes I made a dumb error, but in fact correcting that didn't fix problem.  My latest build is still running.


@avrumw, thanks for that info.  Your answer make sense.  It's interesting, however.  I did *not* write that code that generates the divide_clock via fabric.  Ken Chapman @chapman did.  It's what you get with the PicoBlaze demo.  Hopefully my at-sign reference will draw his attention to this.  (Note: Ken has been a great help to me, so I'm not indicting him.  Just informing.  He may have an improvement already in mind.) 


There was fabric and then a BUFG.  I replaced the fabric with a BUFR(SIM_DEVICE => "7SERIES", BUFR_DIVIDE => "2") and it seems to work, as well as get rid of no_clock.  I'm currently coalescing into single BUFG, since PicoBlaze is small.  Yep, the BUFR alone works.  Please note this, Ken @chapman.


ALSO.  This leaves one more no_clock associated with jtag for the PicoBlaze.  Please help me follow through on this one.  I find "jtag_clk" in CLUI_PROGRAM.vhd.  I'm thinking I need to put a create_clock in my xdc file for jtag_clk.  I didn't write CLUI_PROGRAM.vhd; it got generated with more than just my .psm. Anyway, I find at the bottom that jtag_clk comes from jtag_clk_int, which seems to come from UPDATE?  I don't know vhd, just verilog, so I'm uncertain of the root.  I figure it must connect to hardware somewhere, and obviously it does NOT go through my top level.  should I add a create_clock in my xdc?  What should it look like?  Thanks.   I'm attempting the below, but I really don't know how to form create_clock.

create_clock -period 5.000 -name JTAG_CLK_INT_Z -waveform {0.000 2.500} [get_pins Communications_Manager/CLUI/program_rom/instantiate_loader.jtag_loader_gen/jtag_clk_int]

EDIT: Above didn't help.  See further below.


DARN.  This small project was supposed to help me figure out my big project no_clock, but I believe the issues are independent from one another.


EDIT: Remaining jtag no_clock: (new archive attached)

no_clock 201708111134.jpg


0 Kudos