I am trying to follow the instructions from this mailing list post:

http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/2019-May/000184.html

I am trying to start with a simple port to the ADALM-PLUTO platform, but I
prefer to keep their top level names for the platform so I don't have to
modify the XDC very much.

I defined the HdlPlatform to have:

I then added, as recommended:

I then created a config called pluto_txrx which is defined as:

 <HdlConfig Language="vhdl">
     <device name="ad9361_adc"/>
     <device name="ad9361_dac"/>
 </HdlConfig>

But, my spi_mosi signal isn't connected to ad9361_spi_SPI_DI as I would
have expected in the generated code.

Also, it seems like the HdlPlatform defines some base platform, and the
HdlConfig is some more specific thing with the devices instantiated?

Is there a way to get the base to include the ad9361_adc and ad9361_dac for
all builds and get rid of the HdlConfig requirement?  Essentially think of
it as a part of the board proper?  I tried to look at the matchstiq_z1 as
an example, but it wasn't clear to me on how to make that happen.

Thanks,
Brian

You need to add ad9361_spi_ prefix so your HdlPlatform needs to look like
this:

I'm working on a port for the PLUTO and I used the approach of updating the
XDC file but yours is valid too. This is what my platform xml looks like:

<sdp Name='zynq' Master='true' Count='4'/>
<Property Name='axi_error' Type='bool' Arraylength='4' Volatile='true'/>
<Property Name='sdpDropCount' type='uchar' volatile='true'/>

<!-- debug properties -->
<property name='useGP1' type='bool' parameter='1' default='false'/>
<property name='debug_state' type='Ulonglong' arraylength='4'

volatile='true' debug='false'/>
<property name='debug_state1' type='Ulonglong' arraylength='4' volatile='true' debug='false'/>
<property name='debug_state2' type='Ulonglong' arraylength='4' volatile='true' debug='false'/>

<!-- Put any additional platform-specific properties here using

<Property> -->
<!-- Put any built-in (always present) devices here using <device> -->
<!-- Put any card slots here using <slot> -->
<!-- Put ad hoc signals here using <signal> -->

<device worker='ad9361_adc'/>
<device worker='ad9361_adc_sub'>
  <Property name='LVDS_P' value='false'/>
</device>

<device worker='ad9361_dac'/>
<device worker='ad9361_dac_sub'>
  <Property name='LVDS_P' value='false'/>
</device>

<device worker='ad9361_data_sub'>
  <Property name='LVDS_P' value='false'/>
  <Signal name='DATA_CLK_N' platform=''/>
  <Signal name='FB_CLK_N' platform=''/>
  <Signal name='TX_FRAME_N' platform=''/>
  <Signal name='RX_FRAME_N' platform=''/>
</device>

<device Worker='ad9361_spi'/>
<device Worker='ad9361_config'/>

The only caveat is that those device workers in the platform xml also need
to be instanced in a platform config file or container. The platform and
card XML simply dictate what's allowed to be instanced. Every device worker
needs to be instanced in either a platform or container. Here's an example
of one my HdlConfig:

Aaron

On Wed, Jan 8, 2020 at 9:52 AM Brian Padalino bpadalino@gmail.com wrote:

I am trying to follow the instructions from this mailing list post:

http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/2019-May/000184.html

I am trying to start with a simple port to the ADALM-PLUTO platform, but I
prefer to keep their top level names for the platform so I don't have to
modify the XDC very much.

I defined the HdlPlatform to have:

<device worker="ad9361_spi"> <signal name="SPI_CLK" platform='spi_clk'/> <signal name="SPI_DO" platform='spi_miso'/> <signal name="SPI_DI" platform='spi_mosi'/> <signal name="SPI_ENB" platform='spi_csn'/> <signal name="RESETB" platform='gpio_resetb'/> </device>

I then added, as recommended:

<!-- SPI Interface --> <signal output="spi_mosi" /> <signal input="spi_miso" /> <signal output="spi_clk" /> <signal output="spi_csn" /> <signal output="gpio_resetb" />

I then created a config called pluto_txrx which is defined as:

 <HdlConfig Language="vhdl">
     <device name="ad9361_adc"/>
     <device name="ad9361_dac"/>
 </HdlConfig>

But, my spi_mosi signal isn't connected to ad9361_spi_SPI_DI as I would
have expected in the generated code.

Also, it seems like the HdlPlatform defines some base platform, and the
HdlConfig is some more specific thing with the devices instantiated?

Is there a way to get the base to include the ad9361_adc and ad9361_dac for
all builds and get rid of the HdlConfig requirement?  Essentially think of
it as a part of the board proper?  I tried to look at the matchstiq_z1 as
an example, but it wasn't clear to me on how to make that happen.

Thanks,
Brian

You need to add ad9361_spi_ prefix so your HdlPlatform needs to look like
this:

I'm working on a port for the PLUTO and I used the approach of updating
the XDC file but yours is valid too. This is what my platform xml looks
like:

The only caveat is that those device workers in the platform xml also need
to be instanced in a platform config file or container. The platform and
card XML simply dictate what's allowed to be instanced. Every device worker
needs to be instanced in either a platform or container. Here's an example
of one my HdlConfig:

On Wed, Jan 8, 2020 at 12:34 PM Aaron Olivarez aaron@olivarez.info
wrote:

You need to add ad9361_spi_ prefix so your HdlPlatform needs to look like
this:

<device worker="ad9361_spi"> <signal name="ad9361_spi_SPI_CLK" platform='spi_clk'/> <signal name="ad9361_spi_SPI_DO" platform='spi_miso'/> <signal name="ad9361_spi_SPI_DI" platform='spi_mosi'/> <signal name="ad9361_spi_SPI_ENB" platform='spi_csn'/> <signal name="ad9361_spi_RESETB" platform='gpio_resetb'/> </device>

When I tried, this I received the following error:

For file pluto.xml: Signal "ad9361_spi_SPI_CLK" is not defined for device
type "ad9361_spi"

Which I think makes sense.  The signal name is defined as SPI_CLK in the
ad9361_spi.xml file.

Looking through the generated code, I don't think things are still
correct.  But maybe I am looking too early in the process?

I'm working on a port for the PLUTO and I used the approach of updating
the XDC file but yours is valid too. This is what my platform xml looks
like:

<!-- This file defines the pluto HDL platform --> <HdlPlatform Language='VHDL' Spec='platform-spec'> <specproperty Name='platform' Value='pluto'/> <!-- These next two lines must be present in all platforms --> <metadata Master='true'/> <timebase Master='true'/> <!-- This platform worker provides a control plane --> <cpmaster master='true'/> <!-- Set your time server frequency --> <device Worker='time_server'> <Property Name='frequency' Value='100e6'/> </device> <sdp Name='zynq' Master='true' Count='4'/> <Property Name='axi_error' Type='bool' Arraylength='4'

Volatile='true'/>

<Property Name='sdpDropCount' type='uchar' volatile='true'/> <!-- debug properties --> <property name='useGP1' type='bool' parameter='1' default='false'/> <property name='debug_state' type='Ulonglong' arraylength='4' volatile='true' debug='false'/> <property name='debug_state1' type='Ulonglong' arraylength='4' volatile='true' debug='false'/> <property name='debug_state2' type='Ulonglong' arraylength='4' volatile='true' debug='false'/> <!-- Put any additional platform-specific properties here using <Property> --> <!-- Put any built-in (always present) devices here using <device> --> <!-- Put any card slots here using <slot> --> <!-- Put ad hoc signals here using <signal> --> <device worker='ad9361_adc'/> <device worker='ad9361_adc_sub'> <Property name='LVDS_P' value='false'/> </device> <device worker='ad9361_dac'/> <device worker='ad9361_dac_sub'> <Property name='LVDS_P' value='false'/> </device> <device worker='ad9361_data_sub'> <Property name='LVDS_P' value='false'/> <Signal name='DATA_CLK_N' platform=''/> <Signal name='FB_CLK_N' platform=''/> <Signal name='TX_FRAME_N' platform=''/> <Signal name='RX_FRAME_N' platform=''/> </device> <device Worker='ad9361_spi'/> <device Worker='ad9361_config'/> </HdlPlatform>

Thanks!  This is great!  Were you planning on open sourcing this, or just
for your own little project?

The only caveat is that those device workers in the platform xml also
need
to be instanced in a platform config file or container. The platform and
card XML simply dictate what's allowed to be instanced. Every device
worker
needs to be instanced in either a platform or container. Here's an
example
of one my HdlConfig:

<HdlConfig Constraints="pluto_ad9361_txrx_sub_mode_2_cmos"> <device name="ad9361_spi"> <property name="CP_CLK_FREQ_HZ_p" value="100e6"/> <!-- we MUST

provide

to this worker the pluto's control plane clock freq value -->
</device>
<device name="ad9361_config"/>
<device name="ad9361_data_sub">
<property name="lvds_p" value="false"/>
<property name="half_duplex_p" value="false"/>
<property name="single_port_p" value="true"/>
<property name="swap_ports_p" value="true"/>
</device>
<device name="ad9361_adc"/>
<device name="ad9361_adc_sub">
<property name="lvds_p" value="false"/>
<property name="half_duplex_p" value="false"/>
<property name="single_port_p" value="true"/>
</device>
<device name="ad9361_dac"/>
<device name="ad9361_dac_sub">
<property name="lvds_p" value="false"/>
<property name="half_duplex_p" value="false"/>
<property name="single_port_p" value="true"/>
</device>
</HdlConfig>

This is also very good to know.  I only had the ad9361_adc and ad9361_dac
in there before.  What is interesting is that when I have the ad9361_adc
before the ad9361_adc_sub in the XML, I get the following error:

For file ../../pluto/pluto_txrx.xml: Platform device 'ad9361_adc_sub' is
already in the platform configuration

Should I be adding a new "assembly" which defines all this stuff as opposed
to a different "configuration"?

Thanks for all the guidance.

Brian

For the platform XML:

• for: device element: signal subelement: name attribute: value should
  match the signal names from the OWD (as you surmised)
• for: device element: signal subelement: platform attribute: is only
  necessary if a) the device pin is not connected to the slot/FPGA, in which
  case its value should be an empty string, or b) the code-generated HDL
  top-level design's signal names do not match the signal names in the
  constraint file, in which case the value should be set to the value from
  the corresponding constraint file signal

So your ad9361_spi element of your platform XML should probably look
something like:

Also, in your original post it sounded like you were adding signal elements
as subelements of the platform element, where the signal elements' name
attribute had values of ad9361_spi*. Such content is incorrect and maybe
part of the confusion. Device worker signals are automatically exposed at
the top level of the HDL design.

For the "Platform device 'ad9361_adc_sub' is already in the platform
configuration" error, I suspect you are running into a consequence of
auto-instantiation of subdevice workers. I'd recommend instancing the
device/subdevice workers in the platform config XML in the following order
(this is based off of the order within
projects/assets/hdl/platforms/zed/cfg_1rx_1tx_fmcomms_2_3_lpc_lvds.xml,
which is known to build successfully):

<device name="ad9361_spi"><device name="ad9361_data_sub"><device name="ad9361_config"><device name="ad9361_adc_sub"/><device name="ad9361_dac_sub"/><device name="ad9361_adc0"/><device name="ad9361_dac0"/>

On Wed, Jan 8, 2020 at 1:52 PM Davis Hoover dhoover@geontech.com wrote:

For the platform XML:

• for: device element: signal subelement: name attribute: value should
  match the signal names from the OWD (as you surmised)
• for: device element: signal subelement: platform attribute: is only
  necessary if a) the device pin is not connected to the slot/FPGA, in
  which
  case its value should be an empty string, or b) the code-generated HDL
  top-level design's signal names do not match the signal names in the
  constraint file, in which case the value should be set to the value from
  the corresponding constraint file signal

So your ad9361_spi element of your platform XML should probably look
something like:

<device worker="ad9361_spi"> <signal name="SPI_CLK" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_DO" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_DI" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_ENB" platform='enter_signal_name_from_constraint_file'/> <signal name="RESETB" platform='enter_signal_name_from_constraint_file'/> </device>

Also, in your original post it sounded like you were adding signal
elements
as subelements of the platform element, where the signal elements' name
attribute had values of ad9361_spi*. Such content is incorrect and maybe
part of the confusion. Device worker signals are automatically exposed at
the top level of the HDL design.

Thank you.  This helps clear up some confusion I had.  I was declaring a
signal outside of the device, which seems incorrect.  The platform
attribute in the device element inside the HdlPlatform node is the only
thing required to perform the mapping.

It seems the HdlConfig instantiates the elements and I still need to have a
base configuration as well as my txrx configuration which is "fixed" on the
PCB - no slots.  Understandable.

For the "Platform device 'ad9361_adc_sub' is already in the platform
configuration" error, I suspect you are running into a consequence of
auto-instantiation of subdevice workers. I'd recommend instancing the
device/subdevice workers in the platform config XML in the following
order
(this is based off of the order within
projects/assets/hdl/platforms/zed/cfg_1rx_1tx_fmcomms_2_3_lpc_lvds.xml,
which is known to build successfully):

<device name="ad9361_spi"><device name="ad9361_data_sub"><device name="ad9361_config"><device name="ad9361_adc_sub"/><device name="ad9361_dac_sub"/><device name="ad9361_adc0"/><device name="ad9361_dac0"/>

I figured this out via trial and error.

I am still a little lost regarding the "top level" and when that gets
made.  I see this pluto_txrx_rv entity/component that gets created.  Is
that my top level?  I can't imagine it is.

My ultimate goal is to target the FSK application to the pluto.  I found
the assemblies in the assets/hdl/assemblies/fsk_modem and added one for my
pluto device.  Is this how I go about targeting this to make a top level?

Is there a simpler way to build a top level?  Is that the purpose of the
matchstiq_z1 empty assembly?

Thanks,
Brian

The top level is made when you build the assembly. The work I'm doing is
going to be open sourced and I'm targeting the same example applications.
The issue I've run into is that 7010 is smaller than 7020 and hitting
resource boundaries when implementing fsk_modem assembly.

On Wed, Jan 8, 2020 at 1:10 PM Brian Padalino bpadalino@gmail.com wrote:

On Wed, Jan 8, 2020 at 1:52 PM Davis Hoover dhoover@geontech.com wrote:

For the platform XML:

• for: device element: signal subelement: name attribute: value should
  match the signal names from the OWD (as you surmised)
• for: device element: signal subelement: platform attribute: is only
  necessary if a) the device pin is not connected to the slot/FPGA, in
  which
  case its value should be an empty string, or b) the code-generated HDL
  top-level design's signal names do not match the signal names in the
  constraint file, in which case the value should be set to the value from
  the corresponding constraint file signal

So your ad9361_spi element of your platform XML should probably look
something like:

<device worker="ad9361_spi"> <signal name="SPI_CLK" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_DO" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_DI" platform='enter_signal_name_from_constraint_file'/> <signal name="SPI_ENB" platform='enter_signal_name_from_constraint_file'/> <signal name="RESETB" platform='enter_signal_name_from_constraint_file'/> </device>

Also, in your original post it sounded like you were adding signal
elements
as subelements of the platform element, where the signal elements' name
attribute had values of ad9361_spi*. Such content is incorrect and maybe
part of the confusion. Device worker signals are automatically exposed
at
the top level of the HDL design.

Thank you.  This helps clear up some confusion I had.  I was declaring a
signal outside of the device, which seems incorrect.  The platform
attribute in the device element inside the HdlPlatform node is the only
thing required to perform the mapping.

It seems the HdlConfig instantiates the elements and I still need to have
a
base configuration as well as my txrx configuration which is "fixed" on
the
PCB - no slots.  Understandable.

For the "Platform device 'ad9361_adc_sub' is already in the platform
configuration" error, I suspect you are running into a consequence of
auto-instantiation of subdevice workers. I'd recommend instancing the
device/subdevice workers in the platform config XML in the following
order
(this is based off of the order within
projects/assets/hdl/platforms/zed/cfg_1rx_1tx_fmcomms_2_3_lpc_lvds.xml,
which is known to build successfully):

<device name="ad9361_spi"><device name="ad9361_data_sub"><device name="ad9361_config"><device name="ad9361_adc_sub"/><device name="ad9361_dac_sub"/><device name="ad9361_adc0"/><device name="ad9361_dac0"/>

I figured this out via trial and error.

I am still a little lost regarding the "top level" and when that gets
made.  I see this pluto_txrx_rv entity/component that gets created.  Is
that my top level?  I can't imagine it is.

My ultimate goal is to target the FSK application to the pluto.  I found
the assemblies in the assets/hdl/assemblies/fsk_modem and added one for my
pluto device.  Is this how I go about targeting this to make a top level?

Is there a simpler way to build a top level?  Is that the purpose of the
matchstiq_z1 empty assembly?

Thanks,
Brian

The top level is made when you build the assembly. The work I'm doing is
going to be open sourced and I'm targeting the same example applications.
The issue I've run into is that 7010 is smaller than 7020 and hitting
resource boundaries when implementing fsk_modem assembly.