axi_xbar: Change default master port setting from input to parameter about axi HOT 3 OPEN

@WRoenninger: What do you think?

from axi.

Yes, as you mentioned, the intend was to have the default ports runtime configurable. However I have not seen this feature being used dynamically yet and see the overhead that arises when trying to use it.

I am fine with changing it to a parameter. However this should probably be done after #157 as there is the whole config struct replacement going on.

Also this ties in with an issue I see with the addr_decode from common_cells. The recommended struct definition there is:

  typedef struct packed {
    int unsigned idx;
    addr_t       start_addr;
    addr_t       end_addr;
  } rule_t;

The main issue that can happen with this struct definition is that some tools do not like the int unsigned inside of a packed structure. For the default mst_port functionality it should not be an issue, as the decoder requires the cf_math_pkg::idx_width(NumIdx) typed index for its default mapping anyway, because the decoder does a typecast form addr_map_i.idx to this idx_t when it is checking the address map for a rule.
I am wondering if it would be a good idea to recommend defining the addr_map_t.idx field to be of type idx_t or a set a fixed width logic in the example rules found in axi_pkg?
So e.g. the rule xbar_rule_32_t would then read:

  typedef struct packed {
    logic [31:0] idx;
    logic [31:0] start_addr;
    logic [31:0] end_addr;
  } xbar_rule_32_t;

This struct definition change should not have any influence on the behavior of addr_decode and help with tool compatibility.

from axi.

However this should probably be done after #157 as there is the whole config struct replacement going on.

Okay, I agree.

I am wondering if it would be a good idea to recommend defining the addr_map_t.idx field to be of type idx_t or a set a fixed width logic in the example rules found in axi_pkg?

Yes, makes sense to me.

from axi.