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] density problems in SoC Encounter

Status
Not open for further replies.

soloktanjung

Full Member level 6
Joined
Nov 20, 2006
Messages
364
Helped
51
Reputation
100
Reaction score
43
Trophy points
1,308
Location
nowhere
Activity points
3,194
Hi,

Here is my problem during place and route stage regarding placement density:

Before placement = 60%
Optdesign -prects = 67%
optdesign -prects -incr = 75%

optdesign -postcts = 79%
optdesign -postcts -incr = 81%
optdesign -postcts -hold = 95%

Timing analysis after optdesign -postcts -hold:
Code:
------------------------------------------------------------
     optDesign Final Summary
------------------------------------------------------------

+--------------------+---------+---------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate |
+--------------------+---------+---------+---------+---------+---------+---------+
|           WNS (ns):| -1.055   | -0.797  | -1.055   | -0.721  |  4.389  |   N/A   |
|           TNS (ns): | -1521.3 |-232.758| -1397.5 | -30.677 |  0.000  |   N/A   |
|    Violating Paths:|  3215    |  1251    |  2332    |   131    |    0      |   N/A   |
|          All Paths:  |  4559    |  3152    |  2473    |   288    |   16     |   N/A   |
+--------------------+---------+---------+---------+---------+---------+---------+

+--------------------+---------+---------+---------+---------+---------+---------+
|     Hold mode      |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate |
+--------------------+---------+---------+---------+---------+---------+---------+
|           WNS (ns):| -0.761  | -0.246  |  1.088  | -0.761  |  0.847  |   N/A   |
|           TNS (ns): | -85.824 | -13.244 |  0.000 | -72.580|  0.000  |   N/A   |
|    Violating Paths:|   474   |   210     |    0      |   264    |    0    |   N/A   |
|          All Paths:  |  4558   |  3151    |  2472   |   288    |   16    |   N/A   |
+--------------------+---------+---------+---------+---------+---------+---------+

I cannot continue with nanoroute because of 95% density. Here is my constraints:

Synthesis constraint: 2.2 ns clock period (-0.57 ns slack)
place and route constraint: 2.5 ns clock period

I'm working on block level implementation now, die area is 700 um x 500 um.
Is there any problem with my constraint or with the floorplan? Any advice please?
 

How much margin you are keeping for hold .. seems 14% utilization jump for hold optimization.
 

How much margin you are keeping for hold

I dont have any margin for now, because i will do several iterations to find the correct block level constraint, and so for this first try run, i just want to complete the place and route, assemble it in the top level implementation and evaluate the timing.

Thanks in advance.
 

I dont have any margin for now, .

What's your target limit for hold ?. 14% utilization jump is pretty huge number. I thought you are over constraining your hold limit...


Are you allowing IO optimization at your block level? Do you keep tighter constraints for IO's? Because seeing 8% utilization growth at incremental prects stage and total of 15% util growth for overall placement.
 

Hi Hairo,

It may because of Not synthesis properly and so many number of hold violations in netlist or ur hold margin is very tight.

Synthesis stage itself u have -0.57ns slack. So, Please make sure that tool should not optimize that already violated paths[try to hide those paths]. so u can avoid the % of gate increases with unnecessary paths. And then relax ur hold margin and run. because in hold optimization % of increasing gate count is very high.

Regards,
Santhosh.
 

Thanks for the suggestions.

I change the constraints as follows:

synthesis clk period = 2.5 ns
input delay = 0.5 ns (i reduced from 1.0 ns)
place and route clk period = 3.5 ns

However i still got about 15% utilization increment when running optdesign -postcts -hold from optdesign -postcts command.

I do check_timing -verbose to find any problem but there is no problem with the timing.

Thanks again.
 

Thanks for reply,

Can u tell me what are the setOptMode options you used with values?
 

Thank you San31.

Here is the setoptmode options:

