Deployment to Ettus E310 - xdc and containers

RJ
roland.johnson@paconsulting.com
Thu, Oct 26, 2023 10:24 AM

Hi all,

I’m looking to deploy some test apps onto the Ettus E310 – I’m not fussed whether it’s in Standalone mode or Server mode, I just want to understand the OCPI build process for deployed projects.

Looking at tutorial 10 of the official OCPI tutorials ( https://opencpi.gitlab.io/releases/v2.4.6/ )whereby the FSK app is prepared for the PlutoSDR, it looks like there’s an xdc constraints file for the Zynq SoC that one needs to copy from the “fsk_modem” application.

As the IOs are preconfigured for the Ettus, could this .xdc conceivably be used for all deployed projects? And if that were the case, I suppose (even though there would be a lot of overhead and be massive overkill for most applications), it would be possible to use the same container, so long as one only needed to use common peripherals in their projects like the ADC/DAC, and not something specific like DDR interfacing?

Best,
Roland

Hi all, I’m looking to deploy some test apps onto the Ettus E310 – I’m not fussed whether it’s in Standalone mode or Server mode, I just want to understand the OCPI build process for deployed projects. Looking at tutorial 10 of the official OCPI tutorials ( https://opencpi.gitlab.io/releases/v2.4.6/ )whereby the FSK app is prepared for the PlutoSDR, it looks like there’s an xdc constraints file for the Zynq SoC that one needs to copy from the “fsk_modem” application. As the IOs are preconfigured for the Ettus, could this .xdc conceivably be used for all deployed projects? And if that were the case, I suppose (even though there would be a lot of overhead and be massive overkill for most applications), it would be possible to use the same container, so long as one only needed to use common peripherals in their projects like the ADC/DAC, and not something specific like DDR interfacing? Best,\ Roland
AO
Aaron Olivarez
Tue, Oct 31, 2023 4:41 AM

Hi Roland,

The idea *is *to utilize the same constraints and container as much as
possible. These common constraints and containers are typically stored in
the platform worker directory and often are symbolic linked in the assembly
when needed. A modern way of organizing them is currently illustrated in
the develop version of the PlutoSDR platform,
https://gitlab.com/opencpi/osp/ocpi.osp.plutosdr/-/tree/develop/hdl/assemblies/include?ref_type=heads
. Inside the assembly directory you will find an include directory that
contains the various ways you can use that platform and its devices in this
case the ADC and DAC.

Taking one of those files in the PlutoSDR assembly directory as an example
and expanding its name: cnt_adc2assy2ic_ic2assy2dac.xml

cnt=container
adc=analog to digital converter
assy= hdl assembly
ic=interconnect
dac=digital to analog converter

analog to digital converter -> hdl assembly -> interconnect (AXI FPGA)
interconnect (AXI FPGA)  -> hdl assembly -> digital to analog converter.

Aaron

On Thu, Oct 26, 2023 at 5:24 AM roland.johnson--- via discuss <
discuss@lists.opencpi.org> wrote:

Hi all,

I’m looking to deploy some test apps onto the Ettus E310 – I’m not fussed
whether it’s in Standalone mode or Server mode, I just want to understand
the OCPI build process for deployed projects.

Looking at tutorial 10 of the official OCPI tutorials (
https://opencpi.gitlab.io/releases/v2.4.6/ )whereby the FSK app is
prepared for the PlutoSDR, it looks like there’s an xdc constraints file
for the Zynq SoC that one needs to copy from the “fsk_modem” application.

As the IOs are preconfigured for the Ettus, could this .xdc conceivably be
used for all deployed projects? And if that were the case, I suppose (even
though there would be a lot of overhead and be massive overkill for most
applications), it would be possible to use the same container, so long as
one only needed to use common peripherals in their projects like the
ADC/DAC, and not something specific like DDR interfacing?

Best,
Roland


discuss mailing list -- discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.org

Hi Roland, The idea *is *to utilize the same constraints and container as much as possible. These common constraints and containers are typically stored in the platform worker directory and often are symbolic linked in the assembly when needed. A modern way of organizing them is currently illustrated in the develop version of the PlutoSDR platform, https://gitlab.com/opencpi/osp/ocpi.osp.plutosdr/-/tree/develop/hdl/assemblies/include?ref_type=heads . Inside the assembly directory you will find an include directory that contains the various ways you can use that platform and its devices in this case the ADC and DAC. Taking one of those files in the PlutoSDR assembly directory as an example and expanding its name: cnt_adc2assy2ic_ic2assy2dac.xml cnt=container adc=analog to digital converter assy= hdl assembly ic=interconnect dac=digital to analog converter analog to digital converter -> hdl assembly -> interconnect (AXI FPGA) interconnect (AXI FPGA) -> hdl assembly -> digital to analog converter. Aaron On Thu, Oct 26, 2023 at 5:24 AM roland.johnson--- via discuss < discuss@lists.opencpi.org> wrote: > Hi all, > > I’m looking to deploy some test apps onto the Ettus E310 – I’m not fussed > whether it’s in Standalone mode or Server mode, I just want to understand > the OCPI build process for deployed projects. > > Looking at tutorial 10 of the official OCPI tutorials ( > https://opencpi.gitlab.io/releases/v2.4.6/ )whereby the FSK app is > prepared for the PlutoSDR, it looks like there’s an xdc constraints file > for the Zynq SoC that one needs to copy from the “fsk_modem” application. > > As the IOs are preconfigured for the Ettus, could this .xdc conceivably be > used for all deployed projects? And if that were the case, I suppose (even > though there would be a lot of overhead and be massive overkill for most > applications), it would be possible to use the same container, so long as > one only needed to use common peripherals in their projects like the > ADC/DAC, and not something specific like DDR interfacing? > > Best, > Roland > _______________________________________________ > discuss mailing list -- discuss@lists.opencpi.org > To unsubscribe send an email to discuss-leave@lists.opencpi.org >