Forum Discussion
Altera_Forum
Honored Contributor
11 years agoMore ... I now have PCI_ORDER_PARK as below ... works fine prior to running NIOS II code ... after running NIOS II code , somehow I suspect the Avalon MM interconnect state changes and I get a the write data returned
from the constant IMEM location 0x10100 after the 8th PCIe write ( see error report image which is confirmed by the PCIe logic analyzer data probing the Gen1 X1 link ) The clue here may be that the write data is offset by 8 and I am wondering if the Avalon MM interconnect has an 8 deep FIFO somewhere ...I have seen it mentioned somewhere. How to fix : 1. reverse engineer the Avalon MM interconnect to see how the reads can pass writes for the BAR1 PCIe Hard IP Avalon MM master. 2. add SignalTap to the BAR1 Avalon MM master port to see what is happening. 3. investigate Hard IP to see if the BAR1 Avalon MM master port has the wrong settings. 4. try to determine why this failure only occurs after running NIOS II ... I will try just a "Hello from NIOS" message . I also see this on Cyclone , but it is worse I believe and the Cyclone is running NIOS out of the SSRAM on board. 5. investigate if the IMEM i'm using as a mailbod between NIOS and the Host ( RC ) needs to be dual ported. case PCI_ORDER_PARK: // test mailbox memory // write and immediate single location wr_addr = 0x10100; rd_addr = 0x10100; wr_data = 0x100; for ( i= 0; i < 0x100; i++ ) { __write( bar1_sav, wr_addr, wr_data ); rd_data = __read( bar1_sav, rd_addr); if ( rd_data != wr_data ) { printk ( "pci order test error: addr = %x, rd_data = %x, expected %x \n" , rd_addr, rd_data, wr_data ); } wr_data++; } printk ( "pci order park test done \n"); break;