In our Arria 10 design, we have a custom IP block for the Nios data and instruction memory. The underlying memory consists of two 4Kx32 memory blocks, shared with other 64-bit processing elements in the system. The Nios fetches and writes data, but obviously 32 bits at a time. We can successfully write to the memory but have a problem reading from memory.As a test, we can successfully read and write using a Qsys onchip memory component. The primary difference is that the onchip memory component doesn't have the ability toadd wait-states (other than the initial wait-state issued by the adapter). Our IP potentially issues wait-states if there is an arbitration conflict between the various memory read and write ports. Also, fundamentally, there's a LOT more going on within our custom IP block. The problem we see is that read data never actually seems to make its way back to the Nios processor through all the Qsys-generated network logic. Here’s a waveform diagram of what we’ve captured using Signal Tap (a PDF is attached in case that’s easier to read). Fundamentally, we can see that Nios successfully writes to memory (not shown in this diagram) and it appears that it also successfully reads from our custom IP memory block. However, as shown in Step 10 in the Signal Tap waverform, the data never actually appears on the Nios processor read bus! We're at a loss on what to try next. Everything seems to be properly aligned but somehow the data is lost in the Qsys-generated logic before it reaches the Nios processor. Any and all relevant comments and suggestions are strongly welcomed! Family: Arria 10 Nios: Nios II/f Qsys Pro (Beta) 16.0.2 Build 222 Qsys Prime Version 16.0.2 Build 222 07/20/2016 SJ Pro Edition
Just glancing but having been in your shoes,uav_readdatavalid is a qualifier for uav_readdata, so your tag for event (8) should actually be one line above event (9), in which case you'll see they aren't in sync. Your data 00000001h shows up one clock later. With a fixed latency slave, you can tweak the "readLatency" attribute in your _hw.tcl to get them to align. You mentioned inserting wait states, but you didn't include the waitrequest signal in your trace? You probably want your trace to look more like Figure 3-5 from mnl_avalon_spec.pdf, but right now you're looking more like Figure 3-6.
--- Quote Start --- Just glancing but having been in your shoes, ... --- Quote End --- Thanks Ted! The original design included the data valid signal but Qsys indicated that it has been deprecated, so we removed it. The Qsys-generated logic seems to be generally correct but it sounds like we'll go back to providing the data valid signal ourselves.
Hi Ted,Thanks again for the assist. It turns out that our custom component was pulling in an older RAM IP with two-cycle latency. With that remedied, it looks like it's working!!! I'll attach a waveform where Nios is simply reading a location, incrementing the value, writing it back, rinse, lather, repeat.