google
[enhancement] developer should be able to choose how to simulate their DSLX code
What's hard to do? (limit 100 words)
Currently when choosing between the DSLX interpreter, the IR interpreter, the JIT or a Verilog simulator to run a set of DSLX tests: developers have to go thru very disjoint experiences (both on the command line and thru bazel rules).
Current best alternative workaround (limit 100 words)
DSLX interpreter
Just use interpreter_main w/ input and assertion from tests; for bazel: xls_dslx_test.
IR interpreter
ir_converter_main | opt_main | eval_ir --use_llvm_jit=false w/ inputs from the command line and --input_validator_expr or --input_validator_path to validate the result; for bazel: xls_dslx_ir ← xls_opt_ir ← xls_eval_ir_test.
JIT
ir_converter_main | opt_main | eval_ir --use_llvm_jit=true w/ inputs from the command line and --input_validator_expr or --input_validator_path to validate the result; for bazel: xls_dslx_ir ← xls_opt_ir ←cc_xls_ir_jit_wrapper ← cc_test.
Verilog
codegen_main and write a verilog test bench.
Your view of the "best case XLS enhancement" (limit 100 words)
Ideally we would have only one command line/bazel rule w/ a flag to choose the simulation environment.
DSLX interpreter
dslx test path/to/example.x
xls_dslx_test(
name = "e_dslx_test",
srcs = [ "example.x" ],
)
IR interpreter
dslx test --simulator=dslx path/to/example.x
xls_dslx_test(
name = "e_dslx_test",
srcs = [ "example.x" ],
simulator = "dslx",
)
JIT
dslx test --simulator=jit path/to/example.x
xls_dslx_test(
name = "e_dslx_test",
srcs = [ "example.x" ],
simulator = "jit",
)
Verilog
dslx test --simulator=iverilog path/to/example.x
xls_dslx_test(
name = "e_dslx_test",
srcs = [ "example.x" ],
simulator = "verilog",
)
Just for another motivating example an engineer was recently trying to understand how performance of XLS simulator tools compared to verilog. They created a #[test_proc] which ran a proc codegen'd through verilog and compared how long the verilog simulation took vs the one performed by 'testing' the test_proc. They were confused about why the xls one was so slow when the reason was that it was doing the DSLX interpreter and so took ~5 minutes to complete. If one runs the same benchmark using the proc-jit it finishes in 0.5 seconds.
We take pride in our fast simulation support but the path to try them out is not always the most well lit.
One complexity here is that we ideally want identical test behavior at each level which will take a lot of work. The biggest problem is likely that the DSLX type system is much richer than the IR (structs, signedness, etc) so you can have much nicer messages. Ideally we'd have a way of recovering that at the lower levels.
