cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
1,885 Views
Registered: ‎04-09-2015

SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

Hello everyone,

 

Hardware: KCU116 Eval Board

 

Block Design:

     +-------+                             +------------+
     |       |  slot_1 : axi_cdma_0_M_AXI  |            |
     |       <----------------------------->            |
     | CDMA  |                             |            |
     |       |          M_AXI_SG           |Interconnect|
     |       <----------------------------->            |
     +-------+                             |            <-------+
                                    +------+            |       |
                                    |      +------------+       |
                                    |                           |
slot_0 : axi_interconnect_0_M00_AXI |                           | slot_2 : xdma_0_M_AXI_B
                                    |     +---------------+     |
                                    +----->               +-----+
                                          |     XDMA      |
                                          +- Bridge Mode -+
                                          |               |
                                          |               |
                                          +---------------+

 

Screenshot of Transfer from CDMA to XDMA:

Unbenannt.png

 

Question:

I can't figure out, why the XDMA slave interface throws the "SLVERR" (at the end within the B/Response channel).

Is there anything I am missing?

Does the AXI transfer from the CDMA to XDMA seem incorrect to anybody?

 

Any help will be appreciated!

 

EDIT:

Forgot to mention:

AXI2PCIEBAR0 has base-address of 0x100000000 and high-address of 0x1FFFFFFFF, so the AWADDR is within a valid address range.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
2,208 Views
Registered: ‎12-10-2013

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

Hi @steffen.kern,


We have identified an issue with 64-bit address propagation in 2017.4 with IPI.  This has been confirmed fixed in 2018.1.  For now, I would recommend rolling back to the 2017.3 environment.  Since this is part of the IPI environment, just rolling back the IP doesn't work. 

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
1,859 Views
Registered: ‎12-10-2013

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

Hi -

 

Are you using IPI and Vivado 2017.4?

 

Can you try taking the S_AXI BAR(s) down into the 32-bit address range as a test?

 

Sincerely,

Beth

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Contributor
Contributor
1,805 Views
Registered: ‎04-09-2015

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

Jep, I'll give it a try and get back to you.

 

EDIT:

Ah, yeah, IPI and 2017.4. Sorry forgot to mention that...

0 Kudos
Highlighted
Contributor
Contributor
1,782 Views
Registered: ‎04-09-2015

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

@bethe

Just finished the first tests and it seems like your assumption is right.

 

Moving the AXIBAR into the 32Bit address range seems to solve the problem.

 

Is this expected behaviour?

0 Kudos
Contributor
Contributor
1,751 Views
Registered: ‎04-09-2015

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

If this is expected behaviour this puts design critical restrictions onto the AXIBAR placements (and every other HDL component with an AXI interface) within the AXI address space that are not documented within the user guides. This should be added!

 

Follow-up questions:

If this is a bug, will this be fixed?

If this is a feature, will it be improved to allow 64bit address ranges above the 4GB mark to be translated correctly onto a 32bit PCIe bus?

 

+ Will this apply to the PCIe2AXI direction as well?

Because currently you need to activate 64Bit PCIe-BARs in order to be able to translate onto a 64Bit AXI address space (as seen in screenshot) which furthermore unnecessarily pulls away 3 of the 6 PCIe-BARs in case only the 32Bit PCIe bus is used.

Unbenannt.PNG

If a design only needs a 32Bit PCIe bus (maybe from CPU restriction or just merely per design choice) but due to the amount of AXI components has a requirement for 64Bit AXI address space that is sth. which should be documented!

 

Appreciate your feedback.

 

EDIT:

Added PCIE2AXI question.

0 Kudos
Highlighted
Contributor
Contributor
1,697 Views
Registered: ‎04-09-2015

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

bump!

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,209 Views
Registered: ‎12-10-2013

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution

Hi @steffen.kern,


We have identified an issue with 64-bit address propagation in 2017.4 with IPI.  This has been confirmed fixed in 2018.1.  For now, I would recommend rolling back to the 2017.3 environment.  Since this is part of the IPI environment, just rolling back the IP doesn't work. 

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Highlighted
Contributor
Contributor
1,566 Views
Registered: ‎04-09-2015

Re: SLVERR from XDMA after write transaction to S_AXI interface

Jump to solution
@bethe
Thanks for the info!
0 Kudos