OpenROAD
OpenROAD copied to clipboard
The-OpenROAD-Project
odb: shrink dbGCellGrid::GCellData fields uint -> uint8_t
Shrinkg 6_final.odb from 3.6G to 2.1G on gf12/bp_single. The effect on gzipped size is minimal as it effective compresses out this inefficiency.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
You could potentially write those variables out as var ints and move them to uint16s if you want the extra headroom
https://sqlite.org/src4/doc/trunk/www/varint.wiki#:~:text=A%20variable%20length%20integer%20is,(and%20less%20common)%20values.
@maliberty Does this reduce RAM requirements of OpenROAD too or is this only disk requirements?
@oharboe It would reduce RAM as well @QuantamHD I think varints are an interesting idea for serialization. I don't think they would help with the in memory representation though as these fields are part of a struct.
I'm sitting on this PR as I may make more changes before merging in order to minimize the number of schema updates.
@QuantamHD that particular scheme is good for ints up to 64 bits. Since many uses are 32bit there may be a better scheme for those cases.
If you expect most things to be within 7 bits I don't see why it wouldn't also be helpful 32 bits.
If you expect most things to be within 7 bits I don't see why it wouldn't also be helpful 32 bits.
Because I want to shrink the in memory representation too by restricting to 1 byte. Varints aren't useful in memory.
If that's the primary purpose then sure, but as I suggested I worry about these low limits and maybe moving to uint16_t is worth the extra memory for the peace of mind.
If that's the primary purpose then sure, but as I suggested I worry about these low limits and maybe moving to uint16_t is worth the extra memory for the peace of mind.
Why? A gcell is ~15 tracks. Even 10X would still fix in a byte.
Smaller memory footprint is always good. Why store it on disk at all ? I’m assuming that it’s derived from the route guides and some blockages, no ? How long does it take to compute this data ?
We would have to separate out the capacity calculation in grt to be separately callable and traverse all the guides so it is possible but not trivial to avoid storing it. Once whittled down I'm not sure it will be as important.
How does grt take blockages or power routing into account ? There must be a pre processing step, right ? Can I get a global route resource map by reading e.g. ispd19 results (routed def) ?
How does grt take blockages or power routing into account ? There must be a pre processing step, right ? Can I get a global route resource map by reading e.g. ispd19 results (routed def) ?
grt does consider such in computing available tracks. You have to run the global router to get the map. You could delete the routing, then run the global router if you really want it.
@maliberty I've made a bunch of updates to remove unused data from dbGCellGrid, with some modifications to the GPL-GRT API to allow us to remove the blockage data from the gcell grid.
