Tighten up nangate45 jpeg #3648
Conversation
Signed-off-by: Jeff Ng <jeffng@precisioninno.com>
|
The other half of #3641 |
| export ABC_AREA = 1 | ||
|
|
||
| export CORE_UTILIZATION ?= 45 | ||
| export CORE_UTILIZATION ?= 80 |
| }, | ||
| "flow__warnings__count:PDN-1041": { | ||
| "value": 270, | ||
| "globalroute__flow__warnings__count:DRT-0120": { |
There was a problem hiding this comment.
[WARNING DRT-0120] Large net net11159 has 102 pins which may impact routing performance. Consider optimization.
seems a bit odd and worth a quick check (not new in the change, just noticed it in the diffs).
There was a problem hiding this comment.
[WARNING DRT-0120] Large net net11159 has 102 pins which may impact routing performance. Consider optimization.seems a bit odd and worth a quick check (not new in the change, just noticed it in the diffs).
It looks like net11159 is being driven by the instance place11160, which is a "Timing Repair Buffer" and it does drive 102 pins:
The net is created in the 3_3_place_gp step, probably during repair. The synthesized net that gets rebuffered is 025959 and the connection looks like:
- Inst 079408 drives net 025959
- net 025959 drives inst place11158 (and 21 other inst terms)
- inst place11158 drives net net11157
- net net11157 drive inst place11160
- inst place11160 drives net11159 (and 101 other inst terms)
The previous version of nangate45 jpeg doesn't have this rebuffering, prob since the clock period was lower.
Should I set max fanout or something to reduce the number of connections that this buffer is driving?
There was a problem hiding this comment.
@precisionmoon this seems odd, do you want to look at it?
There was a problem hiding this comment.
@povik, does GP use repair_design -pre_placement? If so, why do we see a net with 102 pins?
There was a problem hiding this comment.
does GP use repair_design -pre_placement?
It does placement buffering which is different. It can produce a net with 102 pins if it's meeting all constraints.
There was a problem hiding this comment.
I've looked at the checkpoint and it looks sensible.
To add to what Jeff wrote, the buffer sequence is
gate _079408_ -> (28 side loads) + buffer -> (21 side loads) + buffer -> 101 fanouts
There was a problem hiding this comment.
In that case, it probably makes sense to add set_max_fanout of 10.
|
Interesting little clumps in the layout - not sure if they are from gpl or dpl |
4 participants
Tighten up nangate45 jpeg - decreased clock period and increased utilization.