>Xilinx products are not designed or intended to be fail-safe<<">

Presentation is loading. Please wait.

Presentation is loading. Please wait.

Tool Qualification Symposium 2014; April

Similar presentations

Presentation on theme: "Tool Qualification Symposium 2014; April"— Presentation transcript:

1 Tool Qualification Symposium 2014; April 9 - 10 2014
Qualification of a Tool Chain for FPGA Development for IEC and ISO26262 Tool Qualification Symposium 2014; April Validas AG München, Germany Dr. Giulio Corradi (Senior System Architect ISM – Xilinx GmbH – Xilinx Inc.) Mrs. Sylvia Waldhausen (Project Leader TÜV SÜD Rail GmbH)

2 Disclaimer © Copyright 2011 Xilinx, Inc. All rights reserved. Xilinx, the Xilinx logo, and other designated brands included herein are trademark of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners. This file contains confidential and proprietary information of Xilinx, Inc. and is protected under U.S. and international copyright and other intellectual property laws. DISCLAIMER This disclaimer is not a license and does not grant any rights to the materials distributed herewith. Except as otherwise provided in a valid license issued to you by Xilinx, and to the maximum extent permitted by applicable law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND WITH ALL FAULTS, WITHOUT ANY REPRESENTATION, WARRANTY, ASSURANCE OR GUARANTEE REGARDING THE ACCURACY, SUCCESS, OUTCOME, OR PERFORMANCE OF THE MATERIALS AND EXPRESSLY EXCLUDE ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under or in connection with these materials, including for any direct, or any indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. CRITICAL APPLICATIONS Xilinx products are not designed or intended to be fail-safe, or for use in any application requiring fail-safe performance, such as life-support or safety devices or systems, Class III medical devices, nuclear facilities, applications related to the deployment of airbags, or any other applications that could lead to death, personal injury, or severe property or environmental damage (individually and collectively, "Critical Applications"). Customer assumes the sole risk and liability of any use of Xilinx products in Critical Applications, subject only to applicable laws and regulations governing limitations on product liability.  THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS PART OF THIS DOCUMENT AT ALL TIMES. What’s a presentation about Safety without a Disclaimer? >>Xilinx products are not designed or intended to be fail-safe<<

3 Xilinx Technology Evolution
FPGA AMS AMBA ARM Algorithms Logic SW mP IO Protocols 3D-IC Logic SerDes FPGA SerDes Programmable Logic Devices Enables Programmable ‘Logic’ ALL Programmable Devices Enables Programmable Systems ‘Integration’

WHAT IS XILINX ALL PROGRAMMABLE? Accelerating Design Creation, Debug and Simplifying Reuse Artix™-7 Virtex®-7 Kintex™-7 Scalable Array of Logic, DSP, Memory Analog, Transceivers, Clock Systems Processors FPGA DSP A/D ALL Programmable Platform ZYNQ-7000® AXI4 (data) AXI4 Streaming AXI4 Lite Processor AXI Interconnect Block AXI DDR3 Mem Ctrl DMA Timer IntCtrl. Flash Int. TEMAC Plug & Play IP XST ngdbuild map par trce bitgen Coregen EDK SysGen 3rd party ISE Tool chain Vivado Tool chain

5 Dual Core Fault Tolerant
Xilinx FPGA and Functional Safety Challenges Enabling immunity to common mode failures at the silicon level Integrated BRAM ECC Bit Flipped! Basic SEU Detection Robust System Test Dual Core Fault Tolerant Configuration ECC Accurate FIT Rate Calculation XADC Monitor

6 Zynq®-7000 All Programmable SoCs The World’s First All programmable system on chip
2x GigE with DMA 2x USB 2x SDIO Static Memory Controller Quad-SPI, NAND, NOR Dynamic Memory Controller DDR3, DDR2, LPDDR2 AMBA® Switches I/O MUX MIO ARM® CoreSight™ Multi-core & Trace Debug 512 KB L2 Cache NEON™/ FPU Engine Cortex™-A9 MPCore™ 32/32 KB I/D Caches Snoop Control Unit (SCU) Timer Counters 256 KB On-Chip Memory General Interrupt Controller DMA Configuration 2x SPI 2x I2C 2x CAN 2x UART GPIO Processing System Programmable Logic: System Gates, DSP, RAM XADC PCIe Multi-Standards I/Os (3.3V & High Speed 1.8V) Multi Gigabit Transceivers S_AXI_HP0 S_AXI_HP1 S_AXI_HP2 S_AXI_HP3 S_AXI_ACP M_AXI_GP0/1 S_AXI_GP0/1 EMIO Page 6

