pyxsi VS cocotbext-axi

These three environments are glued together using pyxsi, which embeds Xilinx's simulator kernel (xsim). The result is a complicated monolith, but avoids the following "Bad Practices for Complex Dataflow":

Adam mentions it in his Aduvio post, but pyxsi shows how to stack Python on C/C++ on Vivado. (Disclaimer: mine.)

The sketch here is a little stale but shows the general idea.

I'm trying to understand if we can use the Vivado XSI to make our verification tasks easier and improve our coverage via a more productive language like C++ or python. I found an interesting project (https://github.com/gsmecher/pyxsi) that uses it but I'm still unsure if this is worth investing time on (given how many issues Xilinx tools usually have).

0.00ns INFO ..b.dma_wrapper.m_axi_s2mm AXI slave model (write) 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm cocotbext-axi version 0.1.24 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm Copyright (c) 2021 Alex Forencich 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm https://github.com/alexforencich/cocotbext-axi 0.00ns DEBUG gpi m_axi_s2mm_awvalid has 1 elements 0.00ns DEBUG gpi m_axi_s2mm_awprot has 3 elements 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm Reset de-asserted 0.00ns DEBUG gpi m_axi_s2mm_wvalid has 1 elements 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm Reset de-asserted 0.00ns DEBUG gpi m_axi_s2mm_bvalid has 1 elements 0.00ns DEBUG gpi m_axi_s2mm_bready has 1 elements 0.00ns DEBUG gpi m_axi_s2mm_bresp has 2 elements 0.00ns INFO ..b.dma_wrapper.m_axi_s2mm Reset de-asserted 0.00ns DEBUG gpi m_axi_s2mm_awaddr has 32 elements

I was hoping to decouple the designs from any particular vendor as much as I could so I would interface with the core (dut) with a Cocotb AXI Lite master to get/set registers. Then if I were using something like an AXI Stream to send/receive audio or video data there was a Cocotb python driver to process the data in the test bench. As an example, in part 5 the graphics core generated a 16x4 color bar image over AXI video stream that was captured by a Cocotb AXI Stream sink and then 'displayed' as hex values in one of the test.

This is where you can use a BFM (bus functional model). Basically, you can connect your design to a simulation model of the RAM. I wrote some cocotb extensions for doing stuff like this in cocotb, you can give that a try, assuming your code works with a simulator that's compatible with cocotb: https://github.com/alexforencich/cocotbext-axi

The cocotb bus repo has many of the useful drivers and monitors. https://github.com/cocotb/cocotb-bus/tree/master/src/cocotb_bus. There is also https://github.com/alexforencich/cocotbext-axi for some relevant AXI examples that you can also just use.