External Memory Interface IP on Stratix 10

[Embeddedesigner]

I have a design incorporating the EMIF IP for a Stratix 10 chip (Terasic Apollo S10 dev kit). I generated the design example and simulated it using the Avalon Verification IP Suite and BFM. I’ve read the EMIF Intel Stratix 10 FPGA IP User Guide which mainly focuses on the controller part, not the interface spec. I’m using the Avalon MM protocol to communicate. I have no issues writing one word (Avalon Spec notes that a word transfer is 576 bits wide = 72 x 8), and reading it back. The problem arises when I write a burst of four (or any Burst length). I have to probe the signals with SignalTap II, and I simply bit-bang the code instead of using a FSM since there are so few states. I’m writing four words of data, starting at Address 0, data is in this order, 0x4, 0x1, 0x2, 0x3 (all extended to 576 bits). All byte enables are high, burst count set to 4. I follow the procedure outlined in Section 3.5.5.1 Write Bursts in the Avalon Interface Specifications. I’ve appended the results of the SignalTap II runs for Read and Write, which follow the protocol. I have four signals setup to capture the read data. I have a counter which shows the system evolution and signal transitions. I have a read done signal to let me know when I can stop the simulation and observe the results. I also wait until the controller comes out of reset and is calibrated and have the Reset Release IP instantiated in my code.
I’m only able to read the first data item that is written, 0x4. All four signals are written 0x4.I don’t receive the rest.
There is something very wrong here, I immediately note in the SignalTap results, readdatavalid is high for 20 clock cyles. It should be either high for 4 clock cycles, or 4 disconnected periods (See Figure 15 in the Avalon Interface Specs). My read and write phases are adequately separated to not cause any issues caching a write or read access (causing the waitrequest signal to go high).

According to the Avalon Interface Specifications under Table 9, Avalon Memory Mapped Signal Roles, readdatavalid “For a read burst with burstcount value <n>, the readdatavalid signal must be asserted <n> times, once for each readdata item.” This clearly is not happening here. On every rising clock edge while readdatavalid is high, I’m simply capturing the same data over and over, the first written data, 0x4, nothing else. I can confirm the data was written to memory and can see through another run of SignalTap that 0x3 was returned but after I ran the read and write twice and the 0x3 data was captured while readdatavalid was high for 20 cycles, but again no new data was was shown for remainder while readdatavalid was high. I also setup a run where I count the 20 cycles while readdatavalid is high as one cycle and read the data, and again, all I get back is 0x4. I've also discovered that readdatavalid appears to go high for 1 cycle prior to the 20 cycles high and again same data on every clock edge.

My questions are this.

1. I am not understanding what is going on here, why am I seeing readdatavalid is high for 20 clock cycles when it should be 4? There is also a glitch, causing readdatahigh to go high for 1 cycle prior to the 20 cycle high period. 

2. Why am I capturing the same data while readdatavalid is high? I should be getting new data on every rising edge of the clock which readdatavalid is high?

3. Do I have to worry about address alignment, does it matter if I start at address 0?

3. The Avalon Specifications notes that legal values for readdata is 2, 4, 8....512, 1024. But in the EMIF IP it is 576 bits (72*8), why is this not listed in the specs ?

4. Why is response[1:0] not included in the EMIF IP for verification purposes?

[Embeddedesigner]

Can someone please assist with a proposed solution and inquire into what the problem is?

[Embeddedesigner · Accepted solution]

I solved the problem:

the waitrequest signal is active low. I was triggering my logic on active high.
this isn’t immediately relevant from reading the Avalon spec but mere oversight by not seeing the signal in the IP block diagram. 

[WeiHanT_Intel]

Dear @Embeddedesigner, 

We are observing long holiday, please expect slow in response, sorry for any inconvenience this may cause. The AE will attend to you after 19-Feb'24. 

Thanks for contact through Intel Community Forum. 

[AdzimZM_Intel]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.