Technical convenience Diversity is embedded naturally Safety functions requires often ad-hoc design, FPGA offer it Redundancy easily implementable Safe upgradability in case of later modification via Design Preservation Product convenience Behaves like an ASIC but is a standard product “proven in use” Can scale with the application More than 15 years of published quarterly reliability reports Every chip is individually tested, always. Robust Technology Reliability Enhanced Design For Reliability (DFR) achieving FIT < 15 Neutron Test

Sensor CONTROL UNIT Final Element PROCESS transmission Logic Solver FPGA FPGA / ZYNQ Final Element PROCESS transmission Logic Solver

9 Xilinx Solves Functional Safety Challenges
Reduce System Cost and Risk for Functional Safety Designs Fewer components, lower risk of obsolescence Design Isolation and Verification flows (IDF/IVT) reduce effort for subsequent certification of evolving implementations Reduce development and certification time and risk Safety Manual and qualified tools lowers barrier of entry Reduces time and risk for assessor interaction and education Increase productivity Safe-/Non-Safe integration and updates to non-safe functions Proven compliance IEC61508 ISO26262 Reduzieren-System Kosten und Risiken für Funktionale Sicherheit Designs Weniger Bauteile, geringeres Risiko der Veralterung Design-Isolierung und Verifikations-Flows (IDF / IVT) reduzieren Aufwand für die anschließende Zertifizierung von sich entwickelnden Implementierungen Reduzieren Sie die Entwicklung und Zertifizierung Zeit und Risiko Safety Manual und qualifizierte Tools senkt Barriere der Reduziert den Zeitaufwand und das Risiko für Gutachter Interaktion und Bildung Steigern Sie Ihre Produktivität Safe-/Non-Safe Integration und Updates für nicht-sichere Funktionen Bewährte Compliance

10 Xilinx Deliverables for Functional Safety
IEC 61508 SIL1 to SIL3 ISO 26262 ASIL-A to ASIL-D qualified safety data package Qualified tools - ISE 14.2 – and methodology for safety designs with Xilinx FPGA Safety Manual, certificate and test report V-Model, QM and reliability data for devices Isolation Design Flow and Isolation Verification Flow Integrate but separate safe and non-safe applications in one device Reduce effort and risk of subsequent certifications SEU mitigation IP Provides detection and correction of configuration upsets Tools for FIT rate analysis FIT Rate calculator, Essential and Critical Bit analysis – reduce FIT rate consideration for safety applications Power analysis tools Xilinx and supply chain committed to quality and quality management ISO9000/QML/TL9000/TS16494

11 IEC61508 and the Safety Life Cycle
11 Other risk reduction measures Specification and Realisation 1 Concept 2 Overall scope Definition 3 Hazard & Risk Analysis 4 Overall Safety Requirements 5 Overall Safety Requirements Allocation 15 Overall Modification & Retrofit 16 Decommissioning or disposal 12 Overall Installation & Commissioning 13 Overall Safety Validation 14 Overall operation, maintenance and repair 9 E/E/PE system safety requirements specification Realization 10 E/E/PE Safety-related systems Overall Installation & Commissioning Planning 6 7 8 Overall Operation & Maintenance Planning Overall Safety Validation Planning Overall Planning Back to appropriate Overall Safety Lifecycle phase IEC61508 and the Safety Life Cycle Mitigation of risk to a defined tolerance Safety life cycle has 16 phases roughly divided Phases 1-5 address analysis Phases 6-13 address realization Phases address operation Central to the standard is risk identification and mitigation Risk is a function of frequency of the hazardous event and consequence severity Zero risk can never be reached Safety must be considered from the beginning Non-tolerable risks must be reduced Xilinx plays here


Firmware / Hardware Interlock Input2 Reset Input1 Output 1 Output 1 Power Hardware Safety Reset FPGA FPGA Ready Sequencer Interlock Output 2 Function Output 2 I / O & Core Hardware Voltages Permissive Power Sequencer feeds Hardware Interlock directly to block FPGA outputs until power is stable Power Sequencer feeds FPGA to guarantee reliable reset operation during power-up and brown outs Hardware Permissive feeds Hardware Interlock directly to block FPGA outputs until permitted Hardware Permissive feeds FPGA to hold off outputs while blocked by the Hardware Interlock

FPGA Safety Function Separation Non-Safety Function System Monitor

15 Test Coverage and Characterization

