Some more background info if it helps:
When you build from a hdl/platform/<foo> directory, it builds the platform
worker and all platform configs. For Vivado the worker and configs are
built as .edfs. A platform config can (and should, if device workers are
instantiated, in order to keep the device worker and its constraints
"together") reference a constraints file.
Then you build from a hdl/assemblies/<my_assembly> directory. An assembly
is built, again as an .edf if Vivado is used. Then a container is built,
which is synonymous with the top-level HDL design. Unless the assembly
makefile overrides the default, a default container is built which uses the
base config. A custom container can also be built, which can instantiate
device workers directly, and/or it can reference a platform config. A
container can also have a constraints file (or it can simply point to a
platform config which may already have its own constraints file)
So the FSK assembly uses custom containers, each of which follow the
platform-config-containing-constraints-and-device-workers paradigm. For
Vivado this yields a hierarchy of:
* container/bitstream
* assembly .edf
* application worker .edf
* application worker .edf
* ...
* platform config .edf (w/ constraints file)
* device worker .edf
* device worker .edf
* ...
On Wed, Jan 8, 2020 at 2:18 PM Aaron Olivarez <aaron_at_olivarez.info> wrote:
> 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:28:42 CST