FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-24-2007, 10:33 PM
motty
Guest
 
Posts: n/a
Default 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.....

Reply With Quote
  #2 (permalink)  
Old 10-24-2007, 10:58 PM
MM
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

"motty" <[email protected]> wrote in message
news:[email protected] oups.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


Reply With Quote
  #3 (permalink)  
Old 10-25-2007, 04:30 AM
sovan
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

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.

Reply With Quote
  #4 (permalink)  
Old 10-25-2007, 11:11 AM
Guru
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

On Oct 24, 11:33 pm, motty <[email protected]> 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

Reply With Quote
  #5 (permalink)  
Old 10-25-2007, 02:58 PM
motty
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

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.

Reply With Quote
  #6 (permalink)  
Old 10-25-2007, 03:30 PM
sovan
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

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.

Reply With Quote
  #7 (permalink)  
Old 10-25-2007, 05:36 PM
motty
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

Thanks Sovan,

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


Reply With Quote
  #8 (permalink)  
Old 10-26-2007, 09:50 AM
Guru
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

On Oct 25, 6:36 pm, motty <[email protected]> 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

Reply With Quote
  #9 (permalink)  
Old 10-26-2007, 01:36 PM
motty
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

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.

Reply With Quote
  #10 (permalink)  
Old 10-26-2007, 05:45 PM
MM
Guest
 
Posts: n/a
Default Re: MPMC2 NPI Help!

"motty" <[email protected]> wrote in message
news:[email protected] ups.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


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
MPMC2 for Virtex-5 when? Antti FPGA 0 02-12-2007 02:04 PM
MPMC2: MPMC2 with DDR2 SDRAM zyan FPGA 17 12-12-2006 11:14 PM
MPMC2 with Virtex-5 Antti Lukats FPGA 0 11-11-2006 02:07 PM
MPMC2 : npi issues #2 ivo FPGA 1 09-18-2006 08:08 PM
MPMC2 : npi issues ivo FPGA 2 08-31-2006 11:19 PM


All times are GMT +1. The time now is 05:11 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved