Re: [Discuss OpenCPI] Platform Mapping HDL Pins

From: James Kulp <jek_at_parera.com>
Date: Wed, 08 Jan 20 13:20:03 -0500

Its nice to see all this planetary exploration (pluto is a planet again,
right?)

I think it is "best practice" to aspire to leave the constraints file
alone as much as possible, that is why we allow the mapping attributes
using "platform" etc.  But sometimes you can't win and in some case we
end up with a constraints file per platform configuration.

Having more modular constraints files is a roadmap item for sure.


On 1/8/20 12:33 PM, Aaron Olivarez 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>
>
> 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>
>
> 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>
>
> Aaron
>
> On Wed, Jan 8, 2020 at 9:52 AM Brian Padalino <bpadalino_at_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
>>


Received on Wed Jan 08 2020 - 18:20:03 CST

This archive was generated by hypermail 2.3.0 : Fri Jun 05 2026 - 08:45:25 CDT