cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,771 Views
Registered: ‎09-05-2019

ID Width on Crossbar with ACP

We are trying to put an AXI Crossbar between the fabric and ACP port.  By default the ACP port on the PS7 has WID and RID of 3 bits each.  When I connect to the AXI Crossbar, it gets set to 2 for some reason.  I do not have any threading setup on the crossbar.

It is configured as a 3 slave, 1 master crossbar, AXI3.  We generate the entire block diagram programmatically via TCL.  So to size things, I try to copy the settings from the PS7 ACP port, with commands like:

# Create the crossbar (name it acp_crossbar)
create_bd_cell -type ip -vlnv xilinx.com:ip:axi_crossbar:2.1 acp_crossbar

set_property -dict [list CONFIG.NUM_SI {3} CONFIG.NUM_MI {1}] [get_bd_cells acp_crossbar]

# Create the fabric ports create_bd_intf_port -mode Slave -vlnv xilinx.com:interface:aximm_rtl:1.0 s_axi_acp0
create_bd_intf_port -mode Slave -vlnv xilinx.com:interface:aximm_rtl:1.0 s_axi_acp1
create_bd_intf_port -mode Slave -vlnv xilinx.com:interface:aximm_rtl:1.0 s_axi_acp2

# Configure the ports. Here we copy the PS7 ACP details. set_property CONFIG.PROTOCOL [get_property CONFIG.PROTOCOL [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp0] set_property CONFIG.DATA_WIDTH [get_property CONFIG.DATA_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp0] set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp0] set_property CONFIG.AWUSER_WIDTH [get_property CONFIG.AWUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp0] set_property CONFIG.ARUSER_WIDTH [get_property CONFIG.ARUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp0]
set_property CONFIG.PROTOCOL [get_property CONFIG.PROTOCOL [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp1] set_property CONFIG.DATA_WIDTH [get_property CONFIG.DATA_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp1] set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp1] set_property CONFIG.AWUSER_WIDTH [get_property CONFIG.AWUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp1] set_property CONFIG.ARUSER_WIDTH [get_property CONFIG.ARUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp1]
set_property CONFIG.PROTOCOL [get_property CONFIG.PROTOCOL [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp2] set_property CONFIG.DATA_WIDTH [get_property CONFIG.DATA_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp2] set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp2] set_property CONFIG.AWUSER_WIDTH [get_property CONFIG.AWUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp2] set_property CONFIG.ARUSER_WIDTH [get_property CONFIG.ARUSER_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_ports s_axi_acp2]
# Connect the ports to the crossbar
connect_bd_intf_net [get_bd_intf_pins acp_crossbar/S00_AXI] [get_bd_intf_ports s_axi_acp0]
connect_bd_intf_net [get_bd_intf_pins acp_crossbar/S01_AXI] [get_bd_intf_ports s_axi_acp1]
connect_bd_intf_net [get_bd_intf_pins acp_crossbar/S02_AXI] [get_bd_intf_ports s_axi_acp2]

# Connect the crossbar to the ACP port on the PS7 connect_bd_intf_net [get_bd_intf_pins acp_crossbar/M00_AXI] [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]

 

But when validating, it fails with:

ERROR: [BD 41-237] Bus Interface property ID_WIDTH does not match between /ps7_subsystem/S_AXI_ACP(3) and /acp_crossbar/M00_AXI(5)

So, I tried to change with width of M00_AXI to match, using:

set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_pins acp_crossbar/M00_AXI]

But it appears that property is read-only:

CRITICAL WARNING: [BD 41-737] Cannot set the parameter ID_WIDTH on /acp_crossbar/M00_AXI. It is read-only.

Which again leads to:

ERROR: [BD 41-237] Bus Interface property ID_WIDTH does not match between /ps7_subsystem/S_AXI_ACP(3) and /acp_crossbar/M00_AXI(5)

So I tried perhaps setting the ID_WIDTH only the slave sides, thining perhaps it would propagate to the master side, with:

set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_pins acp_crossbar/S00_AXI]

