The Stratix 128 bit AVMM I/F to HIP is broken for certain byte enable combinations including byte. Resulting in a malformed TLP.I have a workload in RC host memory that the NIOS II fetches and executes. Is there a way to add a Compile constraint to force all NIOS II references to the data in the RC host memory to be say 4 byte aligned accesses ? Thanks in Advance.
This is the byte issue I refer to ...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)
The software on the other end of the link needs to be changed to never use unaligned addresses for requests for FPGA processing. I.e. never give the FPGA an unaligned address for it's data pointer.
--- Quote Start --- The software on the other end of the link needs to be changed to never use unaligned addresses for requests for FPGA processing. I.e. never give the FPGA an unaligned address for it's data pointer. --- Quote End --- Thanks Galfonz, I will check with SW team but I believe the pointer to the head of the descriptor chain is aligned , but the structures in the chain are random structure lengths and as NIOS processes the workload, the compiler makes some optimizations resulting in byte accesses that result in the malformed TLP ... let me check why the SW team on why can't all the fetches from NIOS of the workload to be aligned and be 4 byte.
Ok I have some more information ... RC memory contains a list of control blocks that are all the same length and reside of 4byte aligned boundaries.... Each control block is made up of a structure where elements of the structure may or may not be used depending on what task the control block specifies. .... It seems the NIOS compiler is making some optimizations on which element of the control block structure are required and optimizing out the complete read. ... This results in byte accesses that the 128 bit HIP interface doesn't support. I'm Ok with any compile optimization, if that is the cause, but would like to be able to specify a non optimization flag at compile time. I have suggested the NIOS II code could defeat the compiler optimization by forcing some dummy read of each control block to a local copy ... this may work. The SW team will again try incase anything has changed and I can trap any non 4 byte Inbound reads on the PCIe analyzer. Thanks, Bob.
It's generally not a good idea to use C structs when defining data structures with strict layout requirements. You can do it by carefully examining the resulting code, using compiler specific directives and adding pad bytes as needed, but this isn't portable. I like to use# defines for offsets and shift values, then macros to pack/unpack data fields. I use these techniques whenever data is shipped to something that uses a different compiler or CPU architecture, or if a specific layout is defined in a requirement or standards document. That's the only way to be sure that the compiler isn't tampering with how you want it.
Thanks Ganfonz,One issue is that the data structures that NIOS II is reading from the host memory are defined in legacy source code that is ported ATM -> NIOS II and everything would be great if the 128 bit HIP didn't crash on byte reads . Since the NIOS II fetches a workload of IO control blocks from the host memory and never writes to the descriptors .... I hacked the RTL to force the TXS port byte enables to always perform atleast 4 byte reads..... Image of RTL below which is fairly simple ... test code indicates byte reads with the expected byte returned and no NIOS II hangs ... exerciser is now up and running and I will move to Stratix V 256 and DMA design to get back byte and two byte support. Still not sure how to add the CRA translation. Thanks, Bob.