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.

[SOLVED] Design Compiler vs. Prime Time: Setup Violations

Status
Not open for further replies.

hbeck

Junior Member level 2
Joined
Aug 3, 2011
Messages
21
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,283
Activity points
1,419
Hi all,

I'm somehow confused. I synthesized my design (post-layout) with the Design Compiler and the setup timing was met. Without any knowledge of the subsequent clock tree insertion I assume the values for clock uncertainty, transition time and latency as listed below:

Code:
 set clk                   clk
 set clock_period          3.33 
 set clock_uncertainty     0.3
 set clock_transition      0.3
 set clock_latency         1

 create_clock -name clk -period $clock_period [get_ports $clk]
 set_dont_touch_network [get_ports $clk]
 set_fix_hold clk
 set_clock_uncertainty -setup $clock_uncertainty clk
 set_clock_uncertainty -hold $clock_uncertainty clk
 set_clock_transition $clock_transition clk
 set_clock_latency $clock_latency clk
 set_ideal_network [get_ports $clk]

The timing report after synthesis gives following result:

Code:
  Timing Path Group 'clk'
  -----------------------------------
  Levels of Logic:              31.00
  Critical Path Length:          2.92
  Critical Path Slack:           0.00
  Critical Path Clk Period:      3.33
  Total Negative Slack:          0.00
  No. of Violating Paths:        0.00
  Worst Hold Violation:         -0.24
  Total Hold Violation:         -8.22
  No. of Hold Violations:       35.00
  -----------------------------------

In Primetime I read the *.ddc and *.sdc generated by DC and display the endpoint slack of my entire design and there are a lot of of setup violations :shock:

Code:
pt_shell> report_global_timing 
Setup violations
---------------------------------------------------------
         Total  reg->reg   in->reg  reg->out   in->out
---------------------------------------------------------
WNS      -0.35     -0.35      0.00      0.00      0.00
TNS     -26.44    -26.44      0.00      0.00      0.00
NUM        335       335         0         0         0
---------------------------------------------------------

So should I re-synthesis my design with new timing constraints or is this a misunderstanding of the PrimeTime methodology?

Any help is appreciated!

Versions: DC F-2011.09-SP4 and PT F-2011.12-SP3 both running on CentOS 6.2
 
Last edited:

The timinig analysis of DC and PT should be similar. Perhaps there are problems in you PT setting.
 
  • Like
Reactions: hbeck

    hbeck

    Points: 2
    Helpful Answer Positive Rating
The timinig analysis of DC and PT should be similar. Perhaps there are problems in you PT setting.

Thanks for your hint! But PT gets almost all settings from DC output. This is my current PT flow:

  1. Setup technology (equal to DC setup, load wc and bc library *.db file)
  2. Setup netlist with "read_ddc -netlist_only foo.ddc" from DC and link design
  3. Setup timing and operating conditions (*.sdc output of DC)
  4. update_timing
  5. report_global_timing -> output refer to my first post

Should I also load the sdf file from DC?

I'm going to double check this run with another PT version.
 

You dont have to load the sdf in PT. I am not sure the difference but from PT manual, it should be:

Code:
set_clock_latency 2.5 -source -late[B] [get_clocks CLK][/B]

Perhaps you should revise how you write your constraints by checking how it is write in the PT manual.

Thanks.
 
  • Like
Reactions: hbeck

    hbeck

    Points: 2
    Helpful Answer Positive Rating
You can use report_timing to generate the timing report of a common path both in DC and PT.
Then you can analyze it and see the difference
Thanks!
 
  • Like
Reactions: hbeck

    hbeck

    Points: 2
    Helpful Answer Positive Rating
You can use report_timing to generate the timing report of a common path both in DC and PT.
Then you can analyze it and see the difference
Thanks!

I don't get it :sad:

I resynthesize my design without a clock latency to avoid syntax problems as hairo mentioned in his post. The timing report in DC shows this path:

Code:
Operating Conditions: WCCOM   Library: tcbn90ghpwc_ccs
Wire Load Model Mode: top

  Startpoint: reg[0]
              (rising edge-triggered flip-flop clocked by clk)
  Endpoint: reg[1]
            (rising edge-triggered flip-flop clocked by clk)
  Path Group: clk
  Path Type: max

  Des/Clust/Port     Wire Load Model       Library
  ------------------------------------------------
  Toplevel           TSMC128K_Lowk_Conservative      tcbn90ghpwc_ccs

  Point                                                   Incr       Path
  --------------------------------------------------------------------------
  clock clk (rise edge)                                   0.00       0.00
  clock network delay (ideal)                             0.00       0.00
  reg[0]/Q (EDFCNQD1)                                     0.26       0.26 f
  (...)
  data arrival time                                                  2.91
  clock clk (rise edge)                                   3.33       3.33
  clock network delay (ideal)                             0.00       3.33
  clock uncertainty                                      -0.30       3.03
  reg[1]/CP (EDFCNQD1)                                    0.00       3.03 r
  library setup time                                     -0.12       2.91
  data required time                                                 2.91
  --------------------------------------------------------------------------
  data required time                                                 2.91
  data arrival time                                                 -2.91
  --------------------------------------------------------------------------
  slack (MET)                                                        0.00

