Custom scheduling

[amykouf]

Hi all,

I want to introduce a custom scheduling to the codegen, by providing a scheduling file (.pbtxt) describing the result I want for the IR nodes (opt.ir file). I have successfully integrated that functionality to codegen_main.c, as it reads a .pbtxt file and proceeds to the generation of the RTL code.

While in most cases this operates correctly (same opt.ir code, different .pbtxt) I've stumbled on cases where I get the following error:

terminate called after throwing an instance of 'std::out_of_range'
  what():  absl::container_internal::raw_hash_map<>::at
Aborted

I make sure I satisfy dependency requirements among the nodes. Moreover, I simplified my .cc code so that the top function operates on one input, as it corrected some of this behavior. Any ideas on where to look to fix this? Is there a condition for the scheduling that I do not consider?

I attach an example of the codegen I run below. I'm pretty certain --pipeline_stages attribute is ignored:

./bazel-bin/xls/tools/codegen_main test_design.opt.ir   --generator=pipeline   --delay_model="unit" --module_name=xls_test   --top=test_function --pipeline_stages=4 --output_schedule_ir_path=sched.pbtxt --input_valid_signal="load" --output_valid_signal="done" --output_verilog_path=test.v

[Leary, Chris]

Hi!

There are a lot of flat_hash_map::at calls in the code base which makes for a lot of possibilities here -- do you get a back trace in the output?

For a general debugging technique, you can use --vmodule=sdc_scheduler=4 to activate the "VLOG" logging statements in a given C++ module; e.g. https://github.com/google/xls/blob/f0bf6b8496778174687ebf019b1663da13e01386/xls/scheduling/sdc_scheduler.cc#L112

There's also the "whole program" verbose logging level you can set via --v=1 or similar (make sure you also have --alsologtostderr so it prints to the console).

You can also use this facility to do more printf-style debugging to figure out where the crash originates from. Dumping the IR text before codegen and checking all the IR nodes are present and accounted for in your .pbtxt would be a good soundness check.

Additionally you could `bazel build -c dbg //xls/tools:codegen_main` and then run under gdb to see where the crash occurs in context with `gdb --args ./bazel-bin/xls/tools/codegen_main test_design.opt.ir   --generator=pipeline   --delay_model="unit" --module_name=xls_test   --top=test_function --pipeline_stages=4 --output_schedule_ir_path=sched.pbtxt --input_valid_signal="load" --output_valid_signal="done" --output_verilog_path=test.v` (use "up" to go up frames and "list" to do a code listing).

Hope these general debugging techniques are useful, let me know if you were looking for something more specific or have more questions. I would say in general there's a lot of places you can dump the IR (i.e. post scheduling) and inspect what you might be referring to that doesn't exist in the map you're supplying, there may be some way to validate your supplied pbtxt's contents against the graph in a pre-pass to make sure everything is there that you expect to be there.

Cheers,

- Chris Leary

--
You received this message because you are subscribed to the Google Groups "xls-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xls-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xls-dev/239c5208-2bfc-40c5-8ace-400fc2658475n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.