All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [OPAE] Main Memory Access from FPGA
@ 2019-02-07 15:41 Adler, Michael
  0 siblings, 0 replies; 4+ messages in thread
From: Adler, Michael @ 2019-02-07 15:41 UTC (permalink / raw)
  To: opae

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

The CCI-P interface differentiates between MMIO (memory mapped I/O) and main memory read/write requests. MMIO is an FPGA-side address space, mainly used for implementing FPGA-side CSRs. Those CSRs are exposed in the software’s address space but actually result in PCIe transactions to the FPGA.

CCI-P’s main memory read/write requests are exactly what you are asking for: DMA to host main memory. The primary address space used for those requests is a “physical” I/O address space that maps to host physical addresses. It is also possible to use virtual addresses on the FPGA that correspond to the software’s virtual address space. For that you can use the MPF VTP extension. See section 3 of the tutorial<https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/03_ccip>.

-Michael

From: OPAE <opae-bounces(a)lists.01.org> on behalf of David Nicuesa <david.nicuesa.aranda(a)gmail.com>
Date: Thursday, February 7, 2019 at 9:53 AM
To: "opae(a)lists.01.org" <opae(a)lists.01.org>
Subject: [OPAE] Main Memory Access from FPGA

Hi all,

I'm getting started with the examples, specifically with the hello_world from the intel-fpga-bbb<https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/01_hello_world> repository. Everything works just fine but I was wondering if it is possible for me to access the Main Memory (Not IO) from the FPGA using the CCI protocol.

I have an rtl to sum two vectors, so my idea was to provide the addresses for those two vectors from the software application, allocated in General Purpose Memory. This way, ideally, the FPGA should be able to access those vectors without having a shared buffer (MMIO).

Is it possible to do this, maybe using some MPF extension? In case this is not feasible, I should allocate a shared buffer in MMIO space and then comunicate the vectors through that buffer, right?

Thanks!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4981 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [OPAE] Main Memory Access from FPGA
@ 2019-02-07 16:50 Adler, Michael
  0 siblings, 0 replies; 4+ messages in thread
From: Adler, Michael @ 2019-02-07 16:50 UTC (permalink / raw)
  To: opae

