-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Xilinx AXI test harness #1104
Comments
This would be great and is something we should prioritize doing before the end of the summer! |
FYI, this exists: https://github.com/alexforencich/cocotbext-axi. I've used it before with some success but it can be a little challenging to get working. My main suggestion here is to connect the m_axi ports to pre-existing axiram IPs that are initialized with the correct test data and only use cocotbext-axi for communicating with the axilite control. |
After discussing with @rachitnigam, the goal is to write a cocotb AXI test harness that would use Icarus Verilog (Verilator is only supported on version 4.106). |
Bumping this because this might be able to be closed as runt now contains tests that emulates AXI-wrapped hardware using cocotb on our vectorized-add and dot-product examples. The runt tests are here: |
Awesome!! Yep, I think we are done here. This is incredibly useful to have! |
Currently, we have two ways of running Calyx-generated RTL:
readmemh
.These two modes couple two dimensions:
It would be really nice to decouple these choices, creating a third mode where we run AXI-wrapped hardware on open-source simulators. This would make it much faster and less painful to debug the AXI wrapper itself—as conveniently as we currently debug just the "core" hardware.
This would entail, as discussed in #1022 (reply in thread) and thereafter, writing a testbench that implements the "host side" of the AXI protocol for a given design. There are several options on the table for doing that:
The text was updated successfully, but these errors were encountered: