Stats

  • Locked Locked
  • Replies 1
  • Subscribers 62
  • Views 7280
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What does Constant hierarchical Pin(s) means in RTL compiler?

Bardia B
Hi everybody,

When I check the design in RTL compiler 10.1 after synthesis, I get the following summary for my design.

I know that Assigns are not good and should be removed before importing the design in SoC encounter and I know how to do it.

But my question is about the Constant hierarchical Pin(s). I don't know what those mean and if they are important? Should they also be removed before place and route? And how?


Name Total 
-------------------------------------------
Unresolved References 0 
Empty Modules 0 
Unloaded Port(s) 0 
Unloaded Sequential Pin(s) 0 
Assigns 83 
Undriven Port(s) 0 
Undriven Leaf Pin(s) 0 
Undriven hierarchical pin(s) 0 
Multidriven Port(s) 0 
Multidriven Leaf Pin(s) 0 
Multidriven hierarchical Pin(s) 0 
Multidriven unloaded net(s) 0 
Constant Port(s) 0 
Constant Leaf Pin(s) 3 
Constant hierarchical Pin(s) 297 
Preserved leaf instance(s) 0 
Preserved hierarchical instance(s) 0 
Libcells with no LEF cell 0 
Physical (LEF) cells with no libcell 27
 
Thanks in advance for your help.
 Bardia 

  •  Constant hierarchical pins are generally not a problem, but they are still worth investigating.  When RC propagates constants across hierarchical boundaries, it will tie the pin to 1'b0.  The other side of that hierarchical pin will have nothing attached to it.  It effectively becomes an unused hierarchical pin, but RC, by default, will tie it off so it is not undriven.

     What you need to do, to further investigate, is run "check_design -constant" and look at any constant hierarchical pins have a fanout greater than 0.  A fanout of 0 means that it is an unused hier pin, which is not an issue.  For example:

     

    design 'dtmf_chip' has the following constant input hierarchical pin(s)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_SE      (fanout : 5)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_TEST_ENABLE      (fanout : 4)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_IOTEST      (fanout : 1)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_TEST_CLOCK      (fanout : 1)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_INSTR_CAPTURE_2      (fanout : 1)
    /designs/dtmf_chip/instances_hier/JTAG_MODULE/pins_in/JTAG_POR      (fanout : 1)
    /designs/dtmf_chip/instances_hier/DTMF_INST3/pins_in/tdsp_pso      (fanout : 0)
    /designs/dtmf_chip/instances_hier/DTMF_INST3/pins_in/int      (fanout : 0)
    /designs/dtmf_chip/instances_hier/DTMF_INST2/pins_in/tdsp_pso      (fanout : 0)
    /designs/dtmf_chip/instances_hier/DTMF_INST2/pins_in/int      (fanout : 0)
    /designs/dtmf_chip/instances_hier/DTMF_INST1/pins_in/tdsp_pso      (fanout : 0)

     

    In this case, some of the JTAG_MODULE pins are tied off, which I expect, and all the rest of a fanout of 0.  No problems here.

     

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.