How to report list of flops whose clock port is driven by test clock in test mode

 Try running "check_timing -verbose -view viewName". It will include a check to report clock pins which do not have a clock signal driving them.

 - Brian

Hi Brian,

Thanks for the reply.

check_timing only reports whether clock pins are driven by a clock signal or not. Is there a way to report which clock is being used?

What an awesome question this is - thanks for posting it.

Brian's note about the -view option on check_timing is applicable to get_property as well, which you could use to check which clocks are associated with each clock pin per view.  I created a tiny circuit to test this, with clka and clkb being muxed differently in view "a" and view "b".  You can query the clocks like this:

encounter 11> get_property -view a [get_pins i1/CK] clocks
clka
0x14

encounter 12> get_property -view b [get_pins i1/CK] clocks
clkb
0x16

To loop through all of the registers in the design and check you could do something like this:

foreach_in_collection register [all_registers] {
  foreach_in_collection pin [filter_collection [get_pins [get_property $register hierarchical_name]/*] {is_clock == true}] {
    set clk [get_property [get_property -view b $pin clocks] hierarchical_name]
    if {$clk == "clkb"} {
      Puts "Pin: [get_property $pin hierarchical_name] in view \"b\" is driven by \"clkb\""
    }
  }
}

Pin: i1/CK in view "b" is driven by "clkb"
Pin: i2/CK in view "b" is driven by "clkb"

Hope this helps!
-Bob

Hi Bob,

Thanks for the reply.

I tried your solution and I have few questions on it. 

encounter 6> get_property -view func_worst [get_pins pc0/vreg_ovp_reg_0/CKN] clocks

0x11692
encounter 7> get_property -view test_worst [get_pins pc0/vreg_ovp_reg_0/CKN] clocks

0x11694
 

I did not get clock name as in your case.

I tried the looping through the registers using your foreach loop and replacing correponding views and clock name.  For hierarchical_name i am assuming, i have to replace it with any instance name. This is what i had, but could not get it to run correctly.

foreach_in_collection register [all_registers] {
  foreach_in_collection pin [filter_collection [get_pins [get_property $register pc0]/*] {is_clock == true}] {
    set clk [get_property [get_property -view func_worst $pin clocks] pc0]
    if {$clk == "CLK5"} {
      Puts "Pin: [get_property $pin pc0] in view \"func_worst\" is driven by \"CLK5\""
    }
  }
}

When you have set clk[get_property...], the inner get_property gets the pins but what about the outer get_property? which property is it trying to fetch?

Hmm - that's strange that it appears to be returning a collection, but the name of the clock isn't echoed.

"get_proeprty [get_pins xxx] clocks" should get a collection of clocks.  To query the name of those clocks we need to:

get_property [get_property -view func_worst [get_pins pc0/vreg_ovp_reg_0/CKN] clocks] hierarchical_name

-or- if there are multiple clocks you could iterate through each like this:

foreach_in_collection clk [get_property -view func_worst [get_pins pc0/vreg_ovp_reg_0/CKN] clocks] {puts "[get_property $clk hierarchical_name]"}

"hierarchical_name" is an attribute off clocks and other objects alike so you shouldn't have to swap out hierarchical_name for instance_name.  The outer get_property returns the name, the inner get_property returns a collection.

Let us know how these suggests enlighten things and we can go from there.

Hi Bob,

I am using  Encounter v09.12-s159_1.

Thanks for the hierarchical_name explanation.

Since  the clk name is not echoed, I am assuming this command will not work on my side. For sanity check, I ran

encounter 2> get_property [get_property -view func_worst [get_pins pc0/vreg_ovp_reg_0/CKN] clocks] hierarchical_name
**ERROR: (TCLCMD-917):  Cannot find 'modules, library, library cell, library pins, ports, instances, pins, clocks, nets, paths, points or arcs collection' that match ''

Any suggestions?

Thanks again. 

I altered my testcase such that no clock gets to the pin in the b view and I see what you're seeing:

encounter 17> get_property -view a [get_pins i1/CK] clocks
clka
0x24
encounter 18> get_property -view b [get_pins i1/CK] clocks

0x26

A modification to the script could catch the cases where the clock pin doesn't receive a clock:

foreach_in_collection register [all_registers] {
  foreach_in_collection pin [filter_collection [get_pins [get_property $register hierarchical_name]/*] {is_clock == true}] {
    set clocks [get_property -view b $pin clocks]
    if {[sizeof_collection $clocks > 0]} {
      set clk [get_property -view b $clocks clk]
      if {$clk == "clkb"} {
        Puts "Pin: [get_property $pin hierarchical_name] in view \"b\" is driven by \"clkb\""
      }
    } else {
      Puts "Pin: [get_property $pin hierarchical_name] in view \"b\" is not driven by a clock"
    }
  }
}

Pin: i1/CK in view "b" is not driven by a clock
Pin: i2/CK in view "b" is not driven by a clock

Not sure that's going to pinpoint why the pins aren't receiving a clock.  You might want to check the report_case_analysis command for some insight into what's going on relateive to those constraints.

-Bob

 Hi Bob,

Thank you much for your scripts. This is exactly what i was looking for.

However i thing you meant  "set clk [get_property -view b $clocks hierarchical_name]" instead of "set clk [get_property -view b $clocks clk]". I had to modify that to get it working.

You are right about clock not getting to the pin for the missing clk names. I tried different register and i got the clk name back. 

Its working for me now ;-).

Have a good day.