Stats

  • Locked Locked
  • Replies 2
  • Subscribers 90
  • Views 3560
  • 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

Innovus ignores set_false_path constraint

FormerMember
FormerMember

Dear community

I have a design using several memories with an ECC block. There is a combinatorial path from the RAMs output to their own input through the ECC block (essentially a loop around the RAM). This path has no functional purpose und is never used in a meaningful way. Due to the large hold times of the RAMs, these loops always result in hold violations that Innovus cannot fix. Therefore, I would like to constrain them as false paths.

Each RAM consists of two blocks (left and right) each with a 39-Bit input bus (DR and DL), and a 39-bit output bus (QO and QL). In my SDC files, I use

set_false_path -from [get_pins my_mems/i0_RAM/Q*] -to [get_pins my_mems/i0_RAM/D*]

to constrain this.

Unfortunately, Innovus ignors this during timing analyses, i.e. it still reports hold violations on those paths. There is no error during the SDC file import and if I execute the command

get_pins my_mems/i0_RAM/Q*

in my Innovus shell, then I get the correct list of all 2x39 pins returned. Afraid that this might be a syntax problem, I also tried to explicitly write out all possible combinations, i.e. something like this:

set_false_path -from [get_pins my_mems/i0_RAM/QL[0]] -to [get_pins my_mems/i0_RAM/DL[0]]
set_false_path -from [get_pins my_mems/i0_RAM/QL[0]] -to [get_pins my_mems/i0_RAM/DL[1]]
set_false_path -from [get_pins my_mems/i0_RAM/QL[0]] -to [get_pins my_mems/i0_RAM/DL[2]]
...
set_false_path -from [get_pins my_mems/i0_RAM/QR[38]] -to [get_pins my_mems/i0_RAM/DR[38]]

This also does not work; Innovus still reports hold violations on those paths. Why is the tool ignoring those constraints? How to fix this?

  • Hi,
    you are not defining the startpoint of your paths correctly. Typically the startpoint is the clock pin of the launching cell.  With the following command you should see the proper startpoint of the path:
    get_attribute [report_timing -from [get_pins my_mems/i0_RAM/QL[0]] -to [get_pins my_mems/i0_RAM/DL[2]] -collection] startpoint

    You can then either use the startpoint pin, or use the cell in the exception. E.g.

    set_false_path -from [get_cells my_mems/i0_RAM] -to [get_cells my_mems/i0_RAM]

    -Dimo

  • FormerMember
    FormerMember in reply to DimoM

    Dear Dimo

    Thank you so much for your help. I can confirm that your solution works.

    In my case, the command get_attribute [report_timing -from [get_pins my_mems/i0_RAM/QL[0]] -to [get_pins my_mems/i0_RAM/DL[2]] -collection] startpoint simply returns my_mems/i0_RAM/CLK, which is the clock pin of the RAM. Thus, in my SDC file i set

    set_false_path -from [get_pins my_mems/i0_RAM/CLK] -to [get_pins my_mems/i0_RAM/D*]

    which resolves the hold violation problem.

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.