I am using the MPMC2 to implement a PLB and NPI port config. The PLB port works as expected. However, I am simulating my design and the NPI isn't working as I expect. I have created a small NPI interface that I use to control the write/read requests to the NPI bus. I have read both the user guide and the release notes for the MPMC2 (not enough information provided in my opinion).
I am using a 64-bit memory and wish to do double-word (and word) writes and reads.
When using a double-word write transfer with a 64-bit memory: The write data push must occur a minimum of one cycle after the address acknowledge.
All write data pushes for previous transfers must be completed before asserting the address request.
And from the release notes: When using the NPI, please ensure that all write data is in the write data path FIFOs before the memory requires it. This is particularly important to pay attention to when using 64-bit memories or when the custom NPI PIM has a slower clock than MPMC2_0_Clk0. For safest operation assert MPMC2_PIM__AddrReq after all MPMC2_PIM__WrFIFO_Push's.
So I want to do one 64-bit write to the memory. I present the data, data BE, and RNW to the NPI bus and pulse the FIFO Push signal for one clock cycle. Then the very next clock cycle later I assert the ADDR REQ signal. The next clock cycle the ADD ACK goes high. I lower the ADDR REQ on the next cycle. This is according to the timing diagrams and descriptions in the user guide. For some reason the timing diagram presents the ADDR REQ before the DATA PUSH, but the descriptions say to do the opposite. Anyways, the controller does perform the write correctly to the DDR. I thought that I would see the WrFIFO Empty signal go high (it should have written all the data I put in there). But it stays low...meaning data must be in there.
Now, lets say I execute another write following the first write described above. I do this about 50 clock cycles after the first request. In fact, the controller writes the first data to the DDR before the second request is even made. This second 64-bits of data is not written correctly. It is all 0's. I've dug WAY WAY down into the MPMC2 files in simulation. I am not about to try to figure out everything they are doing. But is does appear that some internal FIFO/ Memory is 128-bits wide. I could understand the FIFO not going empty if it contains an extra 64-bits of 0. And that may explain why the second write is all 0's.
I just can't figure out why the core is behaving like this. All documentation says "BE CAREFUL" when using 64-bit wide memory, but it doesn't explain enough. I thought I was following the recommendations. I am putting data in the FIFO before I request the transfer. And if I try to do word writes (by masking the data pushed into the FIFO with the BE signal) it still doesn't work.
Anyone with experience with this port? Any advice would be great. I saw some posts from a little over a year ago so I am hoping.....