In PT I double check if the operating conditions are set equal to DC with report_design:

Code:
Operating Conditions:
  analysis_type                          on_chip_variation
  operating_condition_min_name           BCCOM
  process_min                            1
  temperature_min                        0
  voltage_min                            1.1
  tree_type_min                          balanced_case

  operating_condition_max_name           WCCOM
  process_max                            1
  temperature_max                        125
  voltage_max                            0.9
  tree_type_max                          balanced_case

Wire Load:                               (use report_wire_load for more information)
  wire_load_mode                         top
  wire_load_model_max                    TSMC128K_Lowk_Conservative
  wire_load_model_library_max            tcbn90ghpwc_ccs
  wire_load_selection_type_max           user-specified
  wire_load_model_min                    TSMC128K_Lowk_Conservative
  wire_load_model_library_min            tcbn90ghpwc_ccs
  wire_load_selection_type_min           user-specified
  wire_load_selection_group_max          WireAreaLowkCon
  wire_load_selection_group_min          WireAreaLowkCon
  wire_load_min_block_size               0

All parameters seems to be correct. Now report_timing in PT (which results in another max path as in DC):

Code:
  Startpoint: reg[3]
               (rising edge-triggered flip-flop clocked by clk)
  Endpoint: reg[4]
               (rising edge-triggered flip-flop clocked by clk)
  Path Group: clk
  Path Type: max

  Point                                                   Incr       Path
  ------------------------------------------------------------------------------
  clock clk (rise edge)                                   0.00       0.00
  clock network delay (ideal)                             0.00       0.00
  reg[3]/Q (DFCNQD4)                                      0.27       0.27 r
  (...)
  data arrival time                                                  3.33
  clock clk (rise edge)                                   3.33       3.33
  clock network delay (ideal)                             0.00       3.33
  clock uncertainty                                      -0.30       3.03
  reg[4]/CP (DFCNQD2)                                                3.03 r
  library setup time                                     -0.00       3.03
  data required time                                                 3.03
  ------------------------------------------------------------------------------
  data required time                                                 3.03
  data arrival time                                                 -3.33
  ------------------------------------------------------------------------------
  slack (VIOLATED)                                                  -0.30

Any hints?
 

I dont know what is the problem. But try analyze the same path in DC and in PT and find where is the additional delay is appeared in the path using this command:

Code:
report_timing -from reg[0] -to reg[1]

You can do man report_timing within the dc or pt in order to explore more about this command to help you understand what/where is the problem.

Thanks
 
  • Like
Reactions: hbeck

    hbeck

    Points: 2
    Helpful Answer Positive Rating
This is common problem. The timing engines in DC and PT are different,So the delay calculation. I see in many projects, there will be 100-200ps variation for the same path in DC and PT. Since PT is signoff timing tool,, th delay calculation algorithms are perfect and will violate.

If delay is varying more than 20%, check below thisngs.

1. Write the same path in DC and PT. Check the dealy for each cell in the path , Make sure rise and fall delays are intact in the same path. dont compare rise delay of the cell with fall delay.


Can you send snapshot of data path alone to verify it. Clock path is clear.

Regards, Sam
 
  • Like
Reactions: hbeck

    hbeck

    Points: 2
    Helpful Answer Positive Rating
This is common problem. The timing engines in DC and PT are different,So the delay calculation. I see in many projects, there will be 100-200ps variation for the same path in DC and PT. Since PT is signoff timing tool,, th delay calculation algorithms are perfect and will violate.

Thanks for your reply. This seems to be the root of the problem!

If I compare the timing for the same path in DC and PT there are small differences in the cell delay. This is the DC output of "report_timing -delay_type max_rise" -from reg[0] -to reg[1]

