Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Link monitoring
Before illustrating a possible solution, some further considerations about requirements listed in previous section are illustrated.
[[#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 virtually transparent to the other parts of the system. As a consequence,
*<u>application software don't need any change when 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>
*last but not least, <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.xilinx.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, 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 - is not necessary
*thanks to the communication channel between the two ARM cores, core #0 can be signalled by core #1 in case an alert condition is detected at the transceivers level.
==Conclusions==
