Automotive Safety Manual

Transcription

1 Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs Subscribe MNL Innovation Drive San Jose, CA

2 TOC-2 Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs Contents About the Automotive Safety Manual Altera Safety Disclaimer About the Tailored Safety Life Cycle Customer Task Responsibility Systematic Fault Management Altera Development Flow User Development Flow FPGA Requirements FPGA Architecture Generation Design Description for Logical Module Design Logical Module Design Test Description Logical Module Design Code Creation Logical Module Design Testing Logical Module Design Fault Injection FMEDA Design Description for Logical Module Integration Logical Module Integration Test Description Logical Module Integration Code Creation Logical Module Integration Testing Synthesis Place and Route Static Timing Analysis Gate-Level Simulation Bitstream Generation Design Validation Altera Tools for Automotive Safety Altera IP Cores Cyclone V Architecture for Hardware Fault Management Cyclone V Overview Cyclone V Targeted Applications Cyclone V Hardware Architecture Cyclone V Diagnostic Mechanisms and Usage Assumptions Power Supply Clock Reset Input/Outputs Configuration for Cyclone V FPGAs FPGA User Memory Hard Memory Controller...3-9

3 Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs TOC-3 Transceivers Cyclone V SoC Architecture for Hardware Fault Management Cyclone V SoC Overview Cyclone V SoC Targeted Applications Cyclone V SoC Hardware Architecture Cyclone V SoC Diagnostic Mechanisms and Usage Assumptions Power Supply Clock Reset Input/Outputs FPGA Configuration in Cyclone V SoCs FPGA User Memory Hard Memory Controller Transceivers Soft IP Diagnostic Mechanisms and Usage Assumptions HPS Interconnect HPS to FPGA Interconnect HPS Cortex-A9 MPU Subsystem HPS Debug and Trace HPS SDRAM Controller HPS On-Chip RAM HPS On-Chip Boot ROM HPS NAND Flash Controller HPS SD/MMC Controller HPS Quad SPI Flash Controller HPS FPGA Manager HPS System Manager HPS Scan Manager HPS DMAC HPS Ethernet Media Access Controller HPS USB 2.0 OTG Controller HPS SPI Controller HPS I2C Controller UART Controller HPS Timer HPS Watchdog Timer HPS CAN Controller ISO Specific Techniques and Measures for FPGA Design Design Entry Structured Description and Modularization Design Description in HDL Schematic Entry Observation of Coding Guidelines Restricted use of Asynchronous Constructs Synchronization of Primary Inputs and Control of Metastability...5-4

4 TOC-4 Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs HDL Simulation Functional Test on Module Level Functional Test on Top Level Functional and Structural coverage-driven Verification Application of Code Checker Documentation of Simulation Results Integration and Verification of Soft IPs Synthesis, Mapping, Floor Planning, Placement, Routing Check of PLD Vendor Requirements and Constraints Analysis of PLD Supporting Tool Outputs Documentation of Constraints, Results and Tools Script-based Procedures Simulation and Timing Verification of the Final Netlist Comparison of the Final Netlist with the Model (Formal Equivalence Check) Adequate Time Margins Design Rule Check PLD Integration and Testing PLD Verification PLD Integration Safety-related Special Characteristics during Chip Production Quality Control of the Production Process Known Problems in the Altera Tools and Software Software Development with the Cyclone V SoC HPS Configuring a HPS with Qsys HPS Software Tools HPS Boot Flow Software and Hardware Integration with the Cyclone V SoC HPS Supported (V)HDL versions Software Tool Confidence Level and Techniques For Error Detection IP Cores Qualified for Safety Use...-1 Specific FMEAs for Altera IP Cores...-4 Generic FMEAs for Altera IP Cores Avalon-MM Interface Generic FMEA...-8 Avalon-ST Interface Generic FMEA...-8 AMBA Interface Generic FMEA...-8 DDR SDRAM Generic FMEA...-9 Interrupt Interface Generic FMEA Tri-state Interface Generic FMEA Soft IP Diagnostic Mechanisms and Usage Assumptions HPC II Controller

5 Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs TOC-5 Document Revision History

