cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fishere
Visitor
Visitor
1,347 Views
Registered: ‎11-27-2019

AXI Wizard - unconnected internal ports synthesis warnings

Jump to solution

Hi All,

 

Having been using the AXI wizard for our interconnect needs, our design is functionally correct. However, despite the editable outer levels of the AXI system all being correct, Vivado synthesis generates multiple warnings of the variety of:

- [Synth 8-3331] design s02_couplers_imp_SMU08S has unconnected port M_AXI_bid[3], and

- [Synth 8-3331] design s02_couplers_imp_SMU08S has unconnected port M_AXI_bid[2]...

 

At the AXI top level, bid for S00, S01 and S02 are each 2 bits (0:1), are connected, and the port within the AXI block design is also set to 2 bits wide. The couplers however are within the AXI interconnect design and as customary are only editable via pass through of the top level's wizard settings. The couplers, as I understand it, interface to the cross bar, which again uses parameters passed down from the top level.

The AXI design simulates correctly, utilises bid (hence the confusion) and as part of the design wizard passes validation.

Question:

- What is the cause of such synthesis warnings, and how can they be removed. Our application is one in which we much remove or justify all warnings.

Many thanks,

Ed

0 Kudos
1 Solution

Accepted Solutions
markcurry
Scholar
Scholar
997 Views
Registered: ‎09-16-2009

Ed,

Ok, that's reasonable behavior by the AXI wizard, and the tools.  Here's what's happening.

The AXI Masters only need to drive 2 bits (per their THREAD_ID requirements) on AWID, and ARID.  In response, these masters only expect 2 bit IDS returned on RID, and BID.  However system requirements dictate the 4-bit total AXI ID_WIDTH. This is because the AXI interconnect needs those extra bits in order to route the RID, and BID response back to the correct AXI Master.  The AXI interconnect takes care of all of this for you.  

Each Master drives (only) 2-bit ARID, and AWID.  The AXI Interconnect takes care of assigning the top two bits (uniquely) on each one of these ports.  This total 4-bits is then is what is sent to all slaves.  Which in return to a Write, or Read request, the AXI slaves reflect the 4 bit AWID -> BID (or ARID->RID for reads).  The AXI Interconnect uses the top-two bits to know which AXI Master to send the responses to.  At the perimeter of the AXI Interconnect where the final BID, and RID are returned to the master, the AXI Interconnect removes those extra two bits (since the masters aren't expecting them).  But the RID, and BID ports are still 4 bits.  So it drives those two bits to a zero.  The AXI Masters, needing only 2-bits of ID, ignore (don't even sample) those two high bits of RID, and BID.  Synthesis/back end tools optimize those two extra (constant value) bits away.  The warning is generated.

Regards,

Mark

View solution in original post

0 Kudos
12 Replies
richardhead
Scholar
Scholar
1,314 Views
Registered: ‎08-01-2012

