cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
661 Views
Registered: ‎10-30-2019

Axi4-lite slave wrong AWADDR transfer

Jump to solution

Hello,

I have an issue with my custom slave axi4-lite interface connected to the Axi-interconnect IP v2.1 rev 16 and Vivado 2017.4.

The target should receive AWADDR 004 to write the slv_reg_control but sometimes receives the address 000 from the Master (Axi Interconnect IP) and write data to the slv_reg_config.

I can see the issue with ILA connected between the Interconnect and the slave. When I connect ILA  between the Zync-ps and the InterConnect the issue disappear Below are the ILA waveforms: KO then OK

Transfert KOTransfert KO

OK.png

My VHDL design axi_slave is based Vivado template and it looks this bug: https://forums.xilinx.com/t5/Processor-System-Design-and-AXI/AXI4-lite-Write-Channel-starts-the-next-transaction-before-the/td-p/1083186

The issue occurs around 1 time by 20 transfers. WNS is ok (Clk 200Mhz).

Do someone can confirm me it is that bug? Is there a VHDL Xilinx patch? (I cannot regenerate the project to a newer Vivado version).

Thanks by advance.

Alexandre
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
383 Views
Registered: ‎05-21-2015

@AlexMen2211 ,

Woah, back up ... you have a combinatorial mux on the AW channel, and you are using to select from among AXI-lite slaves?  That's going to violate protocol in many different ways.

  1. Once AWVALID && AWREADY, AWADDR is no longer reliable.  If you allow WVALID & WREADY on any cycle where !AWVALID (the protocol allows this), then you might end up sending these signals to the wrong slave.
  2. How will you know which BVALID to return?  By the time you set BVALID, AWVALID may no longer be properly set.
  3. What happens if one request is accepted by one slave, then another by the next, before the first returns BVALID?

In general, the solution you need/want is either not AXI-lite on the downstream end, or two ports off of an AXI interconnect.  You could even use an AXI-lite interconnect for this.  To see what's required, consider this AXI-lite interconnect.

The other way to handle this, if you wanted something simpler, would  be to allow only one burst downstream at a time in the "AWVALID MSB" component, to allow nothing downstream until both AWVALID && WVALID were aligned, and to disallow anything more until BVALID were returned.  I've done this often, but rarely with the full AXI-lite protocol.  I tend to use bus simplifiers instead when I just want something light weight.

Dan

View solution in original post

12 Replies
Highlighted
Scholar
Scholar
628 Views
Registered: ‎05-21-2015

@AlexMen2211 ,

The signals from the master in that transaction don't look right.  AWVALID should never drop until both AWVALID && AWREADY.  The same applies to WVALID.  I'd check to see if there are bugs in your AXI master therefore.

Also, if you'd like me to run a quick formal check on your updated/fixed slave design, feel free to share it.  It might help by eliminating one of the possible places to look for a bug.

Dan

Highlighted
Visitor
Visitor
566 Views
Registered: ‎10-30-2019

@dgisselq wrote:

The signals from the master in that transaction don't look right.  AWVALID should never drop until both AWVALID && AWREADY.  The same applies to WVALID.  I'd check to see if there are bugs in your AXI master therefore.


Hello Dan, thank you for you quick reply.

I am agree with you, the master don't assert the *WValid signal correctly. But I assume it was because of the slave response. Maybe the slave miss the previous transaction, and generate Master or Interconnect bug ? I can't see the full transaction as most of the BRAM are used for the design and no more available for ILA. I try to trig on last valid transfer before the bug, I will share you the trace Monday when I will be back to the office. 


I forgot to mention the master is a closed source IP containing the Zynq-PS. Interconnect is connected between Zynq-PS HP0 link and that IP. So I can't investigate the master as I cannot reproduce the bug with ILA on Zynq-PS HP0 link. This lead me to also suspect a CDC instability as Interconnect handle two clock-domains (Zynq-PS@200MHz and Slave@90MHz).


@dgisselq wrote:

Also, if you'd like me to run a quick formal check on your updated/fixed slave design, feel free to share it.  It might help by eliminating one of the possible places to look for a bug.

Dan


About the slave sources they are basically the same than Vivado axi4-lite template except (last but not least) the axi-bus is multiplexed by the AWADDR MSB, either master will drive slv_reg or an axi_sram module.

Thanks again for your help. I will continue to read your axi-bus articles.

Alexandre
0 Kudos
Highlighted
Observer
Observer
545 Views
Registered: ‎11-21-2020

If it's a bug, it would be a bug of axi_interconnect as, if I understand well, *WVALID comes from the interconnect and the latest official AXI specification is quite clear that it shouldn't be deasserted until *WREADY is asserted. But axi_interconnect is still in v2.1 in Vivado 2020.1 implying no bug has been found since 2017.4.

