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.

Critical warning of "No clock" received after implementation in Vivado

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 using Vivado 2017.1 targeting a Zynq-7000 clg484 Xilinx FPGA.

I have implemented a ring oscillator and a period counter circuit both implemented on the FPGA. My objective as a course project is to measure the frequency of ring oscillator using the period counter circuit. To do so, I connected the output of ring oscillator to the clock input of period counter directly without any buffer or something else, it is just a simple routing wire. Primarily in SYNTHESIS navigation menu in Vivado, I did right-click and set -bug to 0 avoid using clock trees in my design. (Default value for bufg was 12). After implementation, I saw that the registers of my period counter did not receive clock signal and I see the "No clock" critical warning as seen in the attached figures along with a closed view of registers without clock.

As the first guess, I thought maybe this is due to the bufg value that I already set to 0 in SYNTHESIS menu, so I changed it to its default value (12) and re-implemented my design. But still the problem exists and my period counter does NOT count anything !!!

Here is the message received by Vviado. The "xn_inferred_i_1" is the output of ring oscillator that is connected to the CLK pin of period counter module.

[Place 30-568] A LUT 'xn_inferred_i_1' is driving clock pin of 51 registers. This could lead to large hold time violations. First few involved registers are:
prd_contr/delay_reg_reg {FDCE}
prd_contr/p_reg_reg[0] {FDCE}
prd_contr/p_reg_reg[10] {FDCE}
prd_contr/p_reg_reg[11] {FDCE}
prd_contr/p_reg_reg[12] {FDCE}

Can anyone help me to solve this problem, please? I am in rush to finish this work and this crazy issue has stopped me !

Kind replies and helps are in advance appreciated.

Regards,
2.png1.png
 

Re: Critical warning of "No clock" retceived after implementation in Vivado

First you say the clock is not connected and then you show an error message saying its connected to 51 registers. Maybe your code (that is invisible ) is the problem.
 

Re: Critical warning of "No clock" received after implementation in Vivado

No clock probably makes sense. Either the tools need you to define something as a clock in the xdc, or the tools need to see a clock source somewhere in the clock tree. I don't know which one as I've always had defined clocks.

Because you are doing something that is more of a research project than a normal design, expect to have lots of warnings and for the tools to do the wrong thing.

- - - Updated - - -

No clock probably makes sense. Either the tools need you to define something as a clock in the xdc, or the tools need to see a clock source somewhere in the clock tree. I don't know which one as I've always had defined clocks.

Because you are doing something that is more of a research project than a normal design, expect to have lots of warnings and for the tools to do the wrong thing.
 

I think if a signal drives the input to a ff, it's considered a clock whether you define it or not.
 

Timing analysis can't derive a ring oscillator clock, you need to define it explicitly. Of course the frequency must be in acceptable range for core clocks. Did you calculate the expectable frequency?

I presume, a recent FPGA series like Zynq7000 has a feature to route the ring oscillator output to a local or global clock network.
 

Do notice that the msg mentions hold violations. The tool has no idea how to time this experiment of yours, and assumes you are violating hold on several flops.
 

I'm not sure if I mentioned this in your other thread.

If you don't use a global or regional clock buffer and use general purpose routing for your clock, then clock skew will be a problem and you will need to use a ripple T-FF counter if you want something that sort of works. But you'll have to disable the ring oscillator if you ever want to see a valid count value (the ripple propagation is probably longer than the clock period). I'm not entirely sure if you can route a clock like this without ever using a clock buffer (well I've never had an occasion where I needed to do such a thing).

I still think this is a ridiculous and probably totally useless experiment, which teaches students nothing about design.

I could understand if this was something involving process variation across the die, but then you would have to do something like another poster here was doing and use Tcl to generate the design, placement, and routing all by hand so the implementation of each ring osc/counter are identical across the entire die. So that any die process variations will be the major contributor to any differences. You would also want to run this on 100's of devices over many different lots to get any meaningful results.

Hence, this is useless (IMO) as a teaching aid.
 

I'm not sure if I mentioned this in your other thread.

If you don't use a global or regional clock buffer and use general purpose routing for your clock, then clock skew will be a problem and you will need to use a ripple T-FF counter if you want something that sort of works. But you'll have to disable the ring oscillator if you ever want to see a valid count value (the ripple propagation is probably longer than the clock period). I'm not entirely sure if you can route a clock like this without ever using a clock buffer (well I've never had an occasion where I needed to do such a thing).

I still think this is a ridiculous and probably totally useless experiment, which teaches students nothing about design.

I could understand if this was something involving process variation across the die, but then you would have to do something like another poster here was doing and use Tcl to generate the design, placement, and routing all by hand so the implementation of each ring osc/counter are identical across the entire die. So that any die process variations will be the major contributor to any differences. You would also want to run this on 100's of devices over many different lots to get any meaningful results.

