How to debug the remaining violations？

1) The remainning unfixable violation endpoints can be get by "-with_top_n" option on summarize commands:

xtop> summarize_path_violations  -with_top_n 100

xtop> summarize_gba_violations -setup  -with_top_n 10

Currently, after fixing, the left unfixed paths can be checked on GUI by timing inspection window (same as interactive eco) now. But GBA violations can't be shown in the same way now.

2) If you'd like to the detail reasons of why they are unfixable, you can try following commands:

If having paths,

xtop> report_fail_reasons -paths [get_paths -to $endpoint]

If no path,

xtop> report_fail_reasons -pins [get_critical_gba_paths -delay_type max -to $endpoint]

How to highlight all “fail_to_legalize” violations?

Try the command:

xtop> highlight_objects [get_failed_pins -reasons fail_to_legalize]

How to enable writing debug log for eco calculation?

Try the command:

xtop> set opt_log_level “debug_level”

How to debug when fix hold/leakage breaks setup margin?

1) The problem of break setup wns -50ps nvp 1000+ will be found when fix hold

2) It is found that there is no cell inserted by XTop in all the violation paths, indicating that there is no violation caused by insufficient evaluation of load or SI by the delay cell. The initial suspect is that the capacity of the driver of the cell is too weak or the distance of the legal is large. .

3) Take a worst path comparison and find thatthe arrival delay of register Q is too large. Compare the path before fix.After comparing the violation of match break, basically put the focus of debug on the starting point to this register.

4) I found that all the caps and transitions on the clock path have a slight change, which is -40ps overall, but the changes that occur on both launch and cap do not produce such a large violation.

5) It is found that the cap value of theregister Q is very large, and the change from 0.0015 is 0.023. Therefore, itseems that the net has changed a lot, so look at the winding in the PRdbs.

6) I found that the routing of this net haschanged a lot compared with the fix. Check the cell connected to the net andfind that the cellxtop_fix_timing is inserted by ice, and the distance from xtop_fix_timing to the driver is 25, and the pin of the ice inserted into the buffer is away. The distance of the driver is 2, and the line has a certain detour.

7) It can be determined that because the new buffer chain legal method causes the last insertion buffer to be too far away from the driver, the original net adds too much cap, and the original path is underestimated, resulting in a break setup. 

How to debug when 0 solution committed and all failed reason is “fail to legalize”?

1) Use the check_placement_readiness command to make sure that the design has been sourced and there is no error; the reason for the incomplete design may be that the lack of a certain cell's lef or def does not match the site defined in the tlef.

2) Check if there is a filler in the design.If there is a filler, there will be no space for optimization; if there is a filler in the design, set_removable_fillers command can be set to improve the situation.

3) Use report_placement_constraint to view the range of allowed cells and Max congestion, where Max congestion can't be less than 0.7, usually 0.8-0.9; ECO Inst Max Displacement at 16nm: 15-20Micros (up to 30Micros in later trimming); 12nm: 10-15Micros; 7nm: 10Micros or so, no more than 15Micros.

4) There may be a rule problem of advanced technology. You can view the situation by report_placement_context, record the data and send it to R&D for analysis.

How to report the violation fail reason on the path?

PBA

xtop> report_fail_reason -paths [get_paths]

GBA

xtop> report_fail_reason -pins [get_critical_gba_path]

How to debug fail points?

First check what causes the most fail, grab the corresponding cause's violated pin through get_failed_pins command, and then check the timing to do the corresponding operation.

Several commonly used debug parameters

xtop> set output_delay_change_script "true"

xtop> set new_si_amend "true"

xtop> set opt_log_level "debug_level"

xtop> set buffer_chain_dist_ratio 6

xtop> set si_critical_net_rank_ratio 0.05

How to debug XTop with gdb?

Command Mode

gdb program //The most common way to start the program with gdb, start debugging

gdb program core //use gdb toview the core dump file, the reason for tracking the program core

gdb program pid //use gdb to debug the program that has started running, specify pid

gdb attach pid //use gdb to debug the program that has started running, specify pid, then where

Interactive mode

Run          //run the program

Continue  //continue to run to the next breakpoint after the interrupt

Step         //single step execution, enter the function

Next         //Step by step

Return      //The function is not executed, ignore the unexecuted statement, and return.

Finish        //The function returns after execution.

Call           //call a function fun("1234")

(backtrace) bt  //display stack

Bt N          //display the beginning of the N stack

Bt -N         //display the last N stacks

(frame)f N //Show the Nth stack

List           //display source

Set directory //Set the working directory of gdb

Pwd          //current working directory

How to solve "Can not get valid routing layers for congestion calculation"?

1) Congestion check defaults to M2 to M5; the level that must be checked must have type routing and direction definitions in tech lef 

2) Check if techlef is missing, because the routing layer is defined by Type routing and DIRECTION from each layer in tech lef;

3) You can see if these layers exist in thelayer display setting on the right side of the layout interface. If it exists,the techlef read is normal;

4) If the techlef exists, checking each lef file for a certain level of duplicate definition may also cause this situation;

Why does inno* not find the corresponding cell when source a physical eco script?

1) Possible reasons: This is a bug in inno*. In some versions, there is no support for Hinstguide, so the cell that eco enters cannot be placed on the corresponding level according to this guide, so the latter cell has a problem. Inno* has another bug that adds extra needs after the cell name *_1 etc.

2) Debug method: This cell generally still exists, but it is placed at another level, or a serial number is added to the name, and the cell can be found by *matching.

