This has shown up as intermittent, and is most likely unrelated to the zynq changes. It is under investigation.

On 3/23/21 9:07 AM, aponchak@geontech.onmicrosoft.com wrote:

(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

<pre class="moz-quote-pre" wrap="">_______________________________________________
discuss mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:discuss@lists.opencpi.org">discuss@lists.opencpi.org</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:discuss-leave@lists.opencpi.org">discuss-leave@lists.opencpi.org</a>

This issue was never observed with our board, or the zed board, for v2.1.0-beta.1 and v2.1.0-rc.2.
For both v2.1.0-beta.1 and v2.1.0-rc.2, our Zynq-7000/xilinx19_2_aarch32 board performed the similar to zed/xilinx13_3.

This issue (DP stack dump), is consistent, and has been confirmed by two people in our office.

It seem that changes make between rc.2 and the official release of v2.1.0 have exacerbate this issue for our Zynq-7000 board.

Is this easy for you to repeat?