Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Limitations of traditional AMP configurations
This solution can be considered as a sort of natural evolution on the traditional AMP configuration described in <ref name="AN-BELK-001">DAVE Embedded Systems, [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|''AN-BELK-001: Asymmetric Multiprocessing (AMP) on Bora – Linux FreeRTOS'']]</ref>. For this reason, reading of [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|this document]] is highly recommended.
==Limitations of traditional AMP configurations==
Xilinx Zynq AP architecture provides unprecedented possibilities in terms of integration. In industrial world applications, this is often leveraged to combine on a single chip the implementation of real-time tasks with generic software applications and functionalities that don't have specific requirements in terms of real-timeness{{efn|Network connectivity is an example of such functionalities.}}. In addition, the flexibility offered by the FPGA - known as Programmable Logic or PL for short - allows system designer to implement in hardware custom IPs to add new interfaces and peripherals or to move processing modules from the software to the hardware world{{efn|Powerful tools have been introduced in the market recently that facilitate this process significantly. One of these is [http://www.xilinx.com/products/design-tools/software-zone/sdsoc.html SDSoC]. Bora and BoraX are two of the [http://www.xilinx.com/products/design-tools/software-zone/sdsoc.html#boardskits supported hardware platforms].}}.
The following list recaps the typical requirements that such systems must meet. This list has been compiled on the base of real world use cases (specifically medical, transportation, automation and telecom applications):
* real-time and non real-time tasks integration: on the same physical component it is required that non real-time and real-time world coexist; this allows overall design simplification, BOM reduction and better integration* the non real-time world - denoted as W2 in the rest of the document - is based on a well-known operating system such as linux* the real-time world - denoted as W1 in the rest of the document - is based on a RTOS or a bare metal executable* inter o.s. -world communication and data sharing: the two worlds must have the capability to:* integrity# communicate via asynchronous mechanisms*# share data* isolationintegrity: W1 must guarantee a high reliability level, no matter how the other world behaves; in other words, W1 can not be altered by any kind of actions taken by the code executed in W2. The traditional AMP<ref name="AN-BELK-001"></ref> configuration satisfies all of these requirements except the last one. For example an application with ''root'' privileges or code executed in kernel space can access memory regions that are supposed to be exclusively accessed by code executed in W1. This may lead to unpredictable behaviors and potentially to catastrophic consequences. This is where TrustZone technology comes to help: it creates a sort of barrier between the two worlds and prevents W2 code from unauthorized accesses to certain regions in the processor's addressing space.
TBD
aggiungere analisi delle soluzioni micro grosso+microcontrollore e di quelle big.little ?
==TrustZone-based approach==