xls
xls copied to clipboard
google
[enhancement] Provide automatic generation of channel muxing / demuxing procs in DSLX
What's hard to do? (limit 100 words)
Even though creating muxing/demuxing logic for channels is an easy concept it requires quite complex code, with nonblocking receives to allow free data flow and conditional operations that depend on the select signal. This task could potentially be automated.
Current best alternative workaround (limit 100 words)
Write the muxing/demuxing logic manually
Your view of the "best case XLS enhancement" (limit 100 words)
A basic muxing/demuxing logic with the select channel could potentially be generated automatically. However, simple channel switching is often insufficient for a functional design. For instance, when connecting a single proc to two RAMs, one may want to switch between channels only after all operations on one channel have finished. This scenario requires more complex arbitration logic. Users can provide this additional logic by wrapping the simple muxing/demuxing processes with a process that performs the necessary arbitration.
Though it's not obvious, I believe this will be addressed when we resolve #1023.
XLS already supports generation of adapters that manage the simple case of this problem; DSLX just doesn't currently include a way to specify that you'd like to use an adapter.
This is hitting us now when updating the Verilog wrappers for the decoder and updating the related plumbing, CC @richmckeever - obviously we'll have to do it by hand this time around, but it would be a huge timesaver if this was possible to do automagically. Potentially something we'd be happy to work on at some point, unless of course there is an idea how to get this sooner. Not sure how #1023 would help here, but that's probably me not understanting the toolchain well enough.
Talking about stuff like this: https://github.com/antmicro/xls/blob/zstd_compressed_block_dec/xls/modules/zstd/ram_mux.x
Conditional receives/sends can do a lot, especially if we expose reduced strictness through DSLX... The main limitation remaining is that you can't make arbitration decisions based on the fullness of a FIFO, except for the non-blocking receive (which essentially lets you do an action conditional on the non-emptiness of a FIFO as long as you can precommit to receiving one value if it's available).
Can you be more specific about the sort of muxing/arbitration logic you're looking to achieve? If it's possible, I'd be glad to add it to our list of examples, and if it's not, it'll make it easier to act on this as a feature request.
For reference, I sent https://github.com/antmicro/xls/pull/1 as an example of the sort of cleaned-up logic that's already possible. It's nice to see that it's possible to write a reasonable clean controlled 2-input (0/1) 2-port (read/write) MUX for generic request/response exchanges!
My obvious remaining wishlist would be the ability to do some sort of indexing on channels, since that would remove some redundancy in the input-side of the MUX handling. What else would you like to see?