Code:
  reg[0]/CP (EDFCNQD2)                                    0.00 #     0.00 r
  reg[0]/Q (EDFCNQD2)                                     0.26       0.26 f
  U25685/ZN (INVD1)                                       0.10       0.36 r
  U821/ZN (ND4D4)                                         0.12       0.48 f
  U724/ZN (CKNXD2)                                        0.06       0.54 r
  U618/ZN (ND2D2P5)                                       0.05       0.59 f
  U24499/ZN (OAI21D4)                                     0.15       0.74 r
  U73/ZN (INVD8)                                          0.08       0.81 f
  U23508/ZN (CKND2D8)                                     0.08       0.89 r
  U23509/ZN (INVD10)                                      0.04       0.93 f
  U1778/ZN (AOI22D2)                                      0.05       0.98 r
  U25689/ZN (OAI211D1)                                    0.10       1.08 f
  U1576/Z (MUX2D1)                                        0.15       1.23 f
  U2029/Z (AO222D2)                                       0.14       1.37 f
  U2027/Z (BUFFD4)                                        0.08       1.45 f
  U13795/ZN (INVD6)                                       0.04       1.50 r
  U581/ZN (ND2D4)                                         0.05       1.55 f
  U578/ZN (CKNXD4)                                        0.04       1.59 r
  U577/ZN (ND2D4)                                         0.05       1.64 f
  U474/ZN (CKNXD4)                                        0.04       1.68 r
  U24397/Z (AN3D4)                                        0.11       1.79 r
  U275/ZN (ND3D8)                                         0.08       1.86 f
  U112/ZN (CKNXD6)                                        0.05       1.91 r
  U17008/Z (AN3XD1)                                       0.12       2.03 r
  U17007/ZN (ND3D2)                                       0.09       2.12 f
  U10695/Z (XOR2D1)                                       0.17       2.29 f
  U10694/ZN (INVD2)                                       0.10       2.39 r
  U17132/ZN (IND4D4)                                      0.09       2.48 f
  U24589/ZN (IND3D4)                                      0.13       2.61 f
  U580/ZN (CKNXD4)                                        0.05       2.66 r
  U579/ZN (ND2D4)                                         0.05       2.71 f
  U1019/ZN (ND2D3)                                        0.07       2.78 r
  U473/ZN (INVD6)                                         0.03       2.82 f
  U24556/ZN (OAI22D1)                                     0.09       2.91 r
  reg[1]/D (EDFCNQD1)                                     0.00       2.91 r
  data arrival time                                                  2.91

And ths is the PT output for the same path:

Code:
  reg_0/CP (EDFCNQD2)                                     0.00       0.00 r
  reg_0/Q (EDFCNQD2) <-                                   0.25       0.25 f
  U25685/ZN (INVD1)                                       0.10       0.35 r
  U821/ZN (ND4D4)                                         0.12       0.47 f
  U724/ZN (CKNXD2)                                        0.05       0.52 r
  U618/ZN (ND2D2P5)                                       0.05       0.57 f
  U24499/ZN (OAI21D4)                                     0.15       0.71 r
  U73/ZN (INVD8)                                          0.07       0.79 f
  U23508/ZN (CKND2D8)                                     0.07       0.86 r
  U23509/ZN (INVD10)                                      0.04       0.89 f
  U24631/Z (AO222D0)                                      0.31       1.20 f
  U1736/Z (MUX2D4)                                        0.14       1.34 f
  U1735/ZN (AOI222D2)                                     0.20       1.54 r
  U581/ZN (ND2D4)                                         0.08       1.62 f
  U578/ZN (CKNXD4)                                        0.04       1.67 r
  U577/ZN (ND2D4)                                         0.05       1.71 f
  U474/ZN (CKNXD4)                                        0.03       1.75 r
  U24397/Z (AN3D4)                                        0.11       1.85 r
  U275/ZN (ND3D8)                                         0.07       1.93 f
  U112/ZN (CKNXD6)                                        0.04       1.97 r
  U17008/Z (AN3XD1)                                       0.12       2.09 r
  U17007/ZN (ND3D2)                                       0.09       2.18 f
  U10695/Z (XOR2D1)                                       0.21       2.38 f
  U10694/ZN (INVD2)                                       0.09       2.47 r
  U17132/ZN (IND4D4)                                      0.09       2.56 f
  U24589/ZN (IND3D4)                                      0.13       2.69 f
  U580/ZN (CKNXD4)                                        0.05       2.74 r
  U579/ZN (ND2D4)                                         0.05       2.78 f
  U1019/ZN (ND2D3)                                        0.07       2.85 r
  U473/ZN (INVD6)                                         0.03       2.88 f
  U24556/ZN (OAI22D1)                                     0.09       2.98 r
  reg_1/D (EDFCNQD1)                                      0.00       2.98 r
  data arrival time                                                  2.98

Some cell delays are equal, some vary (e.g. the first EDFCNQD2 cell delay or U10695/Z takes 0.17ns in DC and 0.21ns at PT ). Moreover from U23509/ZN to U581/ZN are other cells in the critical path. Fascinating (and somehow confusing)! :-|

So whats the conclusion? Tighter constraints in DC?
 

I have synthesis asynchonous fifo in dc compiler now i am trying solved violation in PrimeTime. Most of violation is from reset to input posr of subdesig so i set false path to remove the violation now when i check report_timing i got negative slack due to my memory that i want to improve how can i do that in dc compiler or in prime time. generally how to remove violation in dc compile or in prime time.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top