These security features are enabled when generating the boot file and the configuration partitions for the non-volatile boot media. It is also possible to define a fall-back partition. In this case, should the initial first-stage boot loader fail to load its application, it will fall back to another copy of the application stored at a different memory location.
Creating a Trusted Environment
Once the device is successfully up and running, ARM® TrustZone® hardware-based security supported in the Zynq AP SoCdevice can be used to divide the system into secure and non-secure worlds. TrustZone technology implements secure and non-secure virtual cores on the Cortex-A9 processor, and encompasses memory, L2 cache, software, bus transactions, interrupts and peripherals. Hardware logic partitions the secure and non-secure worlds, and a software-based secure monitor manages switching between the two. This creates a Trusted Execution Environment (TEE) comprising TrustZone-based hardware isolation, trusted boot and a trusted OS. Applications that need to be trusted can be run in the TEE.
When it comes to implementing the image-processing pipeline within the Zynq AP SoC PLAll Programmable Zynq-7000 programmable logic fabric, TrustZone can also be used to provide secure or non-secure access to IP cores embedded in the fabric. These may be either custom-developed modules, or modules from the IP library. Securing access to critical aspects of the image-processing chain helps prevent unauthorized changes to the configuration.
Isolation Design Flow
Some safety and security implementations, such as IEC61508, may require certain elements of the system to be isolated from each other. This may be needed to achieve modular redundancy, or to support different safety areas or test functions. Xilinx’s Isolation Design Flow (IDF) helps designers enforce physical separation between the identified zones (figure 3). This is supported for the Zynq device when used with Vivado® Design Suite.
The IDF is similar to the conventional Zynq APdevice design flow, and enables users to implement a secure or safety-critical solution using familiar design techniques and coding styles. Engineers should, however, consider floorplanningfloor planning earlier in the design project to ensure proper isolation of elements such as logic, routing and I/O buffers. One important difference in the development flow is that partitions are used to isolate functions, which can simplify modification of isolated partitions if design changes are needed.
When it comes to implementing the design, several device and tool-specific implementation considerations can be used. The end application and overall engineering management plan will help determine which of these techniques should be used.
• Use of Error Detecting and Correcting (EDAC) codes on memories, if necessary this can be combined with a scrubbing function which periodically reads and corrects the data in memory
• Exploiting the Hamming difference when defining control words. Increasing the Hamming distance between command words while requiring more bits to implement can help with the reliability of the design.
• For critical commands use the “arm and fire” approach which requires two separate commands to action critical functions.
• Use of EDAC codes on external communication interfaces
• Built-In Test (BIT) capability. The Zynq XADC can support BIT my monitoring the device voltages and temperatures, as well as capturing external signals.
Identifying the applicable safety standards and establishing a suitable engineering management plan are essential to ensure the end product will achieve the required certification. Important components, tools and development methodologies are available to designers of All Programmable SoC devices, to help achieve the required standards for functional safety and security.
For more information, please visit: http://www.xilinx.com/products/design-tools/embedded-vision-zone.html