DREAMPlace VS tiny-cuda-nn

Yes, see "DREAMPlace: DREAMPlace: Deep Learning Toolkit-Enabled GPU Acceleration for Modern VLSI Placement".[1] The technique in particular rather reformulates VLSI placement in terms of a non-linear optimization problem. Which is how ML frameworks (broadly) work, optimizing approximations to high-dimensional non-linear functions. So it's not like, shoving the netlist it into an LLM or an existing network or anything.

Note that DREAMPlace is a global placer; it also comes with a detail placer but global placement is what it is targeted at. I don't know of an appropriate research analogue for the routing phase of the problem that follows placing, but maybe someone else does.

[1] https://github.com/limbo018/DREAMPlace

Huge part of why OpenROAD (and as this article.indicates, nvidia) are so focused on machine learning! Because the nitty gritty of chip design has abundant gnarly problems requiring deep deep expertise. Deploying software engineers is hard. But building ml is kind of our bag!

There's another nice upstart opensource project with even fancier ml placememt systems that spawned recently out of the openroad world, dreamplace, https://github.com/limbo018/DREAMPlace

This is just gonna get more & more biased against a couple super smart engineers who we've deeply entrusted to divine inner the workings of the chips on, & become increasingly a set of better modelled problems that we can machine learningly optimize.

In the opposite direction from your question is a very interesting project, TinyNN all implemented as close to the metal as possible and very fast: https://github.com/NVlabs/tiny-cuda-nn

This repo only implemented the rendering part of the NGP but is more simple and has a lesser amount of code compared to the original (Instant-NGP and tiny-cuda-nn).

...a C++ library with a CUDA backend. But these high-performance building blocks might only be saturating the GPU fully if the data is large enough.

I haven't looked at implementing these things, but I imagine uf you have smaller networks and thus less data, the large building blocks may not be optimal. You may for example want to fuse some operations to reduce memory latency from repeated memory access.

In PyTorch world, there are approaches for small networks as well, there is https://github.com/NVlabs/tiny-cuda-nn - as far as I understand from the first link in the README, it makes clever use of the CUDA shared memory, which can hold all the weights of a tiny network (but not larger ones).