IEC61508 generic IEC60601 medical ISO26262 Automotive IEC60730 Home Appliances IEC61800 Power Drive Systems IEC62061 machinery IEC60987 Nuclear IEC62138 Nuclear SOFTWARE CATEGORY B OR C IEC60880 Nuclear A IEC62425 Railway Systems IEC62279 SW Railway Signaling EN50128 SW Railway Signaling EN50129 Railway Systems EN50126 Railway RAMS IEC61511 Process Industry HW/SW HW SW System Process ECSS Q60-02 Spatial DO-254 Avionics •Segment specific norms, like for medical, railways, machinery, etc. derives from IEC Some of such norms have more stringent requirements than IEC61508 – but all requires the IEC61508 to be fulfilled. Automotive has its own standard the ISO26262 that it is also part of Xilinx safety program – it covers hardware and software and model based programming (like Matlab for example). RTCA/DO-254, DESIGN ASSURANCE GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE is a document providing guidance for the development of airborne electronic hardware. The DO-254 is a means of compliance for the design of complex electronic hardware in airborne systems. Complex electronic hardware includes devices like Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), and Application Specific Integrated Circuits (ASICs). The DO-254 standard is the counterpart to the well-established software standard RTCA DO-178B/EUROCAE ED-12B.

17 Quantitative assessment of the safety-related system
Assess the failure rate Reliability modeling is needed to assess the failure rate or probability of failure on demand (PFD) of the safety-related element or elements in question. This can then be compared with the target set in Step 3. UG116 (Xilinx Reliability Data) FIT Calculator Spreadsheet (Xilinx tool) Common Cause Failures (CCF) Qualitative assessment against the SILs Assess the systematic failures (software, process, design) . The various requirements for limiting systematic failures are more onerous as the SIL increases. These cover many of the life-cycle activities. ISE Toolchain = Xilinx Qualified no need of assessment IDF Isolation Design Flow = Xilinx Qualified no need of assessment

18 ASSESMENT …the procedure requires methods
For reference only

19 Reset & Power Sequencing
COMMON MODE CAUSES Configuration Memory FPGA Power Supply Reset & Power Sequencing Clock COMMON MODE CAUSE I/O Banks Different banks Duplicated Clock SEM IP Readback Power sequencer Dual Supply Mitigation

20 FIT RATE CALCULATOR EXAMPLE (LX9 – Ethernet Powerlink for Motor Control)


22 Firmware / Hardware Interlock
REDUNDANCY SCHEMES Firmware / Hardware Interlock Input2 Reset Input1 Output 1 Output 1 Power Hardware Safety Reset FPGA FPGA Ready Sequencer Interlock Output 2 Function Output 2 I / O & Core Hardware Voltages Permissive Power Sequencer feeds Hardware Interlock directly to block FPGA outputs until power is stable Power Sequencer feeds FPGA to guarantee reliable reset operation during power-up and brown outs Hardware Permissive feeds Hardware Interlock directly to block FPGA outputs until permitted Hardware Permissive feeds FPGA to hold off outputs while blocked by the Hardware Interlock

23 E/E/PES safety requirements specification
DEVELOPMENT LIFECYCLE – IEC61508 Validated FPGA Development Process Verification Process Output Test FPGA Safety Requirements specification Code generation FPGA Architecture Module design FPGA design behavioural modelling Module testing Synthesis, Placement and routing Post layout simulation Module integration testing Validation Testing E/E/PES safety requirements specification E/E/PES Architecture Verification of complete FPGA

24 LEVELS OF CRITICALITY (taken from IEC61508-Part 4)

25 FPGA design flow overview

