> (TheEmpathyedioris ismisbehaving.Itisnotrespectingmyspacebar. I’m having to go back and re-manually insert spaces)
>
> Release Version: v2.1.0
>
> Vivado 2019.2
We have developed an OSP for a Zynq-7000-based board, and modeled the implementation (zynq primitive and PW) after the Zed, pre-v2.1.0.rc1. Concisely, our OSP implementation does not have the reorganization of the zynq primitive, etc. Our OSP has it’s own zynq primitive which does not expose the ACP port, and is instanced in the PW.
We have successfully built all component unit test bitstreams, the patten_capture_asm and testbias assemblies for our Zynq-7000-board and the zed board.\
We have successfully ran pattern_capture app on both boards, which confirms that Control Plane is working fine.
On the zed board, we have successfully ran app/assemblies that implement the Data Plane, including testbias.
On the other Zynq-7000-based board, running any app/assembly that implements the Data Plane fails with the following Stack Dump:
“….\
Application started/running \[0 s 2 ms\]\
Waiting for application to finish (no time limit)\
\
Assertion failed: id => m_ports.size() is false at ../gen/os/interfaces/include/OcpiOsAssert.h:118.\
Stack Dump:\
ocpirun(_ZN4OCPI2OS9dumpStackERSo+0x20) \[0x264914\]\
ocpirun() \[0x265110\]\
ocpirun(_ZN4OCPI2OS15assertionFailedEPKcS2_j+0x5c) \[0x2651a4\]
“
This doesn’t seem like an issue that would be cause by simply reorganizing the zynq primitive, but rather something more specific to the SDP. Is this a consequence of bug fixes/improvements made to the SDP infrastructure, which are not backward compatible?
The obvious solution is to upgrade the implementation to match the latest zed, but is there another alternative?
Thanks
Adam
Received on Tue Mar 23 2021 - 13:07:48 CDT