set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_pins acp_crossbar/S01_AXI]

set_property CONFIG.ID_WIDTH [get_property CONFIG.ID_WIDTH [get_bd_intf_pins ps7_subsystem/S_AXI_ACP]] [get_bd_intf_pins acp_crossbar/S02_AXI]

And same critical warning:

CRITICAL WARNING: [BD 41-737] Cannot set the parameter ID_WIDTH on /acp_crossbar/S00_AXI. It is read-only.

CRITICAL WARNING: [BD 41-737] Cannot set the parameter ID_WIDTH on /acp_crossbar/S01_AXI. It is read-only.

CRITICAL WARNING: [BD 41-737] Cannot set the parameter ID_WIDTH on /acp_crossbar/S02_AXI. It is read-only.

And finally I tried just setting the ID_WIDTH on all the fabric ports to 0, thinking perhaps this would equate to "auto", with:

set_property CONFIG.ID_WIDTH {0} [get_bd_intf_ports s_axi_acp0]

set_property CONFIG.ID_WIDTH {0} [get_bd_intf_ports s_axi_acp1]

set_property CONFIG.ID_WIDTH {0} [get_bd_intf_ports s_axi_acp2]

And this validates.

But what gets generated is s_axi_acp0_awid[1:0], etc.  I have no idea where it is getting the 2.  Further, later during synthesis, I get warnings:

WARNING: [BD 41-235] Width mismatch when connecting pin: '/ps7_subsystem/S_AXI_ACP_AWID'(3) to net 'acp_crossbar_M00_AXI_AWID'(2) - Only lower order bits will be connected.
WARNING: [BD 41-235] Width mismatch when connecting pin: '/ps7_subsystem/S_AXI_ACP_WID'(3) to net 'acp_crossbar_M00_AXI_WID'(2) - Only lower order bits will be connected.
WARNING: [BD 41-235] Width mismatch when connecting pin: '/acp_crossbar/m_axi_bid'(2) to net 'acp_crossbar_M00_AXI_BID'(3) - Only lower order bits will be connected.
WARNING: [BD 41-235] Width mismatch when connecting pin: '/ps7_subsystem/S_AXI_ACP_ARID'(3) to net 'acp_crossbar_M00_AXI_ARID'(2) - Only lower order bits will be connected.
WARNING: [BD 41-235] Width mismatch when connecting pin: '/acp_crossbar/m_axi_rid'(2) to net 'acp_crossbar_M00_AXI_RID'(3) - Only lower order bits will be connected.

So, how do I propagate the ID_WIDTH on the PS7 ACP port through the crossbar to the fabric ports?

Tags (2)
0 Kudos
7 Replies
demarco
Xilinx Employee
Xilinx Employee
1,682 Views
Registered: ‎10-04-2016

Hi pete_ladow@selinc.com ,

You are seeing expected behavior. From a high level, two things determine the number of AXI ID bits in a system:

1. The number of AxID/WID bits the endpoint master drives.

2. The number of Snn_AXI interfaces that the crossbar implements. 

The AXI Interconnect PG goes into detail about why and how it appends ID bits on top of the AxID bits that the endpoint master drives. 

https://www.xilinx.com/support/documentation/ip_documentation/axi_interconnect/v2_1/pg059-axi-interconnect.pdf#page=73

To figure out the number of ID bits on the MI interface for the Crossbar, you first determine which SI has the most ID bits. (In your case, none of them have ID bits.) You then append sufficient bits to distinguish between the SIs. You mention that you have 3 slave interfaces, so the Crossbar appends two ID bits. So the Crossbar MI drives AxID[1:0] and WID[1:0] and expects BID/RID[1:0]. 

You can safely ignore the Critical Warnings about the mismatched ID bit widths. The tools should tie off xxID[2] to 1'b0.

Regards,

Deanna

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,658 Views
Registered: ‎09-05-2019

@demarco 

I did manage to get it to work, and the ID bits are sized as 3-bits throughout, with no errors.  I also looked at the generated source, and it is correct.  No ID bits tied to ground.