6 About the Automotive Safety Manual 1 MNL-1082 Subscribe This document provides information for implementing safety critical systems, to guide you to meet ISO 26262: compliance on the item level. TÜV Rheinland successfully assessed previous generations of Altera FPGAs and tools to meet IEC 61508:2010 requirements up to SIL3 level. This expertise and work carries over to meet ISO 26262: Altera participated in the ISO semiconductor subgroup for clarifications of the standard with regard to semiconductors. The Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs discusses the requirements for using Cyclone V FPGAs and Cyclone V SoCs in functional safety relevant applications requiring functional safety.this document supports system and software engineers using the Cyclone V FPGAs or Cyclone V SoCs available features, and achieving additional diagnostic coverage by software measures. Altera describes several measures as safety requirements. Altera assumes the measures are in place when analyzing the functional safety of Cyclone V FPGAs and Cyclone V SoCs. Assumptions concerning the functional safety of the system that integrates the Cyclone V FPGAs or Cyclone V SoCs drive the requirements in this document. Note: TÜV Rheinland have not assessed embedded software, the soft IP, or silicon aspects of this manual (chapters 3, 4, 7, 8 and the Altera IP Cores sections of Chapter 2). After these aspects have been assessed, an updated manual will be published. This document contains guidelines on how to configure and operate the Cyclone FPGAs V and Cyclone V SoCs for functional safety relevant applications. These guidelines are considered to be useful approaches for the specific topics under discussion. You need to use discretion in deciding whether these measures are appropriate and sufficient for your applications. This document targets system applications with ASIL D safety goals for software tools aspects and ASIL B safety goals for embedded software, the soft IP, and silicon aspects. For functional safety goals that require higher functional safety integrity levels, system integrators need to tailor the requirements for their specific application. This document assumes that you are generally familiar with FPGA devices and the ISO standard. Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. *Other names and brands may be claimed as the property of others. ISO 9001:2008 Registered Innovation Drive, San Jose, CA 95134

7 1-2 Altera Safety Disclaimer MNL-1082 Altera Safety Disclaimer The information in the Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs is for reference only and intended to be used as general guidance to assist you in developing your Altera programmable logic device-based design. Altera assumes no responsibility or liability arising out of the application or use of any information, products, or services described herein. The user of Altera technologies, components, software, and tools assumes any and all responsibility and obligation for meeting any and all regulatory and safety requirements. Altera technologies features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. Altera disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Altera representative to obtain the latest forecast, schedule, specifications and roadmaps. The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. Current characterized errata are available on request. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of and registered in the U.S. Patent and Trademark Office and in other countries. Other names and brands may be claimed as the property of others. About the Tailored Safety Life Cycle Altera FPGA and SoC devices are not items in the sense of ISO 26262, but they are components in an item developed at a later point in time. Therefore, the development flow of Altera FPGAs and SoCs follow a tailored safety element out of context (SEooC) life cycle. This document considers the ISO/PAS :2016 document to tailor ISO for the applicability to FPGA users. Along with the hardware, Altera provide documentation (data sheet including electrical parameters), and safety related documentation (safety manual, FMEDA). Table 1-1: Tailored Safety Life Cycle The following table gives details of the specific tailoring of the safety cycle applicable to Altera FPGAs and SoCs. All ISO sections are relevant to each part. About the Automotive Safety Manual

8 MNL-1082 Customer Task Responsibility 1-3 ISO26262 part Topic Applicable Justification or exceptions 1 Vocabulary Yes - 2 Management of functional safety Yes - 3 Concept phase No The concept phase is under the responsibility of the customer. 4 Product development at system level 5 Product development at hardware level 6 Product development at software level 7 Production and operation No Yes - No Yes The development of the system is under the responsibility of the customer. However, Altera did assumptions at system level for the development of Cyclone V SoCs. Those assumptions are described in this document. Altera did not develop any software component considered in the scope of ISO Supporting processes Yes Altera did not consider: Altera does not consider maintenance and reparation. The maintenance and reparation can be considered only at system or vehicle level. Altera did not consider the safety related requirement for decommissioning. Distributed development Qualification of software component Proven in use argument during the development of Cyclone V SoCs 9 ASIL-oriented and safety-oriented analyses 10 Guidelines on ISO Yes No Altera did not consider ASIL decomposition during the development of the Cyclone V SoCs. Information part only. Customer Task Responsibility For your applications, this list shows the tasks that you are responsible for. Altera gives this list as an example and it is not exhaustive. For a more detailed list, contact your local Altera representative. About the Automotive Safety Manual

