I0819 13:13:57.195329 141589 foo.x:42]] Sent data on channel `Foo::x_in`:
The problem is, when we spawn the same proc multiple times, it still reports the same thing, so we can't tell which sub-proc the message is logged against.
Current best alternative workaround (limit 100 words)
I'm not aware of a workaround.
Your view of the "best case XLS enhancement" (limit 100 words)
The logged info should show something like:
I0819 13:13:57.195329 141589 foo.x:42]] Sent data on channel `Foo::x_in(foo_0_x_in)`:
I0819 13:13:57.195329 141589 foo.x:42]] Sent data on channel `Foo(foo_0)::x_in`:
If spawned procs were named, it could be used to differentiate the channels, since channel members within a proc are unique by construction.
Alternatively, channel declarations are named, so retaining this metadata when one end is passed into a spawned proc could perhaps be used to disambiguate multiply-instantiated channels as well.
proppy
commented
3 weeks ago
What's hard to do? (limit 100 words)
When using
interpreter_mainwith the flag--trace_channels, the info message reports sends and receives the proc identifier + channel name (https://github.com/google/xls/blob/main/xls/dslx/bytecode/bytecode_interpreter.cc#L1145 for send from https://github.com/google/xls/blob/main/xls/dslx/bytecode/bytecode_emitter.cc#L109).For example:
The problem is, when we spawn the same proc multiple times, it still reports the same thing, so we can't tell which sub-proc the message is logged against.
Current best alternative workaround (limit 100 words)
I'm not aware of a workaround.
Your view of the "best case XLS enhancement" (limit 100 words)
The logged info should show something like:
If spawned procs were named, it could be used to differentiate the channels, since channel members within a proc are unique by construction.
Alternatively, channel declarations are named, so retaining this metadata when one end is passed into a spawned proc could perhaps be used to disambiguate multiply-instantiated channels as well.