Why do you claim there is a bug? On your slave-interconnect link, nothing tells us that the transaction on the W channel is linked to the transaction on the AW channel occuring at the same time (where you put your cursor). On the timing diagram , we can see there was the desired 0x040 address but we can't see whether the corresponding AWVALID/READY transaction already occured.

The AXI specification is quite clear about the order in which AW/W/B/AR/R transactions have to occur. On your 'KO' timing diagram I see an AW transaction @ address 0x000 and and a W transaction with the data for address 0x040. But nothing tells us that they belong to each other and that there is a bug.

What's going on on the other side of the interconnect is fully irrelevant. The ZYNC-PS may have decided to present AW and W transactions at the same time but 1) it is not our concern, and 2) it doesn't imply it will be the same on th interconnect-slave side. On the contrary, for a burst transaction, the AW/AR rd/wr operations are made of a single cycle (incl. address, width, length, ...) and the corresponding buffering in the interconnect is quite thin, while the W/R transactions are made of several cycles and the correspondng buffering is much deeper (so that it can store the complete burst if needed). It would have the consequences to shift AW wrt to W transactions.

Highlighted
Observer
Observer
466 Views
Registered: ‎11-21-2020

@alexandre.mendy@elsys-design.com

Would it be possible to see the block diagram of the interconnect part as well as ACLK/ARESETN signals on the timing diagram (a wider time range would also be nice). I'm confused with your comment about the various 90/200MHz clock domains as axi_interconnect do handle it properly.

It is also unclear to me what you mean by the axi-bus is multiplexed by the AWADDR MSB. I guess in the slave itself which would require careful handling of the situation as you have 5 AW/W/B/AR/R rather independent channels. In the slave many situations can lead to a desynchronization between the AXI channels (software-controlled slave reset, internal axi sharing, ...).

0 Kudos
Highlighted
Visitor
Visitor
437 Views
Registered: ‎10-30-2019

@EajksEajks wrote:

If it's a bug, it would be a bug of axi_interconnect as, if I understand well, *WVALID comes from the interconnect and the latest official AXI specification is quite clear that it shouldn't be deasserted until *WREADY is asserted. But axi_interconnect is still in v2.1 in Vivado 2020.1 implying no bug has been found since 2017.4.


Xilinx doesn't increase version on minor bug, they increase only revision and we are now to revsion 20 so I don't use the last revision. Vivado IP Versioning here: https://www.xilinx.com/products/intellectual-property/vivado-ip-versioning.html


Why do you claim there is a bug?

From software PS view point it's a bug as the wrong address is write.


@EajksEajks wrote:

The AXI specification is quite clear about the order in which AW/W/B/AR/R transactions have to occur. On your 'KO' timing diagram I see an AW transaction @ address 0x000 and and a W transaction with the data for address 0x040. But nothing tells us that they belong to each other and that there is a bug


That's a good point(address x004 is the slv_reg_spi_control), It looks (with KO tranfer) the address-x004 and WData-x04100a21 are rightly assert but not write with the WData-x04100a21 in the slv_reg_spi_control. So it looks the problem is from the previous transaction. But until now I failled to trig with confidence on the previous transfer, but I will do it.


What's going on on the other side of the interconnect is fully irrelevant. The ZYNC-PS may have decided to present AW and W transactions at the same time but 1) it is not our concern, and 2) it doesn't imply it will be the same on th interconnect-slave side.

I wouldn't be so confident, to observe the master side I/O would allow us to have some certitude about the interconnect behaviour.

Thanks, I will share you block-design this monday.

Alexandre
0 Kudos
Highlighted
Visitor
Visitor
428 Views
Registered: ‎10-30-2019

@EajksEajks wrote:

It is also unclear to me what you mean by the axi-bus is multiplexed by the AWADDR MSB. I guess in the slave itself which would require careful handling of the situation as you have 5 AW/W/B/AR/R rather independent channels. In the slave many situations can lead to a desynchronization between the AXI channels (software-controlled slave reset, internal axi sharing, ...).


Here is a schematic of axi module architecture (mux is combinational, may be I will try to make it sequential and check if the bug still appear):

AxiModule.png

Alexandre
0 Kudos
Highlighted
Scholar
Scholar
422 Views
Registered: ‎08-01-2012

@AlexMen2211 

I would say this is a pretty normal thing to do (I have VHDL functions for doing just this) and it works just fine. But you have to remember to mask of the MSBs used for muxing and disable the valids to the unused slaves.

