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;
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 ?
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
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.
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.
BobThank 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.