Ethan Mahintorabi comments

Results 203 comments of


                                            Ethan Mahintorabi

odb: shrink dbGCellGrid::GCellData fields uint -> uint8_t

https://sqlite.org/src4/doc/trunk/www/varint.wiki#:~:text=A%20variable%20length%20integer%20is,(and%20less%20common)%20values.

odb: shrink dbGCellGrid::GCellData fields uint -> uint8_t

If you expect most things to be within 7 bits I don't see why it wouldn't also be helpful 32 bits.

odb: shrink dbGCellGrid::GCellData fields uint -> uint8_t

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...

Dumping estimated parasitics as SPEF

I'd also like this

Support for package access via VHPI and FLI

Nice!

Add library of useful functions for doing manual placement of cells

We should take a page from CSS Grid https://css-tricks.com/snippets/css/complete-guide-grid/ if we're looking for more generic layout primitives.

Reduce compressed size of files in results/ folder, especially .odb files

We could theoretically add a gz option to the writer.

Reduce compressed size of files in results/ folder, especially .odb files

Looks like not by default. https://bazel.build/reference/command-line-reference#flag--remote_cache_compression, and there's zero chance that CMake and or make are doing any kind of artifact compression. https://www.buildbuddy.io/blog/how-bazel-5-0-makes-your-builds-faster/

Reduce compressed size of files in results/ folder, especially .odb files

My understand of that that feature is that it reduces at rest storage costs. GCS decompresses it on the fly over the wire so you're paying the full network bandwidth...

Reduce compressed size of files in results/ folder, especially .odb files

I think the reality is that would be a lot of work and complexity for gains on very specific systems. I don't think the juice is worth the squeeze. What...