I had to set CONFIG.PROTOCOL to AXI3 and set CONFIG.ID_WIDTH to 3, both on the crossbar itself, not on the individual ports.  Doing this, it generated 3-bit IDs on all the slave interfaces and the master interface.

1,628 Views
Registered: ‎09-05-2019


pete_ladow@selinc.com wrote:

@demarco 

I did manage to get it to work, and the ID bits are sized as 3-bits throughout, with no errors.  I also looked at the generated source, and it is correct.  No ID bits tied to ground.

I had to set CONFIG.PROTOCOL to AXI3 and set CONFIG.ID_WIDTH to 3, both on the crossbar itself, not on the individual ports.  Doing this, it generated 3-bit IDs on all the slave interfaces and the master interface.


@demarco 

I quickly posted, but my solution doesn't correlate to your answer, where you said:

To figure out the number of ID bits on the MI interface for the Crossbar, you first determine which SI has the most ID bits. (In your case, none of them have ID bits.) You then append sufficient bits to distinguish between the SIs. You mention that you have 3 slave interfaces, so the Crossbar appends two ID bits. So the Crossbar MI drives AxID[1:0] and WID[1:0] and expects BID/RID[1:0]. 

So how then does this change I made work with 3 slaves and 1 master?

0 Kudos
demarco
Xilinx Employee
Xilinx Employee
1,602 Views
Registered: ‎10-04-2016

Hi pete_ladow@selinc.com ,

I typed a little too fast in my first response. For the original case, I should have said:

To figure out the number of ID bits on the MI interface for the Crossbar, you first determine which SI has the most ID bits. (In your case, all of the interfaces have 3 address bits.) You then append sufficient bits to distinguish between the SIs. You mention that you have 3 slave interfaces, so the Crossbar appends two ID bits. So the Crossbar MI drives AxID[4:0] and WID[4:0] and expects BID/RID[4:0].

I ran through your initial script and the error I saw corresponds to this expectation:

ERROR: [BD 41-237] Bus Interface property ID_WIDTH does not match between /processing_system7_0/S_AXI_ACP(3) and /acp_crossbar/M00_AXI(5)

So why does the second case work where you configure the crossbar to have an ID width of three bits? Does all of that appending to sort out which SI a transaction come from still happen?

The previously mentioned section of PG059 does a very good job of explaining what the tools do. I'll just fill in the numbers from your design.

You have 3 SI in your Crossbar, so BASE_ID is 2 bits.

The THREAD_ID_WIDTH of your Crossbar is 1. You can see this on the Slave Interfaces tab of the Crossbar Config GUI. The THREAD_ID_WIDTH comes from the NUM_READ_THREADS/NUM_WRITE_THREADS property on the a_axi_acpN input ports to the block diagram.

This means the Crossbar needs a minimum ID_WIDTH of ceil_log2 NUM_SI + max(THREAD_ID_WIDTH) = 2 + 1 = 3.

You need a minimum ID width for the Crossbar of 3. You set your Crossbar to have an ID_WIDTH of 3, so the math works out on this case. If you set the ID_WIDTH to something smaller, I'd expect to see some errors.

Regards,

Deanna

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,586 Views
Registered: ‎09-05-2019

I understand the use of ID's to route responses, and in simulation I see that.  But what remains unclear is how I can have matching IDs widths on the slaves and the master port.

With the CONFIG.PROTOCL set to AXI3 and CONFIG.ID_WIDTH set to 0, I'm ending up with each slave interface having a 3-bit ID and the master interface having a 3-bit ID.  Does this mean that some IDs cannot be used on the slave interfaces?

For example, if S00 receives an ID of "111", how does that translate to an ID on the master interface?  Say the X-bar assigned IDs of 0, 1, and 2 to S00, S01, and S02, respectively.  Would the ID on the master interface when forwarding the S00 request have an ID of 0?  So the crossbar internally buffers the "111" ID to echo back when the transaction completes?

