Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
902 Views

PCIe Inbound Byte write data corruption ... SolutionID rd04172014_563

This describes the behavior I see ... 

 

solution id: rd04172014_563 

last modified: may 02, 2014 

product category: intellectual property 

product area: comm, interface & peripherals 

product sub-area: core implementation 

version found in: v13.1 update 4 

version fixed in: n/a 

software: quartus ii linux, quartus ii pc 

device family: arria v gt,arria v gx,arria v gz,arria v st,arria v sx,cyclone v gt,cyclone v gx,cyclone v st,cyclone v sx,stratix v gs,stratix v gt,stratix v gx 

ip product: pci express 1/2/4/8 lanes (x8) 

can the 128-bit avalon-mm txs slave interface of the altera hard ip for pci express handle read/write request with byteenable=0x01 ? 

 

 

 

 

 

 

 

 

description 

 

 

 

Due to a problemin theQuartus® II software version 13.1 and earlier, the 128-bit Avalon-MM® Txs slave interface of the Hard IP for PCI Express® cannot generate a correct PCI Express TLPpacket when the ByteEnable = 0x01,0x03, or 0x7 at Avalon-MM interface. 

Avalon-MM bridges operate correctly with a burst count = 1 and the following byte enables (DW Byte Enable) 

16'hF000 16'h0F00 16'h00F0 16'h000F 16'hFF00 16'h0FF0 16'h00FF 16'hFFF0 16'h0FFF 16'hFFFF 

 

 

 

 

 

 

 

workaround / fix 

 

 

 

Use 64bit Avalon-MM Txs slave interface, or set ByteEnable to more than 0x07 (set 4 byte enable or more) with 128-bit Avalon-MM Txs slave interface within Quartus II software version 13.1 and earlier. 

 

This problem is scheduled to be fixed in a future release of the Quartus II software. 

 

I have tried updating fro Quartus 14.0 to 15.0 to 15.0.1 with the issue not getting resolved. 

 

I have some sanity checks ... 

 

1. I am not able to match the above description to a fix in any of the releases of Quartus I have tried ? How to do that ? 

 

2. Could it be that I am updating Quartus but the updates are not making it to my fresh compile ( synthesis ) ... Altera distributor rep says I need to re-generate the QSYS catalog. 

I don't know what this involves ... what I have been doing is archiving the project, un-archiving on a separate PC running the updated Quartus , rerunning QSYS generate and re- 

running the Compile / Synthesis. 

 

3. In the end I am going to have to add SignalTap or run the Simulation to captuer HW or SIM data to present to ALtera. 

 

Below is the Quartus 15.0.1 result on the PCIe analyzer ... notice the Length field is 4 and the Last DW BE and First DW BE indicate one byte operations ... the two DW's in the middle got BE = 0xF. 

 

The code generating the byt ewrite thatfails from NIOS II is below. 

 

Dave any suggestions .. I am 99% there but this is bolding me up ... I absolutely have to be able to perform Inbound byte writes and reads ( did I mention that reads hang the NIOS II execution I think in a bus cycle ). 

 

Thanks Bob 

 

 

ddr_mem_ptr = PCIE_HARD_IP_0_TXS_BASE + 2 ; 

read_value = *ddr_mem_ptr; 

printf("read unaligned ddr_mem_ptr = %p read_value = %x \n", ddr_mem_ptr, read_value); 

if ( read_value != 0x55AA55AA ) 

error++; 

 

 

ddr_mem_ptr = PCIE_HARD_IP_0_TXS_BASE + 3 ; 

read_value = *ddr_mem_ptr; 

printf("read unaligned ddr_mem_ptr = %p read_value = %x \n", ddr_mem_ptr, read_value); 

if ( read_value != 0x55AA55AA ) 

error++; 

 

 

ddr_mem_ptr = PCIE_HARD_IP_0_TXS_BASE + 4 ; 

read_value = *ddr_mem_ptr; 

printf("read unaligned ddr_mem_ptr = %p read_value = %x \n", ddr_mem_ptr, read_value); 

if ( read_value != 0x12345678 ) 

error++; 

 

 

// character mode 

 

ddr_char_mem_ptr = PCIE_HARD_IP_0_TXS_BASE; 

*ddr_char_mem_ptr = 0x65; 

 

 

ddr_char_mem_ptr = PCIE_HARD_IP_0_TXS_BASE + 0x11; 

*ddr_char_mem_ptr = 0x66; 

 

 

 

 

 

 

 

 

 

Tags (2)
0 Kudos
6 Replies
Altera_Forum
Honored Contributor I
32 Views

Can't see anything in the release notes for Quartus 14.0, 14.1 or 15.0 or 15.0.1 that sounds like a fix for  

 

"Due to a problemin theQuartus® II software version 13.1 and earlier, the 128-bit Avalon-MM® Txs slave interface of the Hard IP for PCI Express® cannot generate a correct PCI Express TLPpacket when the ByteEnable = 0x01,0x03, or 0x7 at Avalon-MM interface." 

 

How would I take the SolutionID rd04172014_563 number and corerlate it to the fixes listed in each release notes ?
Altera_Forum
Honored Contributor I
32 Views

I think it would be a user guide update to reflect this, instead of this is going to fix. 

The only byte enable with DW granularity is supported, as below: 

 

16'hF000 , 

16'h0F00 , 

16'h00F0 , 

16'h000F , 

16'hFF00 , 

16'h0FF0 , 

16'h00FF , 

16'hFFF0 , 

16'h0FFF , 

16'hFFFF
Altera_Forum
Honored Contributor I
32 Views

Thanks Skbeh, 

 

I got a reply per the SR I opened and Altera says there will be no Quartus based fix as indicated in the Knowledge Base information. This tells me the problem is in the Hard IP and the IP vendor didn't do a very good verification job. 

 

 

I need to run Imbound byte writes and reads as part of a Cache Line stress test suite where the Host and EP share a Cache Lone but operate on different bytes . 

For Flags and Status bytes , I can expand them to be DWORDS I believe ... 

 

 

I am going to see if I can specify a 64 TXS Avalon MM slave port with Gen3 X 1 configuration as I know 64 bit TXS slave widths don't have the byte granularity issue. 

 

 

 

Thanks, Bob.
Altera_Forum
Honored Contributor I
32 Views

Hi Bob 

 

Ya I agreed with you. 

Use Txs 64-bit is the way to go.
Altera_Forum
Honored Contributor I
32 Views

Thanks Skbeh, 

 

I have modified the design to support Gen3 X1 and 64 bit TXS port. 

 

I am passing Inbound byte write operations , without DWORD corruption at the host now. 

I am passing Inbound byte read operations , without NIOS II hanging. 

 

This is on an emulator that only runs Gen1 rates but with the 128 bit TXS design, we previously failed the byte write / read operations. 

 

I am fairly confident that when trained to Gen3 X1 I will get the same passing results with this design point. 

 

Gen3 X1 may be sufficient for the exerciser I have else I can investigate the 256 bit design point. 

 

Thanks, Bob.
Altera_Forum
Honored Contributor I
32 Views

Bob 

 

Thank you for sharing information. 

We conclude that the Txs 128-bit problem happens for 128-bit bus for both read and write. 

AVMM bridge+HIP can handle the TLP correctly with 64-bits.
Reply