velocity 30> getOptMode
-addInst true # bool, default=true
-addInstancePrefix {} # string, default=""
-addNetPrefix {} # string, default=""
-addPortAsNeeded true # bool, default=true
-allEndPoints false # bool, default=false
-allowOnlyCellSwapping false # bool, default=false
-bufferAssignNets false # bool, default=false
-clkGateAware false # bool, default=false
-congOpt false # bool, default=false
-considerNonActivePathGroup false # bool, default=false
-criticalRange 0.2 # float, default=0.2, min=0.000000, max=1.000000
-critPathCellYield false # bool, default=false
-deleteInst true # bool, default=true
-downsizeInst true # bool, default=true
-drcMargin 0 # float, default=0, user setting
-dynamicPowerEffort none # enums={none low med high}, default=none
-effort high # enums={low high}, default=high, user setting
-fixCap true # bool, default=true, user setting, private
-fixDrc true # bool, default=true
-fixFanoutLoad true # bool, default=false, user setting
-fixGlitch true # bool, default=true
-fixHoldAllowOverlap auto # enums={auto false true}, default=auto
-fixHoldAllowSetupTnsDegrade true # bool, default=true
-fixHoldOnExcludedClockNets false # bool, default=false
-fixTran true # bool, default=true, user setting, private
-holdFixingCells {} # string, default=""
-holdFixingEffort low # enums={low high}, default=low
-holdSdfFile {} # string, default=""
-holdTargetSlack 0 # float, default=0
-honorFence false # bool, default=false
-ignorePathGroupsForHold {} # string, default=""
-keepPort {} # string, default=""
-leakagePowerEffort none # enums={none low high}, default=none
-maxDensity 0.95 # float, default=0.95
-maxLength 2147483647 # uint, default=2147483647
-moveInst true # bool, default=true
-optimizeConstantNet true # bool, default=true
-optimizeFF true # bool, default=true
-optimizeNetsAcrossDiffVoltPDs true # bool, default=true
-postCtsClkGateCloning false # bool, default=false
-postRouteAllowOverlap true # bool, default=true
-preserveAssertions true # bool, default=true
-preserveModuleFunction false # bool, default=false
-reclaimArea default # enums={true false default}, default=default
-resizeShifterAndIsoInsts false # bool, default=false
-restruct true # bool, default=true
-route noPreserve # enums={post incrNano incrTrial incr noIncr preserve noPreserve}, default=incrTrial, user setting, private
-setupSdfFile {} # string, default=""
-setupTargetSlack 0 # float, default=0, user setting
-simplifyNetlist true # bool, default=true
-sizeOnlyFile {} # string, default=""
-swapPin true # bool, default=true
-unfixClkInstForOpt true # bool, default=true
-useConcatDefaultsPrefix true # bool, default=true
-usefulSkew false # bool, default=false
-verbose false # bool, default=false
-virtualPartition false # bool, default=false
-yieldEffort none # enums={none low high}, default=none

Thanks again.
 

In Default hold target slack is 0. It will try to optimize to 0 slack. that's why it's adding so many instance i think. But default effort is low only. why it's fixing all the violations? But default Maxdensity 0.95. So it reached upto 95%. :)

-holdTargetSlack 0 # float, default=0
-maxDensity 0.95 # float, default=0.95

U wanna close the timing with this netlist? If no, then take histogram of hold slack and set some value for holdtargetslack to 0.1 or 0.2 and try. and chnage the maxdensity to 0.80 or 0.85 also.

Regards,
Santhosh
 

Options seems okay..

---------- Post added at 09:57 ---------- Previous post was at 08:53 ----------

How much skew you are observing in your design..
 

From reportclocktree command:

********** Clock clk_i Pre-Route Timing Analysis **********
Nr. of Subtrees : 1
Nr. of Sinks : 2939
Nr. of Buffer : 69
Nr. of Level (including gates) : 4
Root Rise Input Tran : 120(ps)
Root Fall Input Tran : 120(ps)
Max trig. edge delay at sink(R): top0/.../.../mem_reg_8__10_/CK 392.7(ps)
Min trig. edge delay at sink(R): top0/.../.../.../CK 362(ps)


(Actual) (Required)
Rise Phase Delay : 362~392.7(ps) 0~10(ps)
Fall Phase Delay : 433.5~523.7(ps) 0~10(ps)
Trig. Edge Skew : 30.7(ps) 120(ps)
Rise Skew : 30.7(ps)
Fall Skew : 90.2(ps)

Max. Rise Buffer Tran. : 219.5(ps) 300(ps)
Max. Fall Buffer Tran. : 129.6(ps) 300(ps)
Max. Rise Sink Tran. : 231.5(ps) 300(ps)
Max. Fall Sink Tran. : 261.6(ps) 300(ps)
Min. Rise Buffer Tran. : 73.8(ps) 0(ps)
Min. Fall Buffer Tran. : 60.3(ps) 0(ps)
Min. Rise Sink Tran. : 137.2(ps) 0(ps)
Min. Fall Sink Tran. : 98.7(ps) 0(ps)

Above report is based on 3 ns clock period.

For more information, this is the timing report for hold time just after finish clockDesign command:

------------------------------------------------------------
timeDesign Summary
------------------------------------------------------------

+--------------------+---------+---------+---------+---------+---------+---------+
| Hold mode | all | reg2reg | in2reg | reg2out | in2out | clkgate |
+--------------------+---------+---------+---------+---------+---------+---------+
| WNS (ns):| -0.826 | -0.256 | 1.061 | -0.826 | 0.900 | N/A |
| TNS (ns): |-456.987 |-283.399 | 0.000 |-173.588 | 0.000 | N/A |
| Violating Paths:| 2172 | 1882 | 0 | 290 | 0 | N/A |
| All Paths: | 4759 | 3263 | 2478 | 290 | 16 | N/A |
+--------------------+---------+---------+---------+---------+---------+---------+

I will try San31 suggestions later this afternoon and will get back.

Thanks again.
 
Last edited:

It seems that the synthesized netlist doesn't correspond to the physical design.
SoC encounter tries to fix the hold time violation by adding delay buffer with the cost of area
As the previous member said, it's the reason why the utilization increases a lot.
 

Solved it by analyzing the violated path in encounter through debug timing menu. There are problems with the IO constraints that make the encounter insert many buffers in the path.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top