Hence, this is useless (IMO) as a teaching aid.



Dear ads-ee,

Thanks for your reply and explanation. Based on your comments, since I am using a user-generated signal (the output ringing signal of ring oscillator) as the clock signal of my period counter, I instantiated a BUFG wher its input comes from output of ring oscillator and its output goes to the clock port of period counter. However, using a BUFG, did not solve the problem and still the regsters in period counter have no clock signal and that's why the period counter does not count anything !!!

Somewhere in your comments, you have talked about using asynchronous counter using T-flip-flops. Here is the code that I am using as a period counter that is so accurate in post PR simulation. This is a synchronous period counter. Can you please help me what modifications I must do to change it to a, asynchronous period countrer??

Thank you so much for your greate help.

Code:
-- Listing 6.7
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;


ENTITY period_counter IS
  PORT(clk, reset           : IN  std_logic;
           start, si        : IN  std_logic;
           ready, done_tick : OUT std_logic;
           prd              : OUT std_logic_vector(31 DOWNTO 0));  -- was  (9 DOWNTO 0)
END period_counter;



ARCHITECTURE arch OF period_counter IS


--mostafa
attribute KEEP : string;
attribute S    : string;
--mostafa



  CONSTANT CLK_MS_COUNT        : integer := 5;  -- 50000; -- 1 ms tick
  TYPE state_type IS (idle, waite, count, done);
  SIGNAL state_reg, state_next : state_type;
  SIGNAL t_reg, t_next         : unsigned(15 DOWNTO 0);  -- up to 50000
  SIGNAL p_reg, p_next         : unsigned(31 DOWNTO 0);   -- up to 1 sec    -- was  unsigned(9 DOWNTO 0);
  SIGNAL delay_reg             : std_logic;
  SIGNAL edge                  : std_logic;
  
  
  
  attribute KEEP of state_reg   : signal is "TRUE";
  attribute S    of state_reg   : signal is "TRUE";
  attribute KEEP of state_next  : signal is "TRUE";
  attribute S    of state_next  : signal is "TRUE";
  attribute KEEP of t_reg       : signal is "TRUE";
  attribute S    of t_reg       : signal is "TRUE";
  attribute KEEP of t_next      : signal is "TRUE";
  attribute S    of t_next      : signal is "TRUE";
  attribute KEEP of p_reg       : signal is "TRUE";
  attribute S    of p_reg       : signal is "TRUE";
  attribute KEEP of p_next      : signal is "TRUE";
  attribute S    of p_next      : signal is "TRUE";
  attribute KEEP of delay_reg   : signal is "TRUE";
  attribute S    of delay_reg   : signal is "TRUE";
  attribute KEEP of edge        : signal is "TRUE";
  attribute S    of edge        : signal is "TRUE";    
  
  
  
  
  
  