9 1-4 Customer Task Responsibility Use the latest FPGA or SoC documentation revision (data sheet, safety manual, FMEDA, application notes, or errata). Consider other or additional safety requirements depending of the target application and required standard (e.g. IEC 61508, IEC 61784). Verify the application mission profile is well covered by the FPGA or SoC device as used in the FMEDA. Compare system requirements versus FPGA or SoC requirements and make sure there are no deviances. Establish validity of usage assumptions considered in this document. Perform safety analysis at the system level, taking into account: The safety analysis provided for the Cyclone V FPGA or Cyclone V SoC. Consider assumptions like typical mission profile and failure rate from data book (IEC 62380). The hazard and risk analysis performed at item level Consider in the system development (with Altera support when necessary): Safety concept performed at item level Specification of soft IP safety requirements Soft IP hardware design with Altera support Verification activities of the soft IP Software development with Altera support Item integration and testing at system level Safety assessment activities at system level Production, maintenance, and decommissioning if applicable Confidence of use of software tool used for system development Consider during safety analysis, the non-functional blocks (e.g. debug). Calculate and verify the safety metrics at system level. Calculate the probability of safety goal violation. Perform DFA analysis at system level. Validate FPGA or SoC outputs behave as expected in the application, and also during error conditions. Consider and verify single point failures and latent failures at system level. Consider and verify systematic errors during system development. Verify the effectiveness of diagnostics at the system level. Perform fault injection tests and validate safety mechanisms at system level. Consider all recommendations and implementation hints given in this safety manual. For completeness of ISO26262 compliance at system level, refer to the Tailored Safety Life Cycle. The installation of the device at the module level is the customer's responsibility. However, Altera gives recommendations on Altera packages during PCB assembly. Those documents are only guidelines to help you develop a specific solution. You still require actual experience and development effort to optimize the assembly process and application design per individual device requirements, industry standards such as IPC and JEDEC, and prevalent practices in your assembly environment. Related Information About the Tailored Safety Life Cycle on page 1-2 MNL-1082 About the Automotive Safety Manual

10 Systematic Fault Management 2 MNL-1082 Subscribe To minimize the risk of faults in the item or element, reduce the potential systematic faults. A robust development flow allows you to achieve this goal. Altera Development Flow on page 2-1 TÜV Rheinland qualified this flow to be suitable for use in applications requiring compliance to IEC 61508:2010 up to SIL3 since 2010, with the most recent certification in 2015 (No.: 968/EL /12). User Development Flow on page 2-3 TÜV Rheinland assesses this flow according to the IEC 61508:2010 requirements. TÜV Rheinland deems it suitable for use for the design of safety critical circuits. Altera amended the flow with specific ISO 26262: requirements. Altera Development Flow Altera develops its tools, devices and IP cores with this flow. TÜV Rheinland qualified this flow to be suitable for use in applications requiring compliance to IEC 61508:2010 up to SIL3 since 2010, with the most recent certification in 2015 (No.: 968/EL /12).Altera is successfully certified to I.S. EN ISO 9001:2008 (certificate: NAIS ). Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. *Other names and brands may be claimed as the property of others. ISO 9001:2008 Registered Innovation Drive, San Jose, CA 95134

11 2-2 Altera Development Flow Figure 2-1: Altera Development Flow The figure shows the Altera development flow, which is split into seven phases. MNL-1082 Discovery Review? no yes Concept Rollout Review? no Review? no yes yes Plan Production Review? no Review? no yes yes Design End of Life Review? no Review? yes no At the end of each phase Altera completes a review of the entire phase with a decision to proceed to the next phase. Discovery Phase In the discovery phase, Altera assesses market opportunities and a potential fit for Altera devices. Concept Phase In the concept phase, Altera defines a solution to address specific markets and Altera creates a plan for the next phase. Systematic Fault Management

12 MNL-1082 User Development Flow 2-3 Plan Phase In the plan phase, Altera develops a project plan with inputs from various functional groups. Altera performs feasibility studies and creates high-level specifications. Design Phase In the design phase, Altera refines the high-level specification to a detailed specification, which it uses to implement the product. Altera creates test plans and verifies that the design meets the detailed specification. Rollout Phase In the rollout phase, Altera validates and qualifies the product, if it is a device. Altera identifies and notes anomalies and potentially fixes them. Production Phase In the production phase, Altera creates production ready devices, tools, and IP cores. Customers can use the Altera deliverables for production. End-of-Life Phase In the end-of-life phase, Altera informs customers that at the end of the product's life Altera will take the product off the market. Customers can, during a defined time period, change to a newer Altera product. User Development Flow Altera products allow hardware programmability. You design your own circuit and program it to the FPGA. You may have to perform many design steps that normally the silicon provider performs. You can use the V-model flow to create IP cores and circuits. TÜV Rheinland assesses this flow according to the IEC 61508:2010 requirements. TÜV Rheinland deems it suitable for use for the design of safety critical circuits. Altera amended the flow with specific ISO 26262: requirements. Systematic Fault Management

