axil_adapter_wr : Modelsim error "part select is reversed"

[peioazk]

Simulator: Modelsim

Tb connection:
axi4lite-master-bfm <-> axil_adapter <-> axil_ram

In simulation I found error:
" ** Fatal: (vsim-3373) /home/peio/fpgawork/cores/verilog-axi/rtl/axil_adapter_wr.v(215): Range of part-select into 'm_axil_awaddr_reg' is reversed."

axil_adapter_wr.v(215) is:
m_axil_wstrb_next = s_axil_wstrb << (m_axil_awaddr_reg[M_ADDR_BIT_OFFSET - 1:S_ADDR_BIT_OFFSET] * S_STRB_WIDTH);

M_ADDR_BIT_OFFSET=2
S_ADDR_BIT_OFFSET=2

simulator doesn't like m_axil_awaddr_reg[1:2]
is it a bug in axil_adapter_wr?

[AlexLao512]

I just ran into this problem as well in axi_axil_adapter_wr.v and axi_axil_adapter_rd.v I have to read through the issue some more and did some thinking and I believe the -1 should be removed in a few places in both files. I have not looked into it enough to confirm.

[AlexLao512]

I think I did it, #49

EDIT 0: Oh I'm sorry. I just realized you have a problem with axil_adapter not axi_axil_adapter. Seems the same issues are in all 3 variants (axi_adapter).

EDIT 1: Never mind, I misunderstood some things. Lets discuss in the MR. I think there are some reasonable workarounds.

[alexforencich]

Some simulators are buggy and complain incorrectly about unreachable code. Specifically what simulator are you using, and how are the module parameters set?

[peioazk]

In my case, simulator is Modelsim.
Parameters: ADDR_WIDTH(16), the default value for the others.

[AlexLao512]

Yea, I am using ModelSim 2020.1 here.

[crdavis12]

I get a similar error in Riviera (2022.04). Specifically with mixed language simulation of axi_axil_adapter (my top level is VHDL). I can run the included testbench in the same version of Riviera no problem.

AXI_STRB_WIDTH = AXIL_STRB_WIDTH = 4

SLP: Fatal Error: axi_axil_adapter_wr.v (338): Part-select direction [1:2] does not match the declared direction [31:0] for 'addr_reg'.

I was able to get around this by disabling SLP (-O2 option in Riviera). If there's a way to do this in ModelSim that might be worth a try.

[paul-demo]

I have the same issue -- there's an illegal slice in modules like axi_axil_adapter_wr.sv (and probably a few other places). Basically the design includes slices in both directions big:small and small:big, so they can't possibly both be valid and it causes VCS to error out.

Slices look like this:

addr_reg[(AXIL_ADDR_BIT_OFFSET - 1):AXI_ADDR_BIT_OFFSET]
AND
addr_reg[(AXI_ADDR_BIT_OFFSET - 1):AXIL_ADDR_BIT_OFFSET]

But if you have everything 32-bits wide, then:

AXIL_DATA_WIDTH = 32
AXIL_STRB_WIDTH = (AXIL_DATA_WIDTH/8) = 4
AXIL_ADDR_BIT_OFFSET = $clog2(AXIL_STRB_WIDTH) = 2

AXI_DATA_WIDTH = 32
AXI_STRB_WIDTH = (AXI_DATA_WIDTH/8) = 4
AXI_ADDR_BIT_OFFSET = $clog2(AXI_STRB_WIDTH) = 2

addr_reg[AXIL_ADDR_BIT_OFFSET-1:AXI_ADDR_BIT_OFFSET] = addr_reg[1:2] -> illegal slice

Just grepping for "ADDR_BIT_OFFSET", it looks like this bug affects 6 files:

• axi_adapter_rd.v
• axi_adapter_wr.v
• axil_adapter_rd.v
• axil_adapter_wr.v
• axi_axil_adapter_rd.v
• axi_axil_adapter_wr.v

What I think I'm going to do for now is add a compile time assertion that AXI_DATA_WIDTH == AXIL_DATA_WIDTH, and remove those slices everywhere. So, since there is no data width conversion happening, then lines like this:

data_next[addr_reg[AXI_ADDR_BIT_OFFSET-1:AXIL_ADDR_BIT_OFFSET]*SEGMENT_DATA_WIDTH +: SEGMENT_DATA_WIDTH] = m_axil_rdata;

Become this:

data_next = m_axil_rdata;

And lines like this:

s_axi_rdata_next = data_reg >> (addr_reg[AXIL_ADDR_BIT_OFFSET-1:AXI_ADDR_BIT_OFFSET] * AXI_DATA_WIDTH);

Just become this:

s_axi_rdata_next = data_reg;

[paul-demo]

Update: nevermind; I saw #28 is also a duplicate of this, and the issue is just that the slices are invalid in unreachable if/else clauses in an always_comb. A lot of tools require invalid slices like that to be in generate if/else clauses -- including our version of VCS, it turns out.

So, I'll just refactor the if/else to be outside the always_comb and be inside a generate/endgenerate.