MPMC2 NPI Help!

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.

>From the User Guide:
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_<Port_Num>_AddrReq after all
MPMC2_PIM_<Port_Num>_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.....

"motty" <mottoblatto@yahoo.com> wrote in message 
news:1193261586.795093.327150@i13g2000prf.googlegroups.com...
>
> 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.....
>

One of the things to watch is memory alignment requirement. I don't remember 
the exact details, it's somewhere in the manual, but you should be safe if 
you align your buffer to 128 bytes I believe.

/Mikhail 

Initially I also had similar problem.

For double-word write transfer with a 64-bit memory the user guide
information is correct:

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.

On Oct 24, 11:33 pm, motty <mottobla...@yahoo.com> wrote:
> 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.
>
> >From the User Guide:
>
> 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_<Port_Num>_AddrReq after all
> MPMC2_PIM_<Port_Num>_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.....

The safest way is to put the data in the NPI FIFO before you put the
address. It is important that all the data is in the FIFO before you
commence the transmission (by putting the address), especially if you
do multiple 64bit transfers at the time.
Be careful about the byte position: 1234 is transferred as 4321

Guru

OK, so the same problem arises from answers here:

Sovan, you are saying that the address request (and subsequent address
ack) goes BEFORE the data push into the FIFO?  Or is the address
request in that statement the one from a previous transfer?

Guru says that the address request should go AFTER pushing data into
the FIFO (or at least this is the safest way).  This is currently what
I am doing, but still having problems.  This doesn't seem like a real
difficult task, but it just isn't working like I expect.

I am using NPI for Double-word and Eight-Word bursts. For Double-word
writes I am requesting address before I push the data. For Eight-Word
writes I am pushing data before address request.

In my case I have one NPI port connected to one RTL block doing Double-
word read/writes and another NPI port is connected to a different RTL
block which does Eight word read/writes. I had to write slightly
different logic for the difference in behavior for different burst
size.

Thanks Sovan,

I am going to try requesting the address before pushing data to see
what happens!

On Oct 25, 6:36 pm, motty <mottobla...@yahoo.com> wrote:
> Thanks Sovan,
>
> I am going to try requesting the address before pushing data to see
> what happens!


Well, I also tried both for Four-Word cacheline writes. First I pushed
the address then data. The NPI consumed the first word, then it
stalled for a couple of cycles, then resumed...
Now I use 64word xfers, pushing 64bit data one at the time, with large
time gaps. When I have pushed all of the 64words (32pushes) I send the
address and the data is transferred.

Guru

Thanks for the help guys.  It appears to work when the AddrReq comes
before the data push.  I guess the IP needs to 'get ready' for one 64-
bit entity using the req.  And it does not work the other way around.
The documentation (release notes) is misleading in the fact that it
basically says that the safest way to do things is to push data then
do the addr req.  They should say next to that 'don't do this with 64-
bit double-word writes though'.  Maybe my reading comprehension needs
adjustment.

"motty" <mottoblatto@yahoo.com> wrote in message 
news:1193402186.653906.267270@19g2000hsx.googlegroups.com...
> Thanks for the help guys.  It appears to work when the AddrReq comes
> before the data push.  I guess the IP needs to 'get ready' for one 64-
> bit entity using the req.  And it does not work the other way around.
> The documentation (release notes) is misleading in the fact that it
> basically says that the safest way to do things is to push data then
> do the addr req.  They should say next to that 'don't do this with 64-
> bit double-word writes though'.  Maybe my reading comprehension needs
> adjustment.


I've just checked my code. I am using 4-word cache-line transfers and I am 
asserting AddrReq after the data has been pushed in, but my memory is 32-bit 
wide...


/Mikhail