[-- Attachment #1: Type: text/plain, Size: 3128 bytes --]

C0 read and C1 write requests go to main memory buffers pinned with fpgaPrepareBuffer(). The transactions will use whatever physical channels are attached to the FPGA, which might be PCIe. The result is reads/writes from/to main memory.

-Michael

From: David Nicuesa <david.nicuesa.aranda(a)gmail.com>
Date: Thursday, February 7, 2019 at 11:23 AM
To: "Adler, Michael" <michael.adler(a)intel.com>, "opae(a)lists.01.org" <opae(a)lists.01.org>
Subject: Re: [OPAE] Main Memory Access from FPGA

Hello Michael,

thanks for the quick response.

So, correct me if I'm wrong, MMIO goes into the c2 on RTL, and Reads/Writes are managed through c0 and c1, right?
This way I can allocate a buffer through software using  fpgaPrepareBuffer and access that buffer from software as a regular array, and using c0/c1 the AFU is able to work with it and those will be actual main memory accesses, not PCIe transactions.

Thank you very much for the help.

Regards,
David

El jue., 7 feb. 2019 a las 16:41, Adler, Michael (<michael.adler(a)intel.com<mailto:michael.adler(a)intel.com>>) escribió:
The CCI-P interface differentiates between MMIO (memory mapped I/O) and main memory read/write requests. MMIO is an FPGA-side address space, mainly used for implementing FPGA-side CSRs. Those CSRs are exposed in the software’s address space but actually result in PCIe transactions to the FPGA.

CCI-P’s main memory read/write requests are exactly what you are asking for: DMA to host main memory. The primary address space used for those requests is a “physical” I/O address space that maps to host physical addresses. It is also possible to use virtual addresses on the FPGA that correspond to the software’s virtual address space. For that you can use the MPF VTP extension. See section 3 of the tutorial<https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/03_ccip>.

-Michael

From: OPAE <opae-bounces(a)lists.01.org<mailto:opae-bounces(a)lists.01.org>> on behalf of David Nicuesa <david.nicuesa.aranda(a)gmail.com<mailto:david.nicuesa.aranda(a)gmail.com>>
Date: Thursday, February 7, 2019 at 9:53 AM
To: "opae(a)lists.01.org<mailto:opae(a)lists.01.org>" <opae(a)lists.01.org<mailto:opae(a)lists.01.org>>
Subject: [OPAE] Main Memory Access from FPGA

Hi all,

I'm getting started with the examples, specifically with the hello_world from the intel-fpga-bbb<https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/01_hello_world> repository. Everything works just fine but I was wondering if it is possible for me to access the Main Memory (Not IO) from the FPGA using the CCI protocol.

I have an rtl to sum two vectors, so my idea was to provide the addresses for those two vectors from the software application, allocated in General Purpose Memory. This way, ideally, the FPGA should be able to access those vectors without having a shared buffer (MMIO).

Is it possible to do this, maybe using some MPF extension? In case this is not feasible, I should allocate a shared buffer in MMIO space and then comunicate the vectors through that buffer, right?

Thanks!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 9442 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [OPAE] Main Memory Access from FPGA
@ 2019-02-07 16:22 David Nicuesa
  0 siblings, 0 replies; 4+ messages in thread
From: David Nicuesa @ 2019-02-07 16:22 UTC (permalink / raw)
  To: opae

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

Hello Michael,

thanks for the quick response.

So, correct me if I'm wrong, MMIO goes into the c2 on RTL, and Reads/Writes
are managed through c0 and c1, right?
This way I can allocate a buffer through software using  fpgaPrepareBuffer and
access that buffer from software as a regular array, and using c0/c1 the
AFU is able to work with it and those will be actual main memory accesses,
not PCIe transactions.

Thank you very much for the help.

Regards,
David

El jue., 7 feb. 2019 a las 16:41, Adler, Michael (<michael.adler(a)intel.com>)
escribió:

> The CCI-P interface differentiates between MMIO (memory mapped I/O) and
> main memory read/write requests. MMIO is an FPGA-side address space, mainly
> used for implementing FPGA-side CSRs. Those CSRs are exposed in the
> software’s address space but actually result in PCIe transactions to the
> FPGA.
>
>
>
> CCI-P’s main memory read/write requests are exactly what you are asking
> for: DMA to host main memory. The primary address space used for those
> requests is a “physical” I/O address space that maps to host physical
> addresses. It is also possible to use virtual addresses on the FPGA that
> correspond to the software’s virtual address space. For that you can use
> the MPF VTP extension. See section 3 of the tutorial
> <https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/03_ccip>
> .
>
>
>
> -Michael
>
>
>
> *From: *OPAE <opae-bounces(a)lists.01.org> on behalf of David Nicuesa <
> david.nicuesa.aranda(a)gmail.com>
> *Date: *Thursday, February 7, 2019 at 9:53 AM
> *To: *"opae(a)lists.01.org" <opae(a)lists.01.org>
> *Subject: *[OPAE] Main Memory Access from FPGA
>
>
>
> Hi all,
>
>
>
> I'm getting started with the examples, specifically with the hello_world
> from the intel-fpga-bbb
> <https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/01_hello_world> repository.
> Everything works just fine but I was wondering if it is possible for me to
> access the Main Memory (Not IO) from the FPGA using the CCI protocol.
>
>
>
> I have an rtl to sum two vectors, so my idea was to provide the addresses
> for those two vectors from the software application, allocated in General
> Purpose Memory. This way, ideally, the FPGA should be able to access those
> vectors without having a shared buffer (MMIO).
>
>
>
> Is it possible to do this, maybe using some MPF extension? In case this is
> not feasible, I should allocate a shared buffer in MMIO space and then
> comunicate the vectors through that buffer, right?
>
>
>
> Thanks!
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5320 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [OPAE] Main Memory Access from FPGA
@ 2019-02-07 14:53 David Nicuesa
  0 siblings, 0 replies; 4+ messages in thread
From: David Nicuesa @ 2019-02-07 14:53 UTC (permalink / raw)
  To: opae

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

Hi all,

I'm getting started with the examples, specifically with the hello_world
from the intel-fpga-bbb
<https://github.com/OPAE/intel-fpga-bbb/tree/master/samples/tutorial/01_hello_world>
repository.
Everything works just fine but I was wondering if it is possible for me to
access the Main Memory (Not IO) from the FPGA using the CCI protocol.

I have an rtl to sum two vectors, so my idea was to provide the addresses
for those two vectors from the software application, allocated in General
Purpose Memory. This way, ideally, the FPGA should be able to access those
vectors without having a shared buffer (MMIO).

Is it possible to do this, maybe using some MPF extension? In case this is
not feasible, I should allocate a shared buffer in MMIO space and then
comunicate the vectors through that buffer, right?

Thanks!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-02-07 16:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-07 15:41 [OPAE] Main Memory Access from FPGA Adler, Michael
  -- strict thread matches above, loose matches on Subject: below --
2019-02-07 16:50 Adler, Michael
2019-02-07 16:22 David Nicuesa
2019-02-07 14:53 David Nicuesa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.