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.

Prime Time mismatch on get_timing_paths and report_cell

Status
Not open for further replies.

matteof93

Newbie level 3
Joined
Jun 26, 2018
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
44
Hello, I am working on a script for PT Shell that must be able to swap cells in order to meet a leakage power constraint. The script works correctly and the idea is to get all the timing paths in the design and swap every cell in the path which has the maximum slack in order to possibly guarantee that the final slack will not be violated. If the constraint is met ok, otherwise continue with the next path.

I have a problem when I set a really "strong" constraint, let's say I want to save 50% of leakage. What I currently see is that in some cases I swap all the cells even in the most critical path, which by the way still has a positive slack, and so I reach a point where all cells listed in get_timing_paths (not directly by the command, of course) have been swapped to "low power" cells (LVT to HVT).

Now the problem is that when I run a "report_cell" command I still see many cells that have not been swapped to "low power" cells. Is it possible that the cells that can be extrapolated from the get_timing_paths command are not all the cells in the circuit?
 

My guess:
1. There is dont_touch attribute on those cells. You can not replace them. Please check it.
2. The "high power cell" are in the Violated path which is out of your target to replace.
 

My guess:
1. There is dont_touch attribute on those cells. You can not replace them. Please check it.
2. The "high power cell" are in the Violated path which is out of your target to replace.

Thank you for your help.
The dont_touch attribute is not set, I've just checked in the library. About the violated path: if I run a report_timing after swapping all the cells related to the points included in get_timing_path command I still get a positive slack so I should not have a violated path, right?

This is the command I use to get all possible paths (since I am new to Prime Time and I don't know how to get timing path with both positive and negative slack I use this big numeric value for slack option):
get_timing_paths -slack_lesser_than 9999999999 -max_paths 2000000

This is how I iterate through one of the paths to find cells, maybe I am missing something in the code...

Code:
# check if all cells in a path are mapped as HVT or not
        proc validpath {path} {
                # iterate through all points in path and for each point check if relative cell is HVT or LVT
                foreach_in_collection timing_point [get_attribute $path points] {
                        set cell_fname [get_attribute [get_attribute $timing_point object] full_name]           
                        # filter with a regexp to consider only correct cells
                        if {[regexp {^U.*} $cell_fname]} { ;# consider only U-cells
                                # remove unnecessary parts of the name
                                set mylist [split $cell_fname {/}]
                                set cell_name [lindex $mylist 0]
                                # get reference name of the cell
                                set cell_rname [get_attribute -class cell $cell_name ref_name]
                                puts "$cell_rname"
                                # as soon as an LVT cell is found return 1 (path is valid)
                                if {[regexp {_LL} $cell_rname]} {
                                        return 1        
                                }
                        }
                }
                # if we do not find any LVT cell we return 0
                return 0        
        }
 

Hello, I am working on a script for PT Shell that must be able to swap cells in order to meet a leakage power constraint. The script works correctly and the idea is to get all the timing paths in the design and swap every cell in the path which has the maximum slack in order to possibly guarantee that the final slack will not be violated. If the constraint is met ok, otherwise continue with the next path.

I have a problem when I set a really "strong" constraint, let's say I want to save 50% of leakage. What I currently see is that in some cases I swap all the cells even in the most critical path, which by the way still has a positive slack, and so I reach a point where all cells listed in get_timing_paths (not directly by the command, of course) have been swapped to "low power" cells (LVT to HVT).

Now the problem is that when I run a "report_cell" command I still see many cells that have not been swapped to "low power" cells. Is it possible that the cells that can be extrapolated from the get_timing_paths command are not all the cells in the circuit?

Can you explain what the purpose of your script is? The reasoning between using HVT/LVT cells is already built in the optimization tool, I doubt you will be able to do a better job than the tools already do.
 

Can you explain what the purpose of your script is? The reasoning between using HVT/LVT cells is already built in the optimization tool, I doubt you will be able to do a better job than the tools already do.
The purpose is to write a script for Prime Time that, given a design synthesized in Synopsys Design Compiler, can run a dual-vth optimization swapping cells from LVT to HVT in order to reduce the leakage power (the user must specify a "saving" value for the leakage).

This is a homework given to me by the professor of the Synthesis course at university. Anyway I realized, thanks to other people, that is pointless to pretend to get the list of all the cells in the circuit using the get_timing_path because in a real environment we have too many paths to consider. The get_timing_path seemed so useful because it can return the path ordered by slack. Slack is important because I want to reduce leakage paying as little slack as possible.

Anyway I found this workaround: foreach_in_collection pincollection [sort_collection [get_pins */Z] max_slack -descending]

It gives me a collection of pins and then I extract the cell. Then I start iterating on my list of cells to implement my solution...
 

The purpose is to write a script for Prime Time that, given a design synthesized in Synopsys Design Compiler, can run a dual-vth optimization swapping cells from LVT to HVT in order to reduce the leakage power (the user must specify a "saving" value for the leakage).

This is a homework given to me by the professor of the Synthesis course at university. Anyway I realized, thanks to other people, that is pointless to pretend to get the list of all the cells in the circuit using the get_timing_path because in a real environment we have too many paths to consider. The get_timing_path seemed so useful because it can return the path ordered by slack. Slack is important because I want to reduce leakage paying as little slack as possible.

Anyway I found this workaround: foreach_in_collection pincollection [sort_collection [get_pins */Z] max_slack -descending]

It gives me a collection of pins and then I extract the cell. Then I start iterating on my list of cells to implement my solution...

That's fine as an academic exercise I guess, but has zero real life applicability.

I would use timing reports, and work my way from there. You could even use hold timing reports to begin with [I will let you think about why].
 

matteof93
run man on get_timing_path and see if there is an option for slack greater than zero. I remember there is something like that.

Can you explain what the purpose of your script is? The reasoning between using HVT/LVT cells is already built in the optimization tool, I doubt you will be able to do a better job than the tools already do.

Thats not true actually, due to the fact that every optimization algorithm has threshold when it is stops optimization.

I wrote similar scripts for PT leakage optimization, since PT default engines for leakage reclaim are garbage.
 

matteof93
Thats not true actually, due to the fact that every optimization algorithm has threshold when it is stops optimization.

I wrote similar scripts for PT leakage optimization, since PT default engines for leakage reclaim are garbage.

Leakage reclaim is one of the easiest optimizations there is, specially if libraries are footprint compatible. Are you sure PT wasn't trying to satisfy another constraint and therefore did not perform all that you wanted?
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top