cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
903 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?

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
814 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
Highlighted
790 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.

Highlighted
760 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
Highlighted
Xilinx Employee
Xilinx Employee
734 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
Highlighted
718 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
Highlighted
Xilinx Employee
Xilinx Employee
707 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