Yes, this is easy to repeat. ________________________________ From: discuss-request@lists.opencpi.org <discuss-request@lists.opencpi.org> Sent: 24 March 2021 03:30 To: discuss@lists.opencpi.org <discuss@lists.opencpi.org> Subject: discuss Digest, Vol 33, Issue 15 Send discuss mailing list submissions to discuss@lists.opencpi.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to discuss-request@lists.opencpi.org You can reach the person managing the list at discuss-owner@lists.opencpi.org When replying, please edit your Subject line so it is more specific than "Re: Contents of discuss digest..." Today's Topics: 1. Affinity/Empathy spins! Please consider a new forum host site. (aponchak@geontech.onmicrosoft.com) 2. OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies (aponchak@geontech.onmicrosoft.com) 3. Re: OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies (aponchak@geontech.onmicrosoft.com) 4. Re: OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies (James Kulp) 5. Re: OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies (aponchak@geontech.onmicrosoft.com) 6. Re: OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies (jek@parera.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 23 Mar 2021 12:19:44 +0000 From: aponchak@geontech.onmicrosoft.com Subject: [Discuss OpenCPI] Affinity/Empathy spins! Please consider a new forum host site. To: discuss@lists.opencpi.org Message-ID: <jZS2wPX5OYNCXnGNsKBqtmanAlJZkwTrQXApjCyFu9A@lists.opencpi.org> Content-Type: text/html; charset=UTF-8 A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 12 bytes Desc: not available ------------------------------ Message: 2 Date: Tue, 23 Mar 2021 12:40:48 +0000 From: aponchak@geontech.onmicrosoft.com Subject: [Discuss OpenCPI] OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies To: discuss@lists.opencpi.org Message-ID: <0isl3XimROVKsJUjwVGDacK6rJ3sWA8DmKwa2hUCw@lists.opencpi.org> Content-Type: text/html; charset=UTF-8 A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 12 bytes Desc: not available ------------------------------ Message: 3 Date: Tue, 23 Mar 2021 13:07:48 +0000 From: aponchak@geontech.onmicrosoft.com Subject: [Discuss OpenCPI] Re: OSP modeled after zed (pre-v2.1.0.rc1) is failing all Data Plane assemblies To: discuss@lists.opencpi.org Message-ID: <Pn7ARrjBheByWLcT1vHLXV519KW16WHmgzW4KA@lists.opencpi.org> Content-Type: multipart/alternative; boundary="b1_Pn7ARrjBheByWLcT1vHLXV519KW16WHmgzW4KA" > (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