If our backend team doesn’t complain about HLS, it most certainly won’t complain about RTL generators.
FWIW: the codecs are not super stable designs at all. They’re under constant development.
For modern ASICs, layout partitions are so large that your backend tools see hundreds of thousands of instances that are on the same clocks. The synthesis tools may have special recipes for optimization (which, again, you can still do), but the backend flow is mostly concerned with meeting timing on that clock. Except for external IOs, it’s rare to have specialty timing constraints at within partitions.
Chisel, SpinalHDL, Clash, Migen, Amaranth aren't HLS
Most of the time, if you get some verilog out of those tools with mangled names, it can be because of bad coding practice.
Here is some examples about how to preserve good names for SpinalHDL : https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/S...
Chisel, SpinalHDL, Clash, Migen, Amaranth, and RTL variants generate synthesizable RTL Verilog in the end. From that point of view, they are compatible with any existing ASIC flow.
The only problematic aspect is that most companies use line and conditional coverage as one of their sign-off criteria. That's hard to do with automatically generated Verilog.
But here's the kicker: HLS-generated Verilog is orders of magnitude worse in terms of readability, and yet most recent ASICs with video codecs are design with HLS and derived from HLS reference implementations. And forget about doing traditional coverage metrics just on that RTL just the same.
If HLS-generated Verilog is fine for an ASIC flow, then alternatives like Chisel and friends are much less problematic.