Re: [Discuss OpenCPI] Platform Mapping HDL Pins

From: Brian Padalino <bpadalino_at_gmail.com>
Date: Wed, 08 Jan 20 14:09:31 -0500

On Wed, Jan 8, 2020 at 1:52 PM Davis Hoover <dhoover_at_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


Received on Wed Jan 08 2020 - 19:09:31 CST