[enhancement] Enable IR timing analysis without logic used by non-synthesizable Verilog code

[rw1nkler]

What's hard to do? (limit 100 words)

To obtain accurate timing information for a code that produces non-synthesizable Verilog constructs like trace_fmt!. Some of the logic may be used exclusively for non-synthesizable code and will be removed during the synthesis step in external tools. IR Visualization tool and the IR benchmarking reports could have an option to remove the logic used solely by non-synthesizable Verilog constructs.

An example of a process whose critical path is will be translated to non-synthesizable Verilog code:

proc Passthrough {
    data_r: chan<u32> in;
    data_s: chan<u32> out;

    config(data_r: chan<u32> in, data_s: chan<u32> out) { (data_r, data_s) }

    init { () }

    next(tok: token, state: ()) {
        let (tok, data) = recv(tok, data_r);

        // this logic could be removed from the IR timing report
        let pow2 = data * data;
        trace_fmt!("Data raised to the power of two: {}", pow2);

        let tok = send(tok, data_s, data);
    }
}

Current best alternative workaround (limit 100 words)

Possibly the Synthesizer mechanism living in the synthesizer.cc may be used to obtain more accurate results, as the gRPC synthesizer can be used by the benchmark_main using the --compare_delay_to_synthesis flag. However, the mechanism is not described in the documentation. If the functionality is already there it would be great to extend the documentation with a description on how to use it.

Your view of the "best case XLS enhancement" (limit 100 words)

It would be great if more accurate timing reports could be viewed using the IR visualization tool or benchmarking rules