alexforencich/cocotbext-axi

AxiLiteSlave: object has no attribute 'aw'

rodrigomelo9 opened this issue · 8 comments

I found the issue trying to verify an AXI Lite master that I am developing. Maybe I am doing something wrong (I didn't find an example using it). Anyway, the easy way to see the problem in action:

  • Change the content of tests/axil/test_axil.py with:
import cocotb
from cocotbext.axi import AxiLiteBus, AxiLiteMaster, AxiLiteSlave

@cocotb.test()
async def test_master(dut):
    axil_mst = AxiLiteMaster(AxiLiteBus.from_prefix(dut, 'axil'), dut.clk, dut.rst)

@cocotb.test()
async def test_slave(dut):
    axil_slv = AxiLiteSlave(AxiLiteBus.from_prefix(dut, 'axil'), dut.clk, dut.rst)
  • Run make
  • The result is:
     1.00ns INFO     test_master passed
     1.00ns INFO     running test_slave (2/2)
     2.00ns INFO     test_slave failed
                     Traceback (most recent call last):
                       File "/home/rodrigo/repos/0thers-axi/cocotbext-axi/tests/axil/test_axil.py", line 10, in test_slave
                         axil_slv = AxiLiteSlave(AxiLiteBus.from_prefix(dut, 'axil'), dut.clk, dut.rst)
                       File "/usr/local/lib/python3.8/dist-packages/cocotbext/axi/axil_slave.py", line 254, in __init__
                         self.write_if = AxiLiteSlaveWrite(target, bus.write, clock, reset, reset_active_level)
                       File "/usr/local/lib/python3.8/dist-packages/cocotbext/axi/axil_slave.py", line 41, in __init__
                         self.log = logging.getLogger(f"cocotb.{bus.aw._entity._name}.{bus.aw._name}")
                     AttributeError: 'NoneType' object has no attribute 'aw'
     2.00ns INFO     **************************************************************************************
                     ** TEST                          STATUS  SIM TIME (ns)  REAL TIME (s)  RATIO (ns/s) **
                     **************************************************************************************
                     ** test_axil.test_master          PASS           1.00           0.00        293.23  **
                     ** test_axil.test_slave           FAIL           1.00           0.00       5949.37  **
                     **************************************************************************************
                     ** TESTS=2 PASS=1 FAIL=1 SKIP=0                  2.00           0.04         51.31  **
                     **************************************************************************************

Ah yep, there were a couple of bugs there that I have sorted out, will push a fix soon. There aren't really any examples of the AXI/AXI lite slave modules as they are a bit special purpose, normally you'll probably want to use the AXI/AXI lite RAM, which is an extension of the AXI/AXI lite slave.

Got it, I'm going to try with the AXI/AXIL RAM and let you know.

I successfully used AxiLiteRAM with my AXI4 Lite master (and I fixed some issues as consequence). Great idea to easily check the basic functionality of a master ;-)

I have a question: whenever I set AxPROT with a value different to 1, 2 or 4, I receive a ValueError:

    13.00ns INFO     test_basic failed
                     ValueError: 011 is not a valid AxiProt

As far I know, any combination is valid, right? I never worry about AxPROT before, but I used it as 000 in the past without problems (Xilinx).

Hmm, that's very odd. Is there a line number associated with that exception? AxiProt should be a flag field, and as such all combinations of bits should be valid.

In [1]: from cocotbext.axi import AxiProt

In [2]: AxiProt(0b011)
Out[2]: <AxiProt.NONSECURE|PRIVILEGED: 3>

And the default that you should normally be using is 0b010, as this sets the "nonsecure" bit. Although it won't make a difference unless you're using something like ARM TrustZone, in which case using 0b000 could end up allowing a device to bypass the TrustZone protections. The idea is that the interconnect components can have "secure" devices that are only accessible by operations with the nonsecure bit clear, and the CPU will issue operations with this bit clear only when operating in certain secure execution modes, and with the bit set in non-secure execution modes.

I am using AxiLiteRAM:

axil_ram = AxiLiteRam(AxiLiteBus.from_entity(dut), dut.aclk)

And here is the exception:

    32.00ns INFO     The core was reset
    36.00ns ERROR    Exception raised by this forked coroutine
    37.00ns INFO     test_burst failed
                     ValueError: 000 is not a valid AxiProt
                     
                     During handling of the above exception, another exception occurred:
                     
                     Traceback (most recent call last):
                       File "/usr/local/lib/python3.8/dist-packages/cocotbext/axi/axil_slave.py", line 110, in _process_write
                         prot = AxiProt(getattr(aw, 'awprot', AxiProt.NONSECURE))
                       File "/usr/lib/python3.8/enum.py", line 339, in __call__
                         return cls.__new__(cls, value)
                       File "/usr/lib/python3.8/enum.py", line 670, in __new__
                         raise exc
                       File "/usr/lib/python3.8/enum.py", line 653, in __new__
                         result = cls._missing_(value)
                       File "/usr/lib/python3.8/enum.py", line 895, in _missing_
                         raise ValueError("%r is not a valid %s" % (value, cls.__name__))
                     ValueError: 000 is not a valid AxiProt

Hmm, looks like I need to explicitly convert that to an integer before converting to AxiProt.

Try again with the current git version and let me know if you're still seeing the same issue.

Yes, it works with the current version at master :-D

Based on one of the last logs (Fix AxiLiteSlave wrapper), I re-check axil_slv = AxiLiteSlave(AxiLiteBus.from_entity(dut), dut.aclk) and it also works, so this issue can be closed.

Thanks Alex, I am very happy using cocotbext-axi in the development of AXI masters at my job ;-) I think that is a very valuable project.

Regards,
Rodrigo