13 2-4 User Development Flow Figure 2-2: User V-Model Development Flow MNL-1082 FPGA Requirements FPGA Architecture Generation Plan Tests Design Validatation Design Description Logical Module Design Test Plan Description Code Creation Testing FMEDA Fault Injection Gate- Level Simulation Bitstream Generation Logical Module Integration Design Description Test Plan Description Testing Static Timing Analysis Code Creation Synthesis Place and Route Each V-model step description includes the following information: A description of the V-model step. Inputs. A list of inputs to the V-model step. For example, project documentation or design files. Outputs. A list of the outputs of the V-model step the final results when you process the inputs. Examples include output netlists or verification pass or fail status. Verification. Verify the V-model step is performed correctly. Altera provides examples, though you may adopt your own methods. If you use a tool for verification or during the V-model step, you must assess the tool output to aid verification. You should assess tool generated, errors, warnings or report files. Suggested tools. You may use this list of software tools to implement the particular V-model step. In some cases only one tool exists, in others many options are available. Specific techniques and measures. This list shows the explicit references in the standard that apply to each step. Later topics in this document describe Altera specific information that describes how you can satisfy these techniques and measures. Note: You should provide methods for requirements traceability through your development. Altera assumes this process as part of the overall safety requirements specification and each V-model step does not explicitly mention it. Systematic Fault Management

14 MNL-1082 FPGA Requirements 2-5 Note: According ISO Chapter a "verification planning" activity is necessary. The document does not address "verification planning" explicitly even if the verification step in each V-model step is considered. According to ISO chapter a "verification specification" activity is necessary. The document does not address "verification specification" explicitly even if the verification step in each V-model step is considered. Note: According to ISO chapter / ISO chapter : your organization shall institute, execute and maintain a continuous improvement process, based on: learning from the experiences gained during the execution of the safety lifecycle of other items, including field experience; and derived improvements for application on subsequent items.. FPGA Requirements In this step, specify the gross functionality of the FPGA subsystem. The description details the high-level specification items and overall device functionality.you analyze the high-level system requirements and derive which functions the FPGA performs. Inputs The FPGA requirements specification may include: High-level functional requirements Subsystem performance Modularity, adequate level of granularity, and simplicity Required external interfaces Items that you may specify at this stage: FPGA device family. Performance. For example, device operating clock frequency. Performance and synthesis settings. For example, using physical synthesis. IP core usage and software specification. Design language and version. External I/O constraints (speed, voltage, temperature, separation). Note: For the properties of a good modular design, refer to ISO Table 1. No specific Altera process or tool is applicable for this V-model step. Item requirements specification Safety concept Outputs Detailed FPGA requirements specification Verification report Verification Procedural crosscheck of detailed FPGA requirements specification against input documents, to check whether the design fulfills the previously established requirements. For example, using numbered items. Review documents for correctness, completeness, and consistency with respect to boundary conditions Peer review detailed FPGA requirements specification Systematic Fault Management

