Fix regressions in ZSTD module

[magancarz]

This PR:

• reverts enabling proc-scoped channels in ZSTD module, which caused regressions in builds and decoding test cases (77dcc8)
• fixes place and route target failures by specifying larger die dimensions
• adds a fix for opt_ir_benchmark targets by checking if a node is tracked before getting info in lazy_query_engine.h. (Fixes xls_benchmark_ir targets failing due to internal checks #3637)

[proppy]

Looks like the zstd CI was cancelled after 5 hours, is that expected?

[proppy]

List of commits which introduced regressions to ZSTD module:

• 0b3b7d

it doesn't looks 0b3b7d is being reverted to me, am I missing something?

[magancarz]

Looks like the zstd CI was cancelled after 5 hours, is that expected?

No, the timeout error was caused by long-running P&R targets and I think those should be tagged as long and skipped in CI to prevent these kind of problems, that is:

• sequence_executor_place_and_route
• command_constructor_place_and_route
• fse_dec_place_and_route
• ram_mux_place_and_route
• huffman_decoder_place_and_route
• mem_writer_place_and_route

I'll update the pull request with relevant changes.

it doesn't looks 0b3b7d is being reverted to me, am I missing something?

Sorry, that was unclear. This commit created the Test ZSTD module job run which showed the error caused by the opt_ir_benchmark targets. Previous Test ZSTD module run on main, as seen on the Actions page, was dispatched by cc8501 and ended without errors. The error was introduced somewhere in between, probably by b20719 and 8bacd2 fixes it.

[magancarz]

I've added a long tag to long-running benchmark synth / P&R targets and excluded them in the Test ZSTD module job.

[magancarz]

I've dropped the commit checking if a node is tracked before getting the info since the actual fix is in #3975.

[magancarz]

I've rebased changes onto the latest main, so fix from #3975 is included.