UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar samcossais
Scholar
9,110 Views
Registered: ‎12-07-2009

SRIO Gen2 address

Jump to solution

Hi,

 

I am currently testing the SRIO Gen2 Core on a Kintex-7.

In simulation I use a SRIO Gen2 core on both sides and my link seems to work fine.

 

In hardware, the host side of the link is a TI DSP. I checked using ILA debug probe and it seems that the address is converted in the wrong way :

- if I try to access register address[33:0]=0x0000_0000, address[33:0]=0x0_0000_0004 is accessed.

- if I try to access register address[33:0]=0x0000_0004, address[33:0]=0x0_0000_0000 is accessed.

- if I try to access register address[33:0]=0x0000_0134, address[33:0]=0x0_0000_0130 is accessed.

 

In other words, it looks as if addr[2] is inverted.

I know in the SRIO Gen1 core we had to pay attention to the endianness of the user interface, and also to the way the address was formed. In SRIO Gen2 I assumed it was not the case anymore, and I could not find anything about addr[33:0] being converted in some way.

 

Do you have any explanation for why I am experiencing such problem ?

 

Edit: This is SRIO Gen2 v3.1, HELLO mode.

0 Kudos
1 Solution

Accepted Solutions
Scholar samcossais
Scholar
15,514 Views
Registered: ‎12-07-2009

Re: SRIO Gen2 address

Jump to solution

Are you sure that the reason for the inversion of addr[2] is that TI DSP does it incorrectly and it is an issue of the DSP?


 

 

No I don't think it is a bug. According to my Chipscope observations, it seems that the address (for instance 0x0000_0130) is kept like this until the FPGA buffer layer output, then it becomes 0x0000_0134 in the logic layer as it is passed to the user interface. I just expected the HELLO format to be a user friendly format using standard endianness (a bit like AXI4) and byte address but it doesn't look like it is exactly the case.

 

And yes I was able to resolve the issue by inverting the byte endianness within the 64b bus (during the data phase, not for the header of course) and negating addr[2].

 

I don't use non 32b aligned Bytes accesses in my system so I only negated byte_addr[2] for 4Bytes accesses.

I am not even sure it is the right way to solve the problem but it seems to work.

 

TI DSP can be set to reverse the byte endinanness, but it will be done within 32b, not within 64b, so that the upper 32b and lower 32b will need to be swapped anyway.

 

 

0 Kudos
3 Replies
Scholar samcossais
Scholar
9,088 Views
Registered: ‎12-07-2009

Re: SRIO Gen2 address

Jump to solution

Anything about this ?

I really need to make this work asap.

 

What is the bit map for addr[33:0] inside the HELLO packet ?

 

I assumed that being the HELLO format, the address was already converted to a convenient way for the user, so that the xamsb[1:0] defined in RapidIO specs was put on addr[33:32] and addr[2:0] was formed taking into account the byte size and the wdptr.

 

Is it the case or do I have to convert it myself ? I did not find any clear information about that in the SRIO IP docs.

0 Kudos
Visitor tomalek
Visitor
8,917 Views
Registered: ‎07-16-2014

Re: SRIO Gen2 address

Jump to solution

Hi,

 

have you managed to resolve the issue? I am facing the same problem. We have Kintex 7 FPGA with SRIO gen2 connected to TI DSP as well.

 

Are you sure that the reason for the inversion of addr[2] is that TI DSP does it incorrectly and it is an issue of the DSP?

 

I have not found any errata related to this, I also did not find any other forum or discussion dealing with this issue.

 

Thanks of any update on this.

0 Kudos
Scholar samcossais
Scholar
15,515 Views
Registered: ‎12-07-2009

Re: SRIO Gen2 address

Jump to solution

Are you sure that the reason for the inversion of addr[2] is that TI DSP does it incorrectly and it is an issue of the DSP?


 

 

No I don't think it is a bug. According to my Chipscope observations, it seems that the address (for instance 0x0000_0130) is kept like this until the FPGA buffer layer output, then it becomes 0x0000_0134 in the logic layer as it is passed to the user interface. I just expected the HELLO format to be a user friendly format using standard endianness (a bit like AXI4) and byte address but it doesn't look like it is exactly the case.

 

And yes I was able to resolve the issue by inverting the byte endianness within the 64b bus (during the data phase, not for the header of course) and negating addr[2].

 

I don't use non 32b aligned Bytes accesses in my system so I only negated byte_addr[2] for 4Bytes accesses.

I am not even sure it is the right way to solve the problem but it seems to work.

 

TI DSP can be set to reverse the byte endinanness, but it will be done within 32b, not within 64b, so that the upper 32b and lower 32b will need to be swapped anyway.

 

 

0 Kudos