Re: [Discuss OpenCPI] Fwd: Platform Mapping HDL Pins
On Thu, Jan 9, 2020 at 3:47 PM Brian Padalino <bpadalino_at_gmail.com> wrote:
> On Thu, Jan 9, 2020 at 12:34 PM Davis Hoover <dhoover_at_geontech.com> wrote:
>
>> From previous discussion you said " 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." which led me to believe you removed the spi_mosi platform
>> signal?
>>
>
> I remember going back and forth, and I couldn't figure out why. I created
> the signal in the platform because I kept getting this error in my empty
> assembly when I didn't:
>
> For file gen/empty_pluto_txrx_container.xml: in HdlContainerAssembly for
> empty_pluto_txrx_container: External signal "spi_mosi" specified for signal
> "ad9361_spi_SPI_DI" of instance "pfconfig" of worker "txrx" is not an
> external signal of the assembly
>
> My container is very simple for this:
>
> <HdlContainer platform="pluto" config="txrx">
> <Connection interconnect="zynq" device="ad9361_dac" port="in"/>
> <Connection device="ad9361_adc" port="out" interconnect="zynq"/>
> </HdlContainer>
>
> Do I somehow need the container and/or the assembly to declare the same
> signals that I told the platform would be there for mapping?
>
After a long and arduous ordeal, the solution to this is to declare the
signal outside of the device, and map the device signal to the platform.
Both are required to make it all work out.
Care should be taken not to assign those signals in the VHDL source file
associated with the platform. I believe what happens in the instantiations
is that the spi_mosi => spi_mosi mapping ends up being undriven, and
therefore isn't a problem.
I had assigned spi_mosi in my platform VHDL file when I shouldn't have.
Now everything, I believe, appears to build and bit files are being made.
The only deficiency is still that I cannot use vectors for device signal
mappings, but I am willing to work around that for now.
Thanks,
Brian
Received on Thu Jan 09 2020 - 22:10:36 CST
This archive was generated by hypermail 2.3.0
: Fri Jun 05 2026 - 08:45:25 CDT