BEGIN
  -- state and data register
  PROCESS(clk, reset)
  BEGIN
    IF reset = '1' THEN
      state_reg <= idle;
      t_reg     <= (OTHERS => '0');
      p_reg     <= (OTHERS => '0');
      delay_reg <= '0';
    ELSIF (clk'event AND clk = '1') THEN
      state_reg <= state_next;
      t_reg     <= t_next;
      p_reg     <= p_next;
      delay_reg <= si;
    END IF;
  END PROCESS;

  edge <= (NOT delay_reg) AND si;

  PROCESS(start, edge, state_reg, t_reg, t_next, p_reg)
  BEGIN
    ready      <= '0';
    done_tick  <= '0';
    state_next <= state_reg;
    p_next     <= p_reg;
    t_next     <= t_reg;
    
	 CASE state_reg IS
      WHEN idle =>
        ready <= '1';
        IF (start = '1') THEN
          state_next <= waite;
        END IF;
      WHEN waite =>                       -- wait for the first edge
        IF (edge = '1') THEN
          state_next <= count;
          t_next     <= (OTHERS => '0');
          p_next     <= (OTHERS => '0');
			 ----- added by me
			 if (p_reg = "00000101111101011110000011110110") then
						p_next <= (others => '0');
						t_next <= (others => '0');
			 end if;
			 ------ end of added by me
        END IF;
      WHEN count =>
        IF (edge = '1') THEN              -- 2nd edge arrived
          state_next <= done;
        ELSE                              -- otherwise count
          IF t_reg = CLK_MS_COUNT-1 THEN  -- 1ms tick
            t_next <= (OTHERS => '0');
            p_next <= p_reg + 1;
          ELSE
            t_next <= t_reg + 1;
          END IF;
        END IF;
      WHEN done =>
        done_tick  <= '1';
        state_next <= idle;
    END CASE;
  END PROCESS;
  prd <= std_logic_vector(p_reg);
END arch;
 

However, using a BUFG, did not solve the problem and still the regsters in period counter have no clock signal and that's why the period counter does not count anything !!!
You have stated nothing that proves or disproves any claims about your circuit functioning. How was this "does not count anything" claim determined? Simulation, hardware? where? Are you sure your counter and your ring oscillator exists in the implemented design. Are there any signals getting removed in synthesis, in implementation?

msdarvishi said:
Somewhere in your comments, you have talked about using asynchronous counter using T-flip-flops. Here is the code that I am using as a period counter that is so accurate in post PR simulation. This is a synchronous period counter. Can you please help me what modifications I must do to change it to a, asynchronous period countrer??
This: **broken link removed**
as long as the first FF can toggle at the rate of the ring oscillator the rest of the FFs should also toggle correctly, but you have to stop the clock to read the output as each bit of the count has a Tco+Troute delay added to it. Once n_counter_bits*(Tco+Troute) >= Tperiod you can't read all the bits in the same clock cycle.
 

You have stated nothing that proves or disproves any claims about your circuit functioning. How was this "does not count anything" claim determined? Simulation, hardware? where? Are you sure your counter and your ring oscillator exists in the implemented design. Are there any signals getting removed in synthesis, in implementation?

This: **broken link removed**
as long as the first FF can toggle at the rate of the ring oscillator the rest of the FFs should also toggle correctly, but you have to stop the clock to read the output as each bit of the count has a Tco+Troute delay added to it. Once n_counter_bits*(Tco+Troute) >= Tperiod you can't read all the bits in the same clock cycle.


Dear ads-ee,

Regarding your question about proving the functionality of period counter and ring oscillator, when I have done an individual Post- PR timing simulation for ring oscillator itself and als, the period counter itself, the work and my period counter is so accurate somehow that a clock signal defined with 200MHz in the testbench for period counter (tb_priod_counter.vhd) is mesured by 199.999995 MHz with my period counter ! But when I put both ring oscillator and period counter together in a top file and I connect the output of my ring oscillator to the clock pin of period counter, I receive the former critical warning message that all registers in my 32-bit counter have no clock signal !! I do not know exactly WHY???

REgarding your link for asynchronous counter, thank you so much :)))
 

I receive the former critical warning message that all registers in my 32-bit counter have no clock signal !! I do not know exactly WHY???
Did you do as another on this thread suggested and apply a clock constraint to the output of the ring oscillator? You will have to use a set_generated_clock for that, which I think will require a virtual clock constraint as you need to specify a source clock. You will probably also need to set a false path for the ring oscillator loop as you don't want it trying to make timing around the loop.
 

Did you do as another on this thread suggested and apply a clock constraint to the output of the ring oscillator? You will have to use a set_generated_clock for that, which I think will require a virtual clock constraint as you need to specify a source clock. You will probably also need to set a false path for the ring oscillator loop as you don't want it trying to make timing around the loop.


I have done your sugestion and defined the output of my ring oscillator as a generated clock in XDC file as follows:

Code:
create_generated_clock -name osc_clk -source [get_pins ringosc/y] -multiply_by 1 [get_pins ringosc/y]

but still it fails in implementation step by providing the following critical warning message:

[Timing 38-285] Generated clock osc_clk with source pin ringosc/y does not have a valid master clock or valid waveform.

I do not know whwre i the source of this error message??!!
 

Re: Critical warning of &quot;No clock&quot; received after implementation in Vivado

You need to use create_clock and create a virtual clock to generate the master clock used by the create_generated_clock, that is why you have an error. You are trying to create a clock on a specific node in the design based on that same node being the master clock.

- - - Updated - - -

Actually after checking some sdc examples, you can probably get away just with create_clock on an input node of the RO.
 

Re: Critical warning of &quot;No clock&quot; received after implementation in Vivado

You need to use create_clock and create a virtual clock to generate the master clock used by the create_generated_clock, that is why you have an error. You are trying to create a clock on a specific node in the design based on that same node being the master clock.

- - - Updated - - -

Actually after checking some sdc examples, you can probably get away just with create_clock on an input node of the RO.


Dear ads-ee,

I still did what you means but it did not work again ! Here in the attachment i my design. Could you please have a look on it and see what can we do in order to solve this issue?

P.S. : in my top file (top.vhd you see an instantiation of a BUFG. I did it in order to interpret the output of the ringoscilator as a gllobal signal for clock pin of period counter, but evn with that the problem persist.

Thank you so much,View attachment pre_counter_plus_PCen_RO4L_3.tar.gz
 

Your xdc file is incorrect.

It should have the following lines:
Code:
create_clock -period 13.506 -name virtual_clk -waveform {0.000 6.753} [get_pins ringosc/inv/x]
set_property IOSTANDARD LVCMOS33 [get_ports prd*]
and get rid of the create_generated_clock.

These changes are based on the constrs_3 file.

You can't create a clock constraint on an output node it must be on an input, hence get_pins and the x input.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top