It seems to me that I've effectively configured things with a THREAD_ID_WIDTH of 0?  So no ID bits on the slaves are sampled (as per PG059, p. 74: "The AXI Crossbar only samples the ID bits defined by the THREAD_ID_WIDTH parameter for each SI slot.")?  This is fine with me.

I'm just trying to make sure, as configured, we won't get mis-routed responses in this configuration.  So far in simulation it doesn't appear to do so.  But it isn't clear why one configuration produces 2-bit IDs on the slave (with a 2-bit ID on the master) and 3-bit IDs on both.

 

0 Kudos
demarco
Xilinx Employee
Xilinx Employee
1,575 Views
Registered: ‎10-04-2016

Hi pete_ladow@selinc.com ,

The Crossbar does track the incoming SI IDs versus the outgoing MI IDs. It makes sure that when it forwards a response from the endpoint slave back to the endpoint master, the appropriate IDs are restored. Misrouting should not occur.

For example, if S00 receives an ID of "111", how does that translate to an ID on the master interface?  Say the X-bar assigned IDs of 0, 1, and 2 to S00, S01, and S02, respectively.  Would the ID on the master interface when forwarding the S00 request have an ID of 0?  So the crossbar internally buffers the "111" ID to echo back when the transaction completes?

Yes, this is the behavior I would expect. Similarly, if S02 receives an ID of 3'b111, I'd expect the ID on the M00 to be 3'b100.

Most masters do not support multi-threading, so generally the THREAD_ID_WIDTH is 0. The PS blocks in the Zynq products are examples of masters that do support multi-threading.

I'm a little confused by this statement: But it isn't clear why one configuration produces 2-bit IDs on the slave (with a 2-bit ID on the master) and 3-bit IDs on both.

I'm not sure which configuration generates the 2-bit IDs on the slave (with a 2-bit ID on the master). From the TCL commands in your initial post, you had an error situation with 3-bit IDs on the three SIs and 5 on the MI. The "it validates" but throws warnings work around had a 0-bit ID width on the three SIs and a 2-bit ID on the MI.

When you configured the Crossbar IP to have a 3-bit ID, that forced both the SIs and MI to have 3-bit IDs.

The difference in the situations you described is that you were configuring the interfaces versus the IP. That is going to cause the tools to infer different desired behavior.

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
8bitmode
Observer
Observer
719 Views
Registered: ‎04-26-2019

Glad I stumbled on this thread.  Great discussion and has filled in some blanks for me with respect to PG059.

One item that still seems ambiguous is the example above, and how Master ID concatenation works; in fact the example seems to suggest that no ID concatenation has taken place at all, but instead a Slave-to-Master ID substitution of sorts.

Specifically, here's the running example:

For example, if S00 receives an ID of "111", how does that translate to an ID on the master interface?  Say the X-bar assigned IDs of 0, 1, and 2 to S00, S01, and S02, respectively.  Would the ID on the master interface when forwarding the S00 request have an ID of 0?  So the crossbar internally buffers the "111" ID to echo back when the transaction completes?

Yes, this is the behavior I would expect. Similarly, if S02 receives an ID of 3'b111, I'd expect the ID on the M00 to be 3'b100.

S00 receiving an ID of 3'b111 suggests (to me) that S00 is utilizing all 3 of its ID bits.  Wouldn't the Xbar need to concatenate two additional bits onto 3'b111 in order to uniquely associate it with S00 out on the external M00-side fabric, given that we have 3 Slaves in the example?  So if the Xbar has assigned ID of 0 (2'b00) to S00, I guess I would expect M00 to need a 5-bit vector for its expanded ID, and its value would be 5'b00111 to uniquely identify the S00 ID of 3'b111.

However the example suggests that the Xbar instead substitutes S00 ID=3'b111 with a master-side M00 ID=3'b000, as opposed to concatenation.  And similarly for the follow-on example (S02 ID=3'b111 is substituted with M00 ID=3'b100).

Can you help me sort through my confusion?  Thanks!

 

0 Kudos