Given how widely used the Xilinx infrastructure is, I would suspect a bug in your custom master or slave first. While the Xilinx code does have bugs (as @dgisselq will confirm) its in more corner cases, and the posted use case is pretty nomal and you already admitted to a bug in your own slave.

@EajksEajks 

There is no ordering requirement in AXI4 other than a response arrives after a complete write (Addr + data). You are allowed to send the WDATA before the AWADDR, and it is the job of the slave to accept them or not. But through an interconnect these must be re-synchronised.

Highlighted
Observer
Observer
384 Views
Registered: ‎11-21-2020
@richardhead There is a lot of dependencies between channels and transactions in AXI except as we both point out between AW and W transactions. There is a full section about it but it sounds like you only focus on AW/W channels.
0 Kudos
Highlighted
Scholar
Scholar
384 Views
Registered: ‎05-21-2015

@AlexMen2211 ,

Woah, back up ... you have a combinatorial mux on the AW channel, and you are using to select from among AXI-lite slaves?  That's going to violate protocol in many different ways.

  1. Once AWVALID && AWREADY, AWADDR is no longer reliable.  If you allow WVALID & WREADY on any cycle where !AWVALID (the protocol allows this), then you might end up sending these signals to the wrong slave.
  2. How will you know which BVALID to return?  By the time you set BVALID, AWVALID may no longer be properly set.
  3. What happens if one request is accepted by one slave, then another by the next, before the first returns BVALID?

In general, the solution you need/want is either not AXI-lite on the downstream end, or two ports off of an AXI interconnect.  You could even use an AXI-lite interconnect for this.  To see what's required, consider this AXI-lite interconnect.

The other way to handle this, if you wanted something simpler, would  be to allow only one burst downstream at a time in the "AWVALID MSB" component, to allow nothing downstream until both AWVALID && WVALID were aligned, and to disallow anything more until BVALID were returned.  I've done this often, but rarely with the full AXI-lite protocol.  I tend to use bus simplifiers instead when I just want something light weight.

Dan

View solution in original post

Highlighted
Observer
Observer
352 Views
Registered: ‎11-21-2020

@alexandre.mendy@elsys-design.com

The block diagram is rather simplistic about how you demultiplex transactions between your control register and your RAM memory. Hopefully you take account that you have 5 concurrent channels, AW/W/B/AR/R, you have to track when demultiplexing AW/W/AR and multiplexing B/R. The interconnect expect a proper ordering between all channels  - the now famous section A3.3 of the AXI specification. If for instance, you receive the write data before the write address as it was already pointed out, how do you demux the transaction?

0 Kudos
Highlighted
Observer
Observer
339 Views
Registered: ‎11-21-2020
You have to remember the overall order of write and read transactions both when receiving the requests and sending responses back. I rarely (if any) share an AXI interface at the IP level (except for interconnect whose it is the job) ; I prefer to have different AXI interfaces for different traffics as they often tend to have different characteristics and patterns. I also prefer to stick to one interface, one purpose. I find it better to reuse IP accross different systems.
0 Kudos
Highlighted
Visitor
Visitor
140 Views
Registered: ‎10-30-2019

@dgisselq wrote:

Woah, back up ... you have a combinatorial mux on the AW channel, and you are using to select from among AXI-lite slaves?  That's going to violate protocol in many different ways.

  1. Once AWVALID && AWREADY, AWADDR is no longer reliable.  If you allow WVALID & WREADY on any cycle where !AWVALID (the protocol allows this), then you might end up sending these signals to the wrong slave.
  2. How will you know which BVALID to return?  By the time you set BVALID, AWVALID may no longer be properly set.
  3. What happens if one request is accepted by one slave, then another by the next, before the first returns BVALID?

In general, the solution you need/want is either not AXI-lite on the downstream end, or two ports off of an AXI interconnect.  You could even use an AXI-lite interconnect for this.  To see what's required, consider this AXI-lite interconnect.

The other way to handle this, if you wanted something simpler, would  be to allow only one burst downstream at a time in the "AWVALID MSB" component, to allow nothing downstream until both AWVALID && WVALID were aligned, and to disallow anything more until BVALID were returned.  I've done this often, but rarely with the full AXI-lite protocol.  I tend to use bus simplifiers instead when I just want something light weight.

Dan


You are right the design is not clean, I think the point 2 you mention generate de bug. In fact the designer made assumptions on certain cases which should not happen to simplify the design. There is still others non-compliance with the axi-specification on Ram module.

So my initial question was to know if the address error was relate to the knowing bug you detailed on Zipcpu, but it is definitly not.

I will first clean the ram_module and try your solution to allow only one burst downstream at a time in the "AWVALID MSB" component. You help me a lot to analyse the fault.

Thank you all.

Regards

Alexandre
0 Kudos