15 2-6 FPGA Architecture Generation Suggested tools Requirement management tool (e.g. IBM DOORS or TechnoSolutions TopTeam) MNL-1082 Specific Techniques and Measures None For more specific information on requirement specification and management, refer to ISO :2011 clause 6 and in ISO :2011 clause 6. In this step, consider some aspects of hardware architectural design, refer to ISO :2011 clause FPGA Architecture Generation Inputs 1. Generate a suitable FPGA architecture. 2. Typically, describe the functionality of the major blocks within the FPGA design and particularly their interconnection and interaction with other blocks, both within the FPGA design and with external interfaces. 3. Typically, generate a block diagram showing the major blocks and their interconnections. 4. Take the overall FPGA system requirements and partition the required functionality into submodules. 5. You should separately define and bound each of these submodules to allow you to develop and test them in isolation. 6. You can specify any third-party IP cores or standard interface. 7. You must specify any architectural features that are necessary to check the correct operation of safety designs. You may specify the following items at this stage: Design entry method Specific device within FPGA family Full tool list Text editor Supported third-party simulator tool Synthesis engine Specification of which part of tools require scripting Requirements for archived files or results Qsys IP cores Overall diagnostic techniques Diagnostic techniques on a submodule level Standard internal interfaces (for example Avalon memory-mapped (Avalon-MM) or Avalon streaming (Avalon-ST) interfaces Note: For the properties of a good modular design, refer to ISO Table 1. Item safety requirements specification (Item SRS) FPGA requirements specification FPGA safety requirements specification (FPGA SRS) Errata and known issues Systematic Fault Management

16 MNL-1082 Design Description for Logical Module Design 2-7 Outputs FPGA functional architecture diagram and description FPGA diagnostic architecture details Detailed module requirements specification and diagnostic or strategy concept Verification report Verification Procedural crosscheck of input document items versus output document items, to check whether the design fulfills the previously established requirements. For example, using numbered items. Review documents for correctness, completeness, and consistency with respect to boundary conditions Peer review of architecture. Suggested tools Standard drawing package (e.g. Microsoft Visio) Standard document package (e.g. Microsoft Word) Requirement management tool (e.g. IBM DOORS or TechnoSolutions TopTeam) Specific techniques and measures None For detailed requirements about the hardware architectural design, refer to ISO :2011 clause For more information, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 1: Design and Synthesis Chapter 2: Design Planning with the Quartus II Software Design Description for Logical Module Design In this step, create a description for the design phase of each module that the FPGA architecture step specifies. In a document describe the methods of achieving the module requirements. This document may be at the level of specifying state machine functions, mathematical functions, detailed module I/O definitions. It may be desirable to model the behavior of a module to allow you to verify the FPGA architecture and to allow a method of checking the final module implementation. You can implement this model in a high-level modeling language, for example, SystemC or The MathWorks MATLAB M. You should include a document that contains sufficient detail to allow a competent engineer to fully implement each module, including diagnostics, within an FPGA device. You should structure the design description in a standard template so you can apply lessons that you learn to a continuous improvement process for future designs. Clearly define the function, performance, and safety relevance of each module. Also clearly define the performance of interconnects and chip-wide resources. The following specific considerations relating to FPGA design for this step might be: RAM usage and arrangement Clocking resource (PLLs, routing) and arrangements Module I/O connectivity, bus types Review of documents regarding correctness, completeness, and consistency with respect to boundary conditions Note: For the properties of a good modular design, refer to ISO Table 1. Systematic Fault Management

17 2-8 Logical Module Design Test Description No specific Altera process or tool is applicable for this V-model step. MNL-1082 Inputs FPGA architecture document Detail module requirements specification Outputs Logical module design functional description Module-level behavioral model Verification report Verification Procedural crosscheck of input specification with output design document, to check whether the design fulfills the previously established requirements. For example, numbered items. Review documents for correctness, completeness, and consistency with respect to boundary conditions Peer review of documents Suggested tools Standard document package (Microsoft Word) Requirement management tool (e.g. IBM DOORS or TechnoSolutions TopTeam) System-C for behavioral modeling The MathWorks MATLAB for behavioral modeling Specific techniques and measures None For detailed requirements about the hardware detailed design, refer to ISO :2011 clause and clause Logical Module Design Test Description Inputs This V-model step involves taking a module-level functional description and generating a test specification or test description. If run, the test description should give sufficient test coverage to satisfy the requirements of the design. The overall system safety requirements and target ASIL drive the requirements. Analyze each specification point or functional requirement. Then describe specific tests to test for both the correct functionality and possible fault conditions. Also develop tests that check the capability of the diagnostic features within the module. No specific Altera process or tool is applicable for this V-model step. Item requirements specification (for overall safety requirements) FPGA requirements specification (for FPGA level requirements) Logical module design functional description Systematic Fault Management

18 MNL-1082 Logical Module Design Code Creation 2-9 Outputs Logical module design test description Verification report Verification Cross check of testable items from design document to numbered tests in test description, to check whether the design fulfills the previously established requirements Review of test descriptions to confirm whether the test cases comply to the requirements and whether you have documented the test descriptions in a systematic manner Peer review of test strategy and coverage Suggested tools Standard document package (Microsoft Word) Requirement Management Tool (e.g. IBM DOORS or TechnoSolutions TopTeam) Specific techniques and measures None For detailed requirements about the hardware detailed design, refer to ISO :2011 clause Logical Module Design Code Creation Inputs In this step, translate the detailed module functional description into a synthesizable design description, which typically takes the form of a (V)HDL description of the circuit functions and typically uses a standard text editor for design entry. If the implementation of requirements is not feasible, you must issue a change request. Note: In this document, the term (V)HDL means either Verilog HDL or VHDL. You can use various techniques for design entry. Determine which of the approaches are appropriate for the implementation of the design. You should refer to the large number of specific techniques and measures ( ISO Specific Techniques and Measures for FPGA Design on page 5-1) to assess the suitability of each design entry method. The references in ISO describe details of how you can use Altera tools to implement these techniques and measures. This V-model step does not require Altera tools or processes. However, if you use the Quartus II software you may use the analysis and elaboration function to check for correct language syntax and or elaboration errors. Analysis and elaboration is the part of the Analysis and Synthesis process that checks your design for correct source code syntax and connectivity. Logical module design functional description Outputs Synthesizable design files (usually (V)HDL) Systematic Fault Management

19 2-10 Logical Module Design Testing Verification Use of lint tool (if applicable) Code inspection or walkthrough Simulation MNL-1082 Suggested tools Standard text editor Quartus II analysis and elaboration Specific techniques and measures Refer to Structured Description and Modularization on page 5-1 Refer to Design Description in HDL on page 5-2 Refer to Restricted use of Asynchronous Constructs on page 5-3 Refer to Observation of Coding Guidelines on page 5-3 For more information, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 1: Design and Synthesis Chapter 1: Managing Quartus II Projects For more information about analysis and elaboration, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 1: Design and Synthesis Chapter 16: Quartus II Integrated Synthesis Related Information ISO Specific Techniques and Measures for FPGA Design on page 5-1 Logical Module Design Testing In this step, generate the design and run test code or testbenches. Translate each individual item from the previously generated test description into an executable test. Each test that you develop during this step, references directly to a test description item. The pass or fail status of the test should be easily accessible to you and the project managers. Many techniques are applicable for this step and you should select those that are appropriate for your own safety-related design. You might use the following commonplace approaches to this step: Code (V)HDL testbenches with a standard text editor Run this testbench within an appropriate logic simulator Capture the pass or fail result of the test Analyze failures and modify the design source code appropriately Use scripts to run tests during this step. To allow you to run tests with a high degree of reliability and repeatability, Altera supports the Tcl scripting language that the EDA community widely supports and uses. Carefully consider the selection of the third-party simulator. ISO 26262: defines requirements for establishing a tool confidence level (ISO :2011 clause 11). For example, increased confidence from use. Systematic Fault Management

20 MNL-1082 Logical Module Design Testing 2-11 Inputs Typically in this step, standard (V)HDL describes the design, therefore you only require a third-party simulator that supports the chosen language. If the design contains instances of Altera IP cores, ensure that you use the appropriate Altera simulation libraries. Altera provides these libraries with the Quartus II software. You must ensure that your simulation configuration targets the correct Altera libraries (from the specific Quartus II software version that this document specifies). You may choose to implement a methodology that uses the System Verilog HDL language for verification purposes. You should ensure that the tool and methodology you choose is appropriate for safety-related design and verification. For detecting anomalies and regression testing, according to ISO chapter , verification planning shall address the actions to be taken if anomalies are detected, and the regression strategy. In this step, you may synthesize your design and run the gate-level code through the same simulation testbench. Altera recommends this step as it gives an early indication if the code produced synthesizes into the target device. Design source files Logical Module Design Test Description document Outputs Test pass or fail status Test pass or fail diagnostics (to aid debug) Verification Tool usage Peer review of test results Manually check for valid simulator output Check of report file presence and or time or date stamp Check of time or date stamp of simulation library files Suggested tools Third-party simulator tool, which are not within the scope of this document: Mentor ModelSim simulator Cadence NCSIM Synopsys VCS Altera simulation libraries (optional) Specific techniques and measures Refer to HDL Simulation on page 5-4 Refer to Functional Test on Module Level on page 5-5 Refer to Functional and Structural coverage-driven Verification on page 5-6 Refer to Documentation of Simulation Results on page 5-6 For detailed requirements about verification planning, specification, execution and evaluation, refer to ISO :2011 clause 9.4.1, 9.4.2, Systematic Fault Management

21 2-12 Logical Module Design Fault Injection For more information, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 3: Verification Chapter 1: Simulating Altera Designs For more information about Tcl scripting, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 2: Design Implementation and Optimization Chapter 3: Tcl Scripting MNL-1082 Logical Module Design Fault Injection Inputs This step is optional and is only applicable if the module design incorporates any fault detection capability. In this step, analyze the diagnostic coverage of the implemented measure by injecting faults into the netlist of the design to determine the number of faults that are detected. You may implement a diagnostic measure at a higher level than the module design. You should perform fault injection testing at the integration of the module design to determine the diagnostic coverage of the higher level measure and to analyze any dependencies between modules. Design netlist Outputs Test diagnostic coverage Verification Tool usage Peer review of test results Suggested tools Third-party fault injection tool Third-party simulation tool Altera simulation libraries (optional) Specific techniques and measures FMEDA Refer to HDL Simulation on page 5-4 Refer to Documentation of Simulation Results on page 5-6 Refer to Logical Module Integration Testing on page 2-14 For more information, refer to: ISO :2011, Section ISO :2011, Section In this step, determine the diagnostic capability and evaluate the achieved metrics of the design. You should consider information about the failure modes, the failure mode distribution, the failure rates, and the diagnostic coverage of any implemented diagnostic measure as an input to the failure mode, effects, Systematic Fault Management

22 MNL-1082 Design Description for Logical Module Integration 2-13 Inputs and diagnostic analysis, (FMEDA). You should refine the FMEDA during the product development cycle with the most accurate information. Note: FMEDA is the same as failure modes effects analysis (FMEA) with diagnostic analysis. Failure modes Failure mode distribution Failure rate of circuit Diagnostic coverage of diagnostic measure Outputs FMEDA Verification Peer review of results Suggested tools The Altera FMEDA spreadsheet for Cyclone V SoCs For more information refer to AN718: The FMEDA Spreadsheet for Cyclone V SoCs for ISO Specific techniques and measures Not applicable Design Description for Logical Module Integration In this step, use similar techniques as Design Description for Logical Module Design on page 2-7, except that the abstraction level is at the module integration level. You can use the FPGA architecture document as a basis for describing the integration between each module. If your design integrates IP, you are responsible for integrating the supplied IP. To integrate, consider any assumptions of use described for the IP. You must consider and analyse with change management the impact of assumptions of use that you cannot fulfill or that are invalid with the design into which you are integrating the IP. For more information refer to: ISO , Clause 8 ISO/PAS :2016 Chapter (ISO and the intellectual property lifecycle). Related Information Design Description for Logical Module Design on page 2-7 Logical Module Integration Test Description In this step, use similar techniques as the Logical Module Design Test Description on page 2-8, except that you specify this testing for higher level blocks or subsystems. This test focuses on the module interfaces, You usually treat the modules as a black-box. You can target this test description at full-chip testing. Systematic Fault Management

23 2-14 Logical Module Integration Code Creation Related Information Design Description for Logical Module Design on page 2-7 MNL-1082 Logical Module Integration Code Creation Inputs In this step, integrate the individual modules developed in previous stages. At this point, combine these modules together to create higher level functions and ultimately the top-level FPGA design. The Quartus II software includes a code generation tool (Qsys) that can simplify module integration particularly when using Altera IP cores. IP user guide, safety manual or safety application note for IP (where applicable) Module design files Logical Module Design Functional Description FPGA Architecture Outputs Chip level or subsystem level design files Verification Analyze report file output for automated steps Check for VHDL source files time and date stamp Inspect Qsys generated hierarchy (when used) Suggested tools Standard text editor Quartus II Qsys Specific techniques and measures Refer to Structured Description and Modularization on page 5-1 Refer to Integration and Verification of Soft IPs on page 5-7 Logical Module Integration Testing Inputs In this step, use similar techniques as the module-level V-model step. However, the verification focus is on higher level blocks and their interfaces. You usually treat the modules as a black-box. When you perform this step on the full chip, Altera refer to it as "functional test on the top level". Refer to Functional Test on Top Level Design source files Logical Module Design Test Description document Outputs Test pass or fail status Test pass or fail diagnostics (to aid debug) Systematic Fault Management

24 MNL-1082 Synthesis 2-15 Verification Tool usage Peer review of test results Manually check for valid simulator output Check of report file presence and or time or date stamp Check of time or date stamp of simulation library files Suggested tools Third-party simulator tool, which are not within the scope of this Document: Mentor: ModelSim Cadence: NCSIM Synopsys: VCS Altera simulation libraries (optional) Specific techniques and measures Synthesis Inputs Refer to HDL Simulation on page 5-4 Refer to Functional Test on Module Level on page 5-5 Refer to Functional and Structural coverage-driven Verification on page 5-6 Refer to Documentation of Simulation Results on page 5-6 For more information, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 3: Verification Related Information Logical Module Design Testing on page 2-10 In this step, use an FPGA synthesis tool. The synthesis tool takes the input design files you specify and translates the logic functions into a format that the Quartus II software can implement within the logic cell structure of the target Altera FPGA. The Quartus II software includes the Quartus II Integrated Synthesis, which is a high-performance synthesis tool that integrates with other parts of the development flow. You may use other synthesis tools within a safety-related flow. The Quartus II software supports specific versions of the VHDL and Verilog HDL languages. You should ensure that your design sources conform to these standards. Ideally, you specify the specific version of the language you use in the FPGA requirement specification document or in a coding guidelines document. The Quartus II software performs the logic synthesis part of an FPGA compilation flow after it checks the design source files for syntactic correctness and after it elaborates the design hierarchy. You have a number of options relating to the operation of the synthesis engine. The synthesis constraints control the Quartus II synthesis engine. Design files, for example (V)HDL module and integration files. Project constraints, for example target family or device. Timing constraints (recommended, allows timing driven optimizations). Systematic Fault Management

25 2-16 Place and Route Outputs Post synthesis database (internal tool files) MNL-1082 Verification Review generated report files (for example, warnings or critical warnings, and so on) Check internal project database time and date stamp Check input file list Suggested tools Quartus II integrated synthesis tool Third-party synthesis tools, which are not within the scope of this document: Synopsys Synplify Mentor Graphics Precision Synthesis Mentor Graphics LeonardoSpectrum Specific techniques and measures Refer to Analysis of PLD Supporting Tool Outputs on page 5-8 Refer to Documentation of Constraints, Results and Tools on page 5-8 Refer to Application of Synthesis on page 5-9 Refer to Script-based Procedures on page 5-10 For more information about how to invoke Quartus II integrated synthesis and the constraints and effect they have, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 1: Design and Synthesis Related Information Supported (V)HDL versions on page 8-1 Place and Route Input In this step, take the result of the logic synthesis and create a netlist that includes the specific placement of each logic cell. Additionally, derive the precise routing between the logic cells and other device resources. You can allow the place and route tool to use the system timing constraints to drive the place and route process. Altera developed the internal algorithms, which are complex in nature, over many versions of the Quartus II software. A full description of the techniques is beyond the scope of this documentation. The place and route process may perform significant manipulation of the synthesis database rather than just placing and routing the synthesis netlist items. Specify the constraints and setup of the Quartus II Fitter early in the design cycle, perhaps at project-wide level. Post synthesis database Project constraints for example target family/device Timing constraints (optional, for timing driven place and route) Systematic Fault Management

26 MNL-1082 Static Timing Analysis 2-17 Outputs Post place and route netlist (internal tool files) Verification Analysis of tool generated report files (check for warnings, critical warnings etc) Check internal project database time and date stamp Check for valid gate-level simulation results Suggested tools Quartus II fitter Specific techniques and measures Refer to Design Rule Check on page 5-15 For more information, refer to the following topics in the Quartus II Software Handbook v14.1: Volume 2: Design Implementation and Optimization Chapter 12: Timing Closure and Optimization Chapter 14: Area Optimization Static Timing Analysis Inputs In this step, perform static timing analysis, to gain accurate knowledge of the timing-related performance of the design, so that you do know if the circuit can perform correctly. You may specify overall system performance of the FPGA in the FPGA requirements document. The FPGA architecture document may specify the timing of subsystems within the design. Altera provides the TimeQuest timing analysis tool within the Quartus II software. Use this comprehensive tool to verify the timing performance against a set of user-provided timing constraints. Timing constraints are a critical part of the overall FPGA design you should carefully design and manage them. Develop timing constraints early in the FPGA design cycle. The Quartus II software uses timing constraints during synthesis and fitting. For example the synthesis and place and route steps can use timing constraints to provide better results for example, speed and area optimizations. Timing constraints FPGA architecture FPGA requirements specification Device timing model Post place and route netlist Outputs Timing report files Systematic Fault Management

27 2-18 Gate-Level Simulation Verification Review tool output files for timing failures Check for valid results from tool: Check that the tool reads the correct constraints (.sdc) file Check the clocks summary report Check the reports that the all summaries macro generates Check for report file presence and or time and date stamp Check unconstrained paths in report files MNL-1082 Suggested tools Quartus II TimeQuest Timing Analyzer Specific techniques and measures Refer to Documentation of Constraints, Results and Tools on page 5-8 Refer to Simulation and Timing Verification of the Final Netlist on page 5-11 Refer to Adequate Time Margins on page 5-13 For more information about the specific requirement to modify timing constraints when using device families for which the process technology is in use less than three years, refer to Adequate Time Margins on page 5-13 Gate-Level Simulation Inputs In this step, validate the previous processes. Simulate the design with the netlist that is output from the place and route step. As the tool can only generate this netlist by also performing logic synthesis, you also test the operation of the synthesis tool. It is typical to re-use the simulation testbenches you generate in the Logical Module Design Testing on page 2-10 and Logical Module Integration Testing on page However, you may decide that your development should apply additional testing at this stage. Describe this requirement in the FPGA Requirements Specification or FPGA Architecture documents. Post place and route netlist Logical module test description and testbenches Logical module integration test description and testbenches Outputs Test pass or fail status Test pass or fail diagnostics (to aid debug) Verification Peer review of test results Manually check for valid simulator output: Manually check waveforms Manually check report file pass or fail status Check of report file presence and or time and date stamp Systematic Fault Management