Technically, in the AXI spec, WID, BID etc are all fixed in the spec at 8 bits. Xilinx allows parameterisation because it knows most people either dont use it at all or just use a limited number of bits. The internal IP blocks that are built into your interconnect all likely have 8 bit XID signals to match the spec, but the unused bits are just tied to 0 or left unconnected (which will likely tie them to 0 during synthesis, hence the warnings.

There is nothing you can do about it. IP blocks from all manufacturers will often throw out many warnings (in our build we have 1000s of them)

FPGA designers have come to generally ignore warnings, only paying attention to critical warnings and looking into the warning when things dont appear to be working correctly.

0 Kudos
fishere
Visitor
Visitor
1,306 Views
Registered: ‎11-27-2019

Thanks Richard.

Would it be advisable then to set these to 8 bits in the wizard and manually tie the unused bits to '0'.

For DO-254 etc, we must remove or justify all such warnings. If this can be safely ignored, then that's great, however is there any formal Xilinx advice on this such as an Answer Record, as justification would need traceability back to a formal vendor document etc.

If removing these synthesis warnings is difficult or not particularly worth the hassle, the only option is justification for its presence and a suitable reason from Xilinx.

Compliance ehh...

Cheers,

0 Kudos
richardhead
Scholar
Scholar
1,292 Views
Registered: ‎08-01-2012

A quick google cannot find an answer record on this. A more thourough search may.

I suggest connecting everything to 0 as you suggest (it should get reduced anyway - then you'll probably get warnings about signals tied to ground!)

0 Kudos
markcurry
Scholar
Scholar
1,280 Views
Registered: ‎09-16-2009

(Prelude: we don't use the Xilinx AXI Wizard.  But do us a LOT of AXI IP, both our own homegrown, Xilinx IP, and other third party IP)

Picking nits, but I don't think there's anything in the ARM standard indicating the xID signals as being fixed at 8 bits - Richard where did you read this?  The signals are sized as needed.  For example, on the MPSOC designs, most of the xID signals are 16 bits.  Any AXI slave peripheral should have a parameterized ID ports in order to reflect back the Read data to the correct thread on the master.  So for MPSOC that's going to be at LEAST 16 bits.  (On our design with multiple masters the final ID widths are 18 bits).

Regards,

Mark

 

 

 

 

richardhead
Scholar
Scholar
1,276 Views
Registered: ‎08-01-2012

@markcurry 

You are right. I have seen some BFMs that locked it to 8 bits, but now reading the spec again (its been a while), its actually marked as implementation defined, with 8 bits being the recommended value:

The width of transaction ID fields is IMPLEMENTATION DEFINED. However, this specification recommends the
following transaction ID field widths:
• for master components, implement a transaction ID field up to four bits
• for master port numbers in the interconnect, implement up to four additional bits of transaction ID field
• for slave components, implement eight bits of transaction ID field support.
For masters that support only a single ordered interface, it is acceptable to tie the transaction ID field outputs to a
constant value, for example, tie to zero.
For slaves that do not make use of the ordering information and process all transactions in order, the transaction ID
functionality can be added without changing the base functionality of the slave.

So i guess that Xilinx internally lock everything to 8 (as per recommendation).

0 Kudos
markcurry
Scholar
Scholar
1,262 Views
Registered: ‎09-16-2009

Xilinx does NOT lock everything to 8 bits internally.  As I said ANY peripheral connected to an Xilnx MPSOC via the AXI ports must have at least 16 bits of xID.  

From what little I've played around with the Xilinx AXI wizard, everything I see shows it as having the ID bits parameterized, and correctly sized for the system requirements.

The sizing of the ID widths are a System level parameter - it's value a function of the number of AXI Master devices, and the number of THREAD_IDs within each of those AXI masters.  This system level parameter must be propagated to ALL AXI peripherals on that interconnect.  All AXI peripherals must correct reflect AWID->BID, and ARID->RID of this calculated number of bits.  

Regards,

Mark

 

0 Kudos
fishere
Visitor
Visitor
1,144 Views
Registered: ‎11-27-2019

Hi Mark,


The sizing of the ID widths are a System level parameter - it's value a function of the number of AXI Master devices, and the number of THREAD_IDs within each of those AXI masters.  This system level parameter must be propagated to ALL AXI peripherals on that interconnect.  All AXI peripherals must correct reflect AWID->BID, and ARID->RID of this calculated number of bits.  


Thank you very much.

So our master side ID width (BID and RID) is 2-bits, which would make sense as we have 3 masters. Each of our master's has read/write 'outstanding' transactions set to 2, which I believe forms a queue systems such that if a write is already in progress, a second write command is held in a suitable queue to be sent after the first has finished.

On the slave side, all slaves have an ID width of 4-bits, which makes sense as we have 14 slave end-points. When I change the master side ID width to 3 bits, slave side ID is automatically updated to 5, and changing master side to 4 bits, the slave side ID automatically increases to 6 bits. This would suggest to me some calculation such as max( (master_width + write_queue_depth) or (slave_id_width) ).

The issue here is that if say (master_width + write_queue_depth) = 2+2 = 4 is a perfectly valid ID width calculation, as performed in the Xilinx IP generation scripts, how do we remove synthesis warnings regarding 'unconnected' bid[2] and bid[3]. They are connected at the IP cores top level, but the warning is with respect to the couplers (which are fully parameterised blocks within the AXI IP), which can't be manually connected.

I suppose, I could reduce the "outstanding read/write transaction" depths to 0, but the queue system I'd have thought would be beneficial, for AXI traffic management.

Many thanks all,

Ed

0 Kudos
markcurry
Scholar
Scholar
1,121 Views
Registered: ‎09-16-2009

If you have 4 AXI Master ports, each with THREAD_ID_WIDTH=2, then your system ID_WIDTH will need to be 4 bits.  (3 * (2**THREAD_ID_WIDTH))=12.  clog2( 12 ) = 4.

For each AXI Master, the threads are completely independent.  So each master can send out 4 threads to the AXI bus.  The AXI protocol allows the interconnect to process these in any order.

The AXI Slave buses at each slave must be 4 bits, because of the calculation above - it doesn't have anything to do with the number of slaves being 14.  The number of slaves doesn't enter into the calculations for ID_WIDTHS at all.

Now, I've said the entire system ID_WIDTH should be 4 in your system.  However, the local connections between just your AXI masters and the axi_interconnect could be truncated to just the two bit THREAD_ID_WIDTH that those masters drive. The axi_interconnect itself takes care of truncating the top bits back to the master.  There's more than one way to do this, and I'm not sure how the Xilinx AXI wizard handles things.  The simpler solution, IMHO is to just define the entire system ID_WIDTH to 4 and make things easier (let synthesis optimize away any constant nets).  However, the Xilinx AXI Wizard may actually truncate those primary Master ID connections.  I'm not sure.

Regards,

Mark

0 Kudos
fishere
Visitor
Visitor
1,025 Views
Registered: ‎11-27-2019

Hi Mark,

Trying a few options with the axi interconnect wizard, it basically always truncates the ID widths between 2-bit on the master side and 4-bit on the slave side.

  • I've tried changing the strategy between custom, minimise area and maximise performance. This was ineffective.
  • I've tried changing the #threads, even down to 0 but the slave side width is again always +2 on the master width.
  • I've also tried manually changing the #outstanding transactions from 2 to 0 and this had no effect

As you say, we can likely ignore this warning, but being a black box it is difficult to justify why it is safe to do so.

Many thanks,

Ed

0 Kudos
fishere
Visitor
Visitor
1,020 Views
Registered: ‎11-27-2019

For future reference, the synthesis warning for the block design is:

- [BD 41-235] Width mismatch when connecting pin: '/axi_interconnect_core/s00_couplers/s00_data_fifo/m_axi_bid'(2) to net 's00_data_fifo_to_s00_couplers_BID'(4) - Only lower order bits will be connected.

0 Kudos
markcurry
Scholar
Scholar
998 Views
Registered: ‎09-16-2009

Ed,

Ok, that's reasonable behavior by the AXI wizard, and the tools.  Here's what's happening.

The AXI Masters only need to drive 2 bits (per their THREAD_ID requirements) on AWID, and ARID.  In response, these masters only expect 2 bit IDS returned on RID, and BID.  However system requirements dictate the 4-bit total AXI ID_WIDTH. This is because the AXI interconnect needs those extra bits in order to route the RID, and BID response back to the correct AXI Master.  The AXI interconnect takes care of all of this for you.  

Each Master drives (only) 2-bit ARID, and AWID.  The AXI Interconnect takes care of assigning the top two bits (uniquely) on each one of these ports.  This total 4-bits is then is what is sent to all slaves.  Which in return to a Write, or Read request, the AXI slaves reflect the 4 bit AWID -> BID (or ARID->RID for reads).  The AXI Interconnect uses the top-two bits to know which AXI Master to send the responses to.  At the perimeter of the AXI Interconnect where the final BID, and RID are returned to the master, the AXI Interconnect removes those extra two bits (since the masters aren't expecting them).  But the RID, and BID ports are still 4 bits.  So it drives those two bits to a zero.  The AXI Masters, needing only 2-bits of ID, ignore (don't even sample) those two high bits of RID, and BID.  Synthesis/back end tools optimize those two extra (constant value) bits away.  The warning is generated.

Regards,

Mark

View solution in original post

0 Kudos
fishere
Visitor
Visitor
989 Views
Registered: ‎11-27-2019

Thank you very much.

I've updated our warning waiver document as this does make sense now that the internals have been a bit better illuminated.

Many thanks.

0 Kudos