pcix core master dma

[Matthias Müller]

Hello,
I have a problem with peforming master dma with the xilinx pcix core.
I'm writing into the systemy memory with 4KB blocks and I use a
4KB-BlockRAM in the FPGA as prefetchable datasource. The
BlockRAMs have a read latency of one clock cycle. If I increment the
internal source-address-counter with m_data_nxt, then the first piece of

data comes out one cycle to late. The Design Guide says that the first
piece of data must be presented to the core with assertion of m_attr_vld

and the subsequent pieces with m_data_nxt. I thought that this mechanism

can compensate the read latency of the BlockRAMs. But it looks like the
first piece of data is NOT sampled with assertion of m_attr_vld. Who
knows about
the problem, when is the first piece of data samlped?
greetings,
Matthias

 

[Michael Rhotert]

"Matthias Müller" <spam*mur@iis.fhg.de> wrote

Hello,
I have a problem with peforming master dma with the xilinx pcix core.
I'm writing into the systemy memory with 4KB blocks and I use a
4KB-BlockRAM in the FPGA as prefetchable datasource. The
BlockRAMs have a read latency of one clock cycle. If I increment the
internal source-address-counter with m_data_nxt, then the first piece of

data comes out one cycle to late. The Design Guide says that the first
piece of data must be presented to the core with assertion of m_attr_vld

and the subsequent pieces with m_data_nxt. I thought that this mechanism

can compensate the read latency of the BlockRAMs. But it looks like the
first piece of data is NOT sampled with assertion of m_attr_vld. Who
knows about
the problem, when is the first piece of data samlped?
greetings,
Matthias

Hello,

when m_attr_vld is asserted, you have to provide the transfer attributes on
the M_DATA_IN bus. In the same cycle, read the first piece of data into the
output register of the BlockRAM and increment your address pointer. The
first piece of data is sampled by the core at the first occurence of
M_DATA_NXT. Use this event to transfer the second piece of data to the
BlockRAM register and increment your address pointer...

Hope this helps,
Michael

 

[Eric Crabill]

Hi,

Michael already answered the question, but I thought I'd
follow up anyway.

If I increment the internal source-address-counter with
m_data_nxt, then the first piece of data comes out one
cycle to late. The Design Guide says that the first
piece of data must be presented to the core with
assertion of m_attr_vld and the subsequent pieces
with m_data_nxt.

That is correct.

I thought that this mechanism can compensate the read
latency of the BlockRAMs.

It works with the BlockRAMS. The m_data_nxt signal is
telling your use application, "You need to provide the
next piece of data during the next clock cycle."

So, you could use m_data_nxt to control the BlockRAM,
which has a latency of one cycle -- and it will work
properly.

But it looks like the first piece of data is NOT
sampled with assertion of m_attr_vld. Who knows about
the problem, when is the first piece of data samlped?

You either need to arrange your design so that the
first piece of data is always available when the
transfer starts (data ready, sitting at BlockRAM
output) or you need to "prefetch" the first piece
using your own m_req as a start flag, or one of the
m_add* signals from the core (which will assert in
response to your assertion of m_req).

You are not told the specific cycle the data is sampled.
You should design to the directions in the design guide.
This way, your design will not break if we ever have to
modify the specific cycle that the data is sampled.

The reason you're not told exactly when is that it varies
depending on what bus mode you're in, and it's a function
of the initiator state machine -- something that is not
"observable" by the user application.

Thanks,
Eric