roalogic / ahb3lite_interconnect Goto Github PK

When the IP is configured with a single master Verilator throws warnings due to $clog2(1) = 0. All vectors dependent on MASTER_BITS and PRIORITY_BITS become vec[-1:0].

%Warning-LITENDIAN: ../src/ahb3lite_intercon_1.1-r1/rtl/verilog/ahb3lite_interconnect.sv:215: Little bit endian vector: MSB < LSB of bit range: -1:0

In the document,the signal mst_HRESP of master port is described ‘input’， but it should be 'output'.

when it try to compile standalone RTL as :

xrun submodules/ahb3lite_pkg/rtl/verilog/ahb3lite_pkg.sv rtl/verilog/*.sv

I'm getting following error:

  function slave_mask_t invert_slave_mask;
                                        |
xmvlog: *E,CFBADT (../rtl/verilog/ahb3lite_interconnect.sv,197|40): Declaration in constant function uses unavailable datatype.
  function slave_mask_t invert_slave_mask;
                                        |
xmvlog: *E,CFBADT (../rtl/verilog/ahb3lite_interconnect.sv,197|40): Declaration in constant function uses unavailable datatype.
  parameter bit [SLAVES-1:0] ERROR_ON_SLAVE_MASK[MASTERS] = invert_slave_mask(),
                                                                            |
xmvlog: *N,CFCALL (../rtl/verilog/ahb3lite_interconnect.sv,136|76): Function invert_slave_mask treated as a constant function because of this call.
	module worklib.ahb3lite_interconnect:sv

What do I miss?

I use xcellium version 20.03-s003

Hi @rherveille and @sphardy ,
I'm using the interconnect to integrate 2x AHB memories as slaves and 2x masters that represents the interfaces of a CPU (I/D Bus). So, the problem that I'm facing right now that in some requests from the masters with conflicts, where it overlap the addresses (both I/D buses are requesting on the same range), the slave does not receive the requests as it should.

In the image above, you can see that both interfaces are requesting on the same range and in the memory perspective, the two requests are not achieving the slave. Also, in another moments like the image below, both requests are answered with the correct signals been driven by the interconnect.

Ps.: the memory address of IRAM it's 0xAA0000 with 16k of range