Fixing code generation for AXI interfaces

[nathanielnrn]

With the help of #1071 it seems like there are now actionable items to fix regarding each issue that @andrewb1999 found. I am listing them here for tracking. Note that this in essence skipping to part 4 of #1022. Also probably overwrites #1020.

These are in order of appearance in #1071, not in order of importance.

• Remove initialization of wires #1080
• Change data port width to 512 to match with hardware Change generated kernel.xml axi manager port width to 512 #1074
• Examine memories_sent control signal and generalize correct behavior Memories sent fix #1075
• Correct width mismatches between memory controller and x_addr0 #1081
• Fix ap_done assignment Fixed assertion of ap_done #1076
• Drive BRAM Done signal Make single port bram correctly drive [Done] signal #1073
• Add ap_idle signal #1078
• Fix order of operations of addr calculations (bit shift must occur before addition) #1082
• Change WDATA assignment to be padded with 0s instead of repeating data Fix concatenation on WDATA and WSTRB #1077
• Change WSTRB to only allow valid bytes passed Fix concatenation on WDATA and WSTRB #1077
• Fix copy_done and send_done to be asserted at the correct time #1079
• Fix WDATA and WSTRB to work with unaligned addresses #1109

[nathanielnrn]

Happy to say that I think this work is almost done. Once #1103 and #1101 are approved, the only thing left will be to actually generate some verilog and emulate it. I'm sure there will be some things to debug but I think we're getting close. In general I'd be happy to hear any feedback regarding this whole endeavor (both from a technical-implementation standpoint or otherwise) from @rachitnigam, @sampsyo, @andrewb1999, and anyone else.

(I know everyone is super busy, no pressure, just trying to say that I'm open to hearing things if there's anything to be said!)

[sampsyo]

This is SO INCREDIBLY COOL! I am super impressed at how quickly these fixes came together—you did an amazing job getting the effort organized, learning Rust and the very complex AXI-generation codebase, and figuring out the fixes.

As for next steps, I think you're right about the immediate one: let's see if it all works! I think it's somewhat predictable that we'll discover some other issue after all these fixes, so let's be prepared that there may be one or two little things to fix up to make the dot product example "go."

Here are some other short-term next steps, as I see them:

1. Let's rip out the existing execution stage in fud and replace it with your PYNQ host code that you've written. This would address [fud] Revamp Xilinx fpga stage to work for both emulation and execution #872. The sub-steps would be:
   • Adapt your PYNQ host script to take in data JSON files as input and produce JSON data files as output.
   • Change the fud stage to invoke this script as a subprocess. I can help with this because it seems a little thankless!
2. Adding a couple of Verilog-generation tests would be super nice, as mentioned in Add ap_idle generation #1101 (review), and shouldn't be very hard at all.

Beyond this, I think there are many useful and exciting directions we could go in, so I think it would be useful to have a conversation about what you would find most fulfilling/interesting. Some options include:

• Try things out with real FPGA execution on havarti (so far we've just been doing emulation—no reason to expect real FPGA execution would be any different, but it would be super exciting).
• Building a more convenient, non-Xilinx testbench for the AXI stuff using cocotb or similar, so we can more quickly/easily debug this stuff in a reasonably automated way (and without touching xsim).
• Cleaning up fud's interface to FPGA execution so it's super easy to use, along the lines of [fud] xclbin stage should use Xilinx paths, etc., from the configuration rather than hard-coding them #1037.
• Getting deeper into exploiting FPGA stuff in Calyx! For example, we could look into using our FPGA's high-bandwidth memory (HBM). That would be a whole thing, but could be very cool.
• A possibly-terrible idea is trying to get Intel FPGAs working alongside Xilinx FPGAs! (As mentioned in Xilinx toolchain #876.)