cocotb VS cocotbext-axi

The use of cocotb and pyuvm for verification

For FPGA/HDL work, there's cocotb

At the moment, it is not possible to directly simulate synthesizable contexts. In principle, I could add a simulator to CoHDL. As a Python implementation, it would be orders of magnitude slower than other solutions. Instead, I am using Cocotb to validate the generated VHDL and for the unit tests in the GitHub repository. There is also some very, very experimental support for formal verification, but it will take some time for that to become usable.

On the topic of simulation, you don't have to restrict yourself to using Verilog or VHDL to write your test benches. For example, Verilator lets you write them in C++, cocotb lets you use Python, and if you use SpinalHDL you will drive the underlying simulator using Scala.

I know it might be difficult without much context, but this makefile is called by a top level makefile. very confused if lines 35-74 do anything. They seem to be a mix of real makefile syntax and just straight up comments. what do these lines do?

Learn more about this here: https://www.cocotb.org/

Also consider cocotb, this thread has some compelling arguments. I'd say as a student, learning industry tools isn't necessarily the best thing you could spend your time on. Getting fast at design AND verification, where you can maintain flow state and run better microexperiments means you will understand more, faster.

Have you tried looking at the mixed language example?

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.