AXI Transaction ID Filtering¶
In order to facilitate constraining the recovery core’s accessibility, the I3C core implements an AXI transaction ID filtering mechanism.
Transaction IDs are passed using the aruser
and awuser
signals.
The ID filtering logic is optional and depends on the AXI_ID_FILTERING
macro definition.
Recovery core configuration includes a parameter denoting the NUM_PRIV_IDS
- number of privileged IDs that are granted read and write access when the filtering mechanism is enabled.
Having AXI_ID_FILTERING
defined requires NUM_PRIV_IDS
to be greater than 0. This is verified with an assertion.
Undefined AXI_ID_FILTERING
and non-zero NUM_PRIV_IDS
are considered a legal configuration and causes the ID filtering logic to not be included in the design.
The filtering mechanism is controlled via:
disable_axi_filtering_i
recovery core port to disable the filtering mechanism1'b0
- enable AXI filtering1'b1
- disable AXI filtering
[0:AXI_ID_WIDTH-1] priv_ids_i [0:NUM_PRIV_IDS-1]
recovery core port containing privileged IDsEach privileged ID should be of width
AXI_ID_WIDTH
passed atpriv_ids_i[k]
for each k in {0 … NUM_PRIV_IDS - 1}All
NUM_PRIV_IDS
entries are expected to be set to valid privileged IDs
When the filtering is enabled, any transaction attempt outside of the privileged IDs will be met with a SLVERR
(0b10
) error on the respective AXI response channel.
The above-mentioned disable_axi_filtering_i
and priv_ids_i
ports will not be included in the design if AXI_ID_FILTERING
is not defined.