Consolidate area reporting calculations/reporting

[jeffng-or]

Description

We currently have at least three different places we report area and utilization. Each one of them is different, which can lead to confusion:

1. report_design_area tcl command: report area & utilization for all cells, excluding fillers, endcaps, and welltaps (Resizer)
2. metadata.json: utilization is (std cell area + macro area) / core area. std cell area excludes fillers, pads, and cover cells, but includes endcaps and welltaps
3. hierarchy browser: reports area for all cell types without exclusions

Suggested Solution

No response

Additional Context

No response

[maliberty]

I think gpl is another place to check

[maliberty]

I feel part of the problem here is a lack of well-defined terms. @gadfort @rovinski thoughts?

[gadfort]

@maliberty as a designer, I think:
utilization of stdarea: (area of stdcells + area of endcaps and tapcells) / (area of rows only) <- macros are not placed over the standard cell area
utilization of area: (area of stdcells + area of endcaps and tapcells + area of macros) / (area of core)
area: is all cells (pad, macros, and stdcells)
I generally dont consider the fillers since their inclusion just obfuscates the design utilization.

[maliberty]

A somewhat related problem: in initial_floorplan we take -utilization which considers the area of the macros without their halos. When placed the halo will effectively increase the size of the macro requiring a higher -density to global_place.

@gadfort what is your thoughts on how halos should be accounted for in reporting and command args?

[maliberty]

(aes-blocks is a good example where we have a lot of very small macros where the halos add a lot of area)

[gadfort]

I think for reporting, the halos don't matter.
The same is true for padding as to halos. The utilization in floorplanning is fine I think, I think the issue is how global place chooses to calculate the density.

[rovinski]

Agree that halos should not count in reporting. Either halos should be soft, in which case buffers and other cells for timing optimization purposes can be placed in them, or they can be hard, in which case it is equivalent to simply removing the sites.

Different definitions of area are useful, I think as long as there is consistent terminology and definitions, I am fine with most things.

[maliberty]

The halo are soft blockages in DEF:

Indicates that the initial placement should not use the area, but
later phases, such as timing optimization or clock tree
synthesis, can use the blockage area. This can be used to
preserve certain areas (such as small channels between
blocks) for buffer insertion after the initial placement.

So they do influence the available area not not as simply as a hard blockage

[maliberty]

The question is should we have a different definition of utilization when reporting vs when passing to initialize_floorplan? If we exclude the halo from the utilization then is an offset between what the user specifies and what is actually achievable.

[rovinski]

No, soft blockages should be ignored for area calculations, regardless of the stage (meaning the area of a soft blockage counts towards total area). The blockages are user-specified in the first place, so they have to make the adjustment to the utilization they provide.