Changes

|1.0.9.0|September 2015|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0]]June 2016|Internal draftFirst public release

This White Papers document describes a practical application of the asymmetric multi-processing (AMP) configuration illustrated [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|here]] [a]. Specifically, this technique is approach has been used to implement a non-intrusive continuous link monitoring mechanism for the Xilinx Zynq multi-gigabit serial transceivers{{efn|More complex configurations such as [[BRX-WP001:_Real-timeness,_system_integrity_and_TrustZone®_technology_on_AMP_configuration|this oneb]] can be used as well.}}.  The starting point for this work is represented by the Xilinx Application Notes

with Vivado IP Integrator and AXI4'', 19th November 2014''</ref>, thus reading of these documents is highly recommended.

The issue that this White Paper technical note addresses is the need to monitor of monitoring multi-gigabit transceivers link status when operating on the field [c] in a <u>non-intrusive way</u> and <u>on the field</u>{{efn|That is after product has been sold and it is operating.}}. Just imagine a product that is based on the architecture similar to the one depicted in the following figure. It is assumed that this architecture is quite representative of many real use cases.  [[File:TBDBorax-wp001 01.png|thumb|center|200px400px|Concept block diagram of the systemwithout monitoring subsystem]]  A generic communication IP is implemented In in Programmable Logic (PL) . This IP makes use of multi-gigabit transceivers to communicate with the peer at the other end of the physical link. On Processor Subsystem (PS) side, Linux operating system is used. On top of the kernel, several applications run, implementing high-level product's functionalities, including the management of data sent and received data through the link shown in the figure. It is also assumed that the reliability of this link is a crucial factor for the successful product functioning. Thus a specific monitoring of its health has to be implemented in order to detect any deviation from normal working conditions that may affect link robustness such as:

Additional requirements have to be metLast but not least, that is monitoring function functionality has to be substantially non-intrusive with respect to:*<span id="REQ1">REQ1</span>: the software applications running in the Linux realm*<span id="REQ2">REQ2</span>: the user functions implemented in PL*<span id="REQ3">REQ3</span>: transmission/reception of user data through the link*<span id="REQ3">REQ4</span>: the overall system functionality.

  [a] At the time of this writing, [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|this document]] refers to BORA only. However, the same AMP implementation is available for BORA Xpress as well. [b] More complex configurations such as [[BRX-WP001:_Real-timeness,_system_integrity_and_TrustZone®_technology_on_AMP_configuration|this one]] can be used as well. [c] That is after the product has been deployed. ==Proposed solutionLink monitoring==

[[#REQ1|REQ1]], [[#REQ2|REQ2]] and through [[#REQ3REQ4|REQ3REQ4]] specify in detail a generic requirement of ''non-intrusiveness''. In other words, it is required that the implementation of link monitoring function is that it is virtually transparent to the other parts of the system. As a consequence, *<u>application software dondoesn't need any changewhen adding such functionality</u>*<u>the cost of additional PL resources is neglectable</u> with respect to the Microblaze-based approach described in <ref name="XAPP743"></ref>*<u>physical link is not affected at all</u>: normal operating, while monitoring is continuously in progress, is guaranteed by the integrated circuitry of GTP/GTX transceivers<ref name="UG482">''UG482 7 Series FPGAs GTP Transceivers User Guide'', http://www. Alsoxilinx.com/support/documentation/user_guides/ug482_7Series_GTP_Transceivers.pdf</ref><ref name="UG476">''UG476 7 Series FPGAs GTX/GTH Transceivers User Guide'', http://www.xilinx.com/support/documentation/user_guides/ug476_7Series_Transceivers.pdf</ref>. Block diagram of the solution here described is depicted in the following figure.  [[File:Borax-wp001 02.png|thumb|center|400px|Concept block diagram of the system with monitoring subsystem]]  Conceptually, no the system architecture amounts to the one illustrated in <ref name="XAPP743"></ref> with two notable differences:*since monitoring software is executed by the second Cortex A9 core, MicroBlaze infrastructure - that would consume PL resources are While - is not necessary*thanks to the communication channel between the system two ARM cores, core #0 can be signalled by core #1 in case an alert condition is performing detected at the transceivers level. Thus appropriate actions can be taken at application level. This solution has been tested on BORA Xpress/BORA Xpress EVB platform implementing PCIe connectivity. PCIe Root Complex and AXI-to-DRP bridge have been integrated in PL. JTAG-to-AXI bridge has been included as well in order to keep the possibility to access monitoring data via JTAG during development/debugging stage. This allows to retrieve data from host running Vivado and generate 2D statistical eye diagrams very easily (for more details please refer to <ref name="XAPP743"></ref>). The following figures show a couple of such diagrams. 

==ConclusionsReferences=={{reflist}}