26 Design Implementation
HW-COSIM completes the IEC61508 V model (adds double verification (a) Xilinx Libraries and (b) Chip execution Design Synthesis Design Verification Design Implementation Device Programming Functional Simulation (RTL simulation) Functional Simulation (with back-annotation) Static Timing Analysis Debug / In-Circuit Verification Schematic Editor Power Analysis Equivalence Checking Timing Constraints Logical / Physical Synthesis Functional Simulation (Gate level simulation) Power Estimation I/O Assignment Floorplanning Place & Route Bitstream Generation Programming Design Creation IP Blocks RTL Coding RTL + Timing Constraints Screening Technology Libraries Lib Chip Lib Prob_failure_Library * Prob_failure_Chip_Hwcosim < Prob_failure_Library

27 IP Quality - Xilinx Verification Initiative (XVI)
Sign-off Xilinx Verification Initiative (XVI) Standardization for logical and functional quality for IC Design and IP development Open Verification Methodology A methodology to improve design and verification efficiency, verification data portability and tool, and VIP interoperability A Class reference manual accompanied by an open-source SystemVerilog base class library implementation and a User Guide.. Validation Delivery verification Verification Static checks DUT

28 Test Coverage at Multiple Levels
IP Quality - XVI Open Verification Methodology Transaction coverage: coverage definition on the user‐controlled parameters usually defined in the transaction class & controlled through sequences. Error coverage: coverage definition on the pre‐defined error injection scenarios Protocol coverage: AXI Handshake coverage Flow coverage: covers various features like, outstanding, inter‐leaving, write data before write address etc Test Coverage at Multiple Levels

29 IDF (Isolation Design Flow)

30 WHAT IS IT? A two-parts design flow to ensure functional separation
ISOLATION ISOLATION VERIFICATION Approved by NSA (US national security agency) Approved by TUV-SUED For IEC61508 And ISO26262 Use planahead and floorplanning

31 How works the Design Flow
IDF requires up-front floorplanning, usually done through PlanAhead, to identify and floorplan the isolated regions. IDF requires hierarchical bottom-up synthesis. To verify isolation, Xilinx provides the Isolation Verification Tool (IVT) which allows the user to check isolation at two stages, against the UCF before implementation and then against the final routed netlist (NCD). More details about IVT are provided in the following slides. STANDARD FLOW INDIPENDENT VERIFICATION ASSURANCE

32 Design Preservation …manage the design
Use previous implementation results to preserve QoR for unchanged blocks Imported Partitions are copied and pasted Implemented Partitions are placed and routed Initial Run Incremental Run This slide as animation to copy over the blue, green and orange block. Then the red block is ‘implemented’. Click once to ‘import’ blue, click again to ‘import’ green click again to ‘import’ orange, click again to ‘implement’ red.

33 Final Results - View of Final Isolated Design in PlanAhead and FPGA Editor
Device Utilization Registers 18% LUT 35% SLICE 57% I/O 23% RAMB 59% DSP48 55% PLL 16% BUFG 31% Time to Implement 2 hrs. Unroutes Timing Score In the PlanAhead view, notice that there are 7 different colored regions in the device. These 7 regions are the floorplanned functionally and physically isolated regions of the design. The FPGA Editor view shows the routed design with the distinguishable isolated regions. Finally, a quick summary of the Spartan-6 LX150T utilization by the design is provided.

34 IDF Logical and . Physical Ownership
Isolated Region B (reg_B.vhd) Isolated Region D (reg_D.vhd) Isolated Region A (reg_A.vhd) Isolated Region C (reg_C.vhd) DCM FENCE F E N C E BUFG clock_gen.vhd top_design.vhd Logical Ownership reg_A.vhd reg_B.vhd reg_C.vhd reg_D.vhd Each isolated region physically owns the components that are logically owned by each isolated function. Global logic is logically owned by the top level and not by it’s own isolated function. This requires the that global logic be physically owned by the isolated regions.

35 Isolated Design Flow General Introduction
Global Logic Route (Clock Tree) F E N C E Isolated Region B (reg_B.vhd) Isolated Region D (reg_D.vhd) Isolated Region A (reg_A.vhd) Isolated Region C (reg_C.vhd) FENCE Intra-Region Route Inter-Region Route The Isolation Design Flow (IDF) allows for multiple physically isolated and independent functions to be implemented within a single FPGA, utilizing a fence of unused device components between each function. Each isolated function is separated by this fence, generating isolated regions within the device. The flow uses early floorplanning, modular design, modular and bottom-up synthesis, and adherence to a set of rules and considerations to guarantee isolation between functions. On-chip communication between isolated functions is achieved through the use of trusted routing, which is handles automatically by the Xilinx tools. For two isolated regions to communicate with one another, they must share an edge separated by a fence. Isolation Design Flow (IDF) is the software methodology that allows for physically isolating one module from another. Methodology backed by significant schematic analysis and software verification (IVT) to ensure elimination of single points of failure

36 IVT – UCF Mode Package Pin Checks
3/31/2017 IVT – UCF Mode Package Pin Checks Must have at least one row or column isolation between pin groups Package pin layout has three adjacency violations Note: Three Violations in two locations not visible in device view Typical Package Layout A IVT looks for Package PIN to PIN isolation violation and I/O bank IOB to IOB isolation violations. The final bullet shows that adjacent package pins aren’t necessarily adjacent within a bank. B H20 P23 J21 R23 R24 A B

37 Diversity LOCK-STEP

38 DIVERSITY PS Microblaze PL Microblaze Lock-Step PL + PS
PL + Microblaze +PS PL + PS + MB_Lock_Step Microblaze Lock-Step PL

39 LOCK-STEP CONCEPT Lock-step architecture two processors the master and the checker execute the same code being strictly synchronized. Master access to the system memory and drives all system outputs. Checker continuously executes the instructions fetched by the master processor. The outputs produced by the checker, both addresses and data, feed the compare logic (monitor). The compare logic checks the consistency of their Master and Checker data, address and control lines. Disagreement on the value of any pair of duplicated bus lines reveals a fault on either CPU without giving the chance to identify the faulty CPU.

40 Lockstep Microblaze Block Diagram

The fault tolerance features included in MicroBlaze: Enabled with C_FAULT_TOLERANT Error Detection for internal block RAMs, Support for Error Detection and Correction (ECC) in LMB block RAMs. All soft errors in block RAMs are detected and corrected Protected parts Instruction and Data Cache MMU Unified Translation Look-Aside Branch Target Cache Exception Handling Scrubbing Support To ensure that bit errors are not accumulated in block RAMs, they must be periodically scrubbed Microblaze_scrub() is the function to check memory integrity


43 Lockstep Microblaze Block Diagram

44 Current Floorplan

Diego Quagreda (QDESYS) + Trevor Hardcastle (Xilinx)

46 The LX150T Design 7 Functionally and Physically Isolated Functions.
3/31/2017 The LX150T Design 7 Functionally and Physically Isolated Functions. First MicroBlaze (Primary) Existing MicroBlaze with local instruction and data memory Second MicroBlaze (Secondary) New MicroBlaze that is exact copy of the first, with its own local instruction and data memory. First MicroBlaze Comparator Compares outputs of First and Second MicroBlazes cycle for cycle. Error output is routed to on-board LED connection. Comparator is added to the design. Second Microblaze Comparator (Redundant to First) Microblaze Peripherals Contains the existing AXI interconnect and all the basic and Command and Control AXI peripherals. Avnet Motor FMC Driver and 2 FOC Cores. Contains the FMC driver and 2 FOCs for the Avnet Motor Control Board. Existing components grouped together. NetMot Board Driver and 2 FOC Cores.

47 Updated LX150T Design Block Diagram
Areas highlighted in blue indicate each of the physically and functionally isolated functions. MicroBlaze 0 is the first MicroBlaze. MicroBlaze 1 is the second Microblaze. The SLINK RCLK and SLINK RDATA components are not part of an isolated function. This is because they are global clocking components (IBUFGDS), and in accordance with Isolation Design Flow (IDF) rules and guidelines, cannot be part of an isolated function. This will be covered later in more detail in the included IDF overview. Notice only the AXI interconnect outputs go to MicroBlaze 1. MicroBlaze zero connects to both the inputs and outputs. The MB0 reset only resets the first MicroBlaze system. This allows testing of breaking the Lockstep between the two MicroBlazes. Notice the Comparator Errors are routed to LEDs on the board as previously discussed.

48 References XAPP1086 Developing Secure and Reliable Single FPGA Designs With Xilinx 7 Series FPGAs using Isolation Design Flow WP412 The Xilinx Isolation Design Flow for Fault-Tolerant Systems UG116 Xilinx quarterly device reliability report Dual-Core Lock-Step Motor Control via Isolation Design Flow (send to

49 References XAPP 1085 XAPP1104 XAPP1105 XAPP1134 XAPP1145
7-series Isolation Design Flow Lab using ISE Design Suite 14.4 XAPP1104 Implementation of a Fail-Safe Design in the Spartan-6 Family XAPP1105 Single Chip Crypto Lab Using PR/ISO Flow XAPP1134 Developing Secure Designs Using the Virtex-5 Family XAPP1145 Developing Secure Designs with the Spartan-6 Family Using the Isolation Design Flow

50 Summary Integration in one device and redundancy by isolation is no contradiction Xilinx povide a TÜV-certified solution for Functional Safety according to IEC and ISO with the Isolation Design Flow Over 15 years of published quarterly reliability reports and FIT the rate calculator tool from Xilinx let you determine the reliability safely Follow Xilinx on: facebook.com/XilinxInc twitter.com/XilinxInc youtube.com/XilinxInc

Download ppt "Tool Qualification Symposium 2014; April"

Similar presentations

Ads by Google