3) Solution: Customers are advised to replace the version of innov*

Why does inno* source the netlist script will report a cell should use always on buffer error?

1) Possible cause: Power domain file is not read and cannot be recognized properly. power domain info A bug in inno* is that there is no support for Hinstguide on some versions, so the cell that enters the eco cannot be placed on the corresponding level according to the guide, resulting in a power domain judgment error.

2) debug and solution: Is there a power domain file, if not, let the client write the pd file from the PR dbs If there is a power domain file, it is possible that there is a problem with the level of inn* hinstguide, and the source of the reason is explained to the customer.

How to debug Setup timing fix?

1) Before running the fix setup command, enable the debug level mode: set opt_log_level “debug_level”. By setting the debug mode, you can view the execution of the brief file in the sta_log file under the named workspace file to find the bug.

2) Compare the timing result after the XTop fix setup with the result processed by the PT tool: compare the timing report before and after reading the eco script through the script of verify_slack_violated.pl that comes with the toolkit; output the .sum and .diff files after executing the script;you can see the timing changes before and after eco by looking at the .sum file. If there is abnormal data, you can use .diff to grab the exception points (The data changes,of max_transition, max_capacitance, min_delay, max_delay will be displayed at the beginning of the diff file. you need to focus on the data of the worn and unexpected, if it exists, you need to locate these pin names, grab it and analyze it).

3) For the comparison between the tools of XTop and the old ICE, you can use the methods of get_pins and fix_setup -only_pins to debug; for some pins, you can fix in the old ICE, and XTop is not processed in fix_setup_gba_violations. You can grab the part of the pin that has not been processed, and then use the get_pins method to fix it separately as the parameter of -only_pins. You can try to fix it by setting hold_margin appropriately. 

4) For the case where the WNS data is abnormal, the report_constraint command can be used to generate the timing report corresponding to the delay type in the PT. The end point of the WNS can be found through the report, and then the point is returned to the XTop, and reported by report_annotated_timing_data -pins... Execute the timing data before and after the fix setup to debug.

Commands about report fail reason

1) gba fail reason: get_hold_gba_violated_pins -endpoint_only/exclude_path

2) There is a -path_type option ("r2r", or "others") in get_paths command. You can use the get_paths -group -delay_type command to get the setup or hold violation path of the desired group

3) summarize_path_violation can be followed directly by the captured path, so that the summary timing of these paths can be reported; “-with_top_n n” can list n specific paths, including their slack, scenario, endpoints, and startpoints.

4) report_path command can report the path with the same format as read in.

Why is the ecoAddRepeateraction slow in the source eco script in inno*? (fix hold)

This is a bug in the inno* setEcoMode, you need to reset before setEcoMode. 

Also specify -write_atomic_cmd option in write_design_changes command to write an addinst, addnet, attechtermformat eco script to use.

When fix hold + fix setup, how can debug the fail reason of hold fix?

Since the fix setup is in the last round, the fix hold's fail reason is flushed out. 

If you need debug, you can open the save workspace, re-run the fix hold with the effort low, you can basically see the same fail reason as before.

How to debug fix hold cause a lot of setup break, while some points having margin?

1) First find the break_setup point through report_fail_reasons or GUI interface, you can see the setup and hold slack values at these points. If the positive value of setup is about the same as or smaller than the negative value of hold slack, then there is no doubt that it must be break. The positive slack value of the general setup is at least 3 times larger than the negative value of hold.

2) If you see that some sets of slacks are relatively large, the negative value of hold slack is relatively small, such as setup slack is 0.08, hold slack is -0.001, this seems obviously wrong. We have to wonder if the buffer list is not very good. For example, the smallest buffer with cell max delay is about 0.04, so even if you count the change of net and cap after inserting it, it is estimated to break. So you need to remind the user to change some buffers in the last round of small violation. The delay of the buffer is higher.

3) If the buffer list does not feel too much problem, this time we need to pick out a few points that we think can be repaired, but not repaired. Open the debug mode, give these points to the pin list, and then open the workspace/sta_log/brief_hold_*.log to see the specific try each buffer our calculation process. If there is something that is a little bit less break, you can see if you can loosen some setup margins properly, set the margin and target to 0 to fix.

Will it crash because of the manual deletion of the .lock file?

If you delete .lock and run XTop crash, you must have XTop using the current workspace. Because XTop will use OA, OA itself has file locks, which are more advanced than XTop's own locks. XTop's own lock can only distinguish between true and false on the same server, OA lock does not have this limitation, only one case can not be distinguished, it is rudely copied.

You can tell if the current workspace is actually locked according to the following conditions:

1. If it is a fixed server, xtoptells you that it is locked, and that is really locked.

2. If it is a bsub-like tool submission, delete the .lock and then open some simple operations (such as start gui) to crash, and stack points to the oa internal function, which means that the previous workspace is also really locked.

3. For the copy workspace, if the workspace is in the close state, copy will not be a problem; if it is in the open state, it is recommended to use save –as; if you want to rudely copy, in addition to deleting the lock of the workspace itself, you must delete all OA design inside the workspace. Lock (layout.oa.cdslock*)

How to debug when open_workspace crashed?

Make sure that the open workspace exists and the path and name are correct. Determine whether the crash is due to the tool. 

You can check whether the stack_fream file is generated; or check the error information in the corresponding log folder to determine the cause of the error.

====== 返回目录 ======

<<< 上一章：Write Design Changes

>>> 下一章：Others