cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,191 Views
Registered: ‎02-12-2020

AXI4-lite Write Channel starts the next transaction before the AXI4-lite Write Response from the previous transaction is received

Jump to solution

 

As soon as I send more than two Xil_Out32 commands to a certain custom IP module the processor is no longer accessible via the debugger. Observing the AXI bus signals via ILA has shown that the BREADY signal is set slightly delayed with the second write command. The third data transfer already starts, which causes a timing problem. Other custom IP modules are also included in the same design. With these the sending of more than two Xil_Out32 commands works without problems. The observation of a working communication has shown that the delays between all write commands are longer than between the write commands in the non-functioning module. Both modules are connected to the same AXI Interconnect.

As far as I understand the AXI4-lite specifications, my custom IP module behaves correctly. The XIL_Out32 command is just a write command to a volatile address. So I don't know where to look for the error and I hope you can help me.

 

#define ADDR XPAR_CONTROLBLOCK_PULSEBLOCK_PULSEAXI_BASEADDR
#define BLUE_PULSE_LENGTH   ((uint32_t)0x0A)
#define RED_PULSE_LENGTH   ((uint32_t)0x0A)
#define PULSE_PERIOD   ((uint32_t)0x31)
#define ENABLE_RED ((uint32_t)1)
#define ENABLE_BLUE ((uint32_t)2)
typedef enum
{
   PWM_MAP_ENABLE = 0x00,
   PWM_RED_PULSE_LENGTH = 0x04,
   PWM_BLUE_PULSE_LENGTH = 0x08,
   PWM_PULSE_PERIOD = 0x0C
} pwmAxiRegiMap_t;


static void configureChopper( void )
{
Xil_Out32( ADDR + PWM_PULSE_PERIOD, PULSE_PERIOD );
Xil_Out32( ADDR + PWM_BLUE_PULSE_LENGTH, BLUE_PULSE_LENGTH );
Xil_Out32( ADDR + PWM_RED_PULSE_LENGTH, RED_PULSE_LENGTH+1 );
Xil_Out32( ADDR + PWM_MAP_ENABLE, ENABLE_RED | ENABLE_BLUE );
}

 

Multiple write commands with problemsMultiple write commands with problems

Multiple write commands with no problemMultiple write commands with no problem

0 Kudos
1 Solution

Accepted Solutions
dgisselq
Scholar
Scholar
1,167 Views
Registered: ‎05-21-2015

daniel.zwygart@ruag.com,

This is a known bug in the custom AXI designs created by the IP packager.  It's also present within some of Xilinx's IP cores as well.

A newer version of Vivado (2018.3+) should be able to create custom AXI logic without this bug in the write channel, although a similar bug will remain in the read channel.  I'm been told that a fix is planned for the 2020.1 Vivado release.  Until then, you might consider using this logic instead.

Dan

View solution in original post

6 Replies
dgisselq
Scholar
Scholar
1,168 Views
Registered: ‎05-21-2015

daniel.zwygart@ruag.com,

This is a known bug in the custom AXI designs created by the IP packager.  It's also present within some of Xilinx's IP cores as well.

A newer version of Vivado (2018.3+) should be able to create custom AXI logic without this bug in the write channel, although a similar bug will remain in the read channel.  I'm been told that a fix is planned for the 2020.1 Vivado release.  Until then, you might consider using this logic instead.

Dan

View solution in original post

necare81
Voyager
Voyager
1,137 Views
Registered: ‎03-31-2016

There is nothing against the AXI spec in either picture.  If you IP is having problems you should fix the custom IP to handle these cases. It is not clear from your post what the problem is.

If you look in these forums you will find some posts about the Xilinx AXI templates having issues with outstanding transactions and suggestions on code changes on how to fix the problem.

You can also try adjusting the settings in the interconnect to allow no outstanding transactions.

0 Kudos
1,112 Views
Registered: ‎02-12-2020
Thank you very much for your help. I used the custom AXI designs created by the IP packager as you expected, and I'm glad that this is a known bug that will be fixed soon. Until then I will use one of your suggested solutions.

Daniel
0 Kudos
dgisselq
Scholar
Scholar
1,110 Views
Registered: ‎05-21-2015

The problem is in the AXI template.

It's triggered by the low BREADY line, and the fact that there's no buffer within template code.  As a result, you'll get traces like the one I generated below:

axil-xilinx-write-fail.png

The fact that this isn't technically an AXI error at this point has thrown tech support off.  When you examine the logic, you'll see that the trace ends in a steady state here--something that's clearly a bug, and will hang any user design as a result.  You can read about other user experiences with these bugs here.

Dan

1,109 Views
Registered: ‎02-12-2020
Thank you for the hit with the setting of the allowed outstanding transactions.

Daniel
0 Kudos
1,104 Views
Registered: ‎02-12-2020

I am surprised that I was only now confronted with this mistake. I have been working with the generated AXI IP templates from Xilinx for several years now and I have never had a problem of this kind before. Even now it's a core of about 20 in the same design and the error only occurred because for unknown reasons the processor sends data to this IP core in shorter intervals than to all other IP cores.

Thanks again for the quick response. My mistake was that I didn't realize that a second write statement is allowed while the first one didn't get the write response yet. So I did not question the implementation of the template.

Daniel

0 Kudos