I'm essentially memory mapping the Nor flash to the system PCIe bus, so that the host CPU can read and write the Nor flash via PCIe memory cycles.I used the SOPC builder to create the system (quartus 10.1) The CFI flash is a 16 bit device (intel/numonyx/micron 1 GBit P30 style flash). The JTAG tools can program this flash no problem, Peeks & Pokes using the Nios CPU via JTAG - no problem. The catch is the PCIe path to the flash. When I execute a 16 bit write from the PCIe host, I see the flash get 64 bits of writes. I see four sequential writes of 16 bits each to offset 0,1,2,3 in sequence. The CFI flash requires some specific access patterns to be able to program a location and these unwanted cycles violate those patterns. The PCIe core does pass the correct byte enables through to an internal memory block, so it's the glue between the PCIe core and the Tristate Avalon MM interface used by SOPC builder to attach the flash.. I do have a support call in, but I haven't had much luck with them lately. Anyone seen this, or have a workaround? Looks like I may have to roll my own flash controller that does listen to PCIe byte enables..
Use this (http://alterawiki.com/wiki/modular_pcie_sopc_builder_bridge_example) instead.The default PCIe<=>SoPC Builder bridge has some limitations...that likely won't be addressed in the near future. Cheers, slacker
Actually - Altera support came thru for me. Apparently, even though SOPC builder didn't complain or warn me, I needed to add an "Avalon MM Pipeline Bridge" in between the PCIe core and the Flash/Tristate core.That fixed the problem..