Re: [Discuss OpenCPI] Platform Mapping HDL Pins

From: Aaron Olivarez <aaron_at_olivarez.info>
Date: Wed, 08 Jan 20 13:18:24 -0600

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_at_gmail.com> wrote:

> 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:18:24 CST