axi_xbar_unmuxed: judge the connection relationship before routing

[Alvin-FA]

For demux, we can check the connectivity before routing, this can improve transmission efficiency. The more there are such case that connectivity[i][j] == 0 between slave_port[i] and mst_port[j], the better the improvement effect will be. Because the unnecessary arbitrations have been reduced, this accelerates the correct access response. At the same time, ensure that there is a dedicated port to receive decode errors as before.

[micprog]

This looks like an interesting improvement! I have one concern: What happens if a specific port has en_default_mst_port_i set and the default_mst_port_i for that slv_port is not connected? Let's double-check that we can handle this scenario correctly as well.

[Alvin-FA]

This looks like an interesting improvement! I have one concern: What happens if a specific port has en_default_mst_port_i set and the default_mst_port_i for that slv_port is not connected? Let's double-check that we can handle this scenario correctly as well.

I think this scenario belongs to a configuration file error. If someone use en_default_mst_port_i and default_mst_port_i, he/she should ensure the connectivity correctly. Unfortunately, if this scenario really occurs, we can only ensure that the route to the instantiation of axi_err_slv module to avoid deadlock.

[micprog]

This looks like an interesting improvement! I have one concern: What happens if a specific port has en_default_mst_port_i set and the default_mst_port_i for that slv_port is not connected? Let's double-check that we can handle this scenario correctly as well.

I think this scenario belongs to a configuration file error. If someone use en_default_mst_port_i and default_mst_port_i, he/she should ensure the connectivity correctly. Unfortunately, if this scenario really occurs, we can only ensure that the route to the instantiation of axi_err_slv module to avoid deadlock.

I agree, if this occurs, then whoever set this up made a mistake. Nonetheless, we can still support this case, maybe with a parameter as an option to disable it?

I think we could directly handle this by setting the corresponding default_idx_i of the addr_decode modules as follows:

-      .default_idx_i ( default_mst_port_i[i] )
+      .default_idx_i ( Connectivity[i][default_mst_port_i[i]] ? default_mst_port_i[i] : mst_port_idx_t'(Cfg.NoMstPorts) )

There may be some PPA implications in non-static cases, but this approach should still properly return DECERR for routing to an unconnected region.

[Alvin-FA]

This looks like an interesting improvement! I have one concern: What happens if a specific port has en_default_mst_port_i set and the default_mst_port_i for that slv_port is not connected? Let's double-check that we can handle this scenario correctly as well.

I think this scenario belongs to a configuration file error. If someone use en_default_mst_port_i and default_mst_port_i, he/she should ensure the connectivity correctly. Unfortunately, if this scenario really occurs, we can only ensure that the route to the instantiation of axi_err_slv module to avoid deadlock.

I agree, if this occurs, then whoever set this up made a mistake. Nonetheless, we can still support this case, maybe with a parameter as an option to disable it?

I think we could directly handle this by setting the corresponding default_idx_i of the addr_decode modules as follows:

-      .default_idx_i ( default_mst_port_i[i] )
+      .default_idx_i ( Connectivity[i][default_mst_port_i[i]] ? default_mst_port_i[i] : mst_port_idx_t'(Cfg.NoMstPorts) )

There may be some PPA implications in non-static cases, but this approach should still properly return DECERR for routing to an unconnected region.

Excellent! It is a very ingenious solution.