Cyclone V SoCs. Automotive Safety Manual. 101 Innovation Drive San Jose, CA MNL Subscribe Send Feedback

Transcription

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

2 TOC-2 Cyclone V SoCs Automotive Safety Manual Contents Introduction to Cyclone V SoCs and Safety Cyclone V SoC Overview Targeted Applications Systematic Fault Management Altera Development Flow Discovery Phase Concept Phase Plan Phase Design Phase Rollout Phase Production Phase End-of-Life Phase User Development Flow Specify FPGA Requirements Generating FPGA Architecture Creating Design Description for Logical Module Design Creating Test Description for Logical Module Design Coding Logical Module Design Testing Logical Module Design Injecting Faults Logical Module Design Performing FMEDA Creating Design Description for Logical Module Integration Creating Test Description for Logical Module Integration Coding Logical Module Integration Testing Logical Module Integration Performing Synthesis Performing Place and Route Performing Static Timing Analysis Performing Gate-Level Simulation Generating Bitstream Validating the Design Altera Tools Altera IP Cores Nios II Processor Architecture for Random Hardware Fault Management Cyclone V SoC Hardware Architecture Diagnostic Mechanisms and Usage Assumptions Power Supply Clock

3 Cyclone V SoCs Automotive Safety Manual TOC-3 Reset Input/Outputs FPGA Configuration FPGA User Memory 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 ISO26262 Specific Techniques and Measures for FPGA Design Design Entry Structured Description Design Description in HDL Schematic Entry Design Description using Boolean Equations Modularization Application of a Proven in Use Design Environment HDL Simulation Functional Test on Module Level Functional Test on Top Level Restricted use of Asynchronous Constructs Synchronization of Primary Inputs and Control of Metastability Functional and Structural coverage-driven Verification Observation of Coding Guidelines Application of Code Checker Code Inspection or Walkthrough Application of Validated Soft Cores Validation of Soft IP Cores Documentation of Simulation Results Synthesis

4 TOC-4 Cyclone V SoCs Automotive Safety Manual Internal Consistency Checks Gate Netlist Simulation Static Timing Analysis (STA) of the Propagation Delay Verification of the Gate Netlist Against a Model by Simulation Comparison of Gate Netlist with Model (Formal Equivalence Check) IC Vendor Requirements and Constraints Check Documentation of Synthesis Constraints, Results and Tools Application of Proven in Use Synthesis Application of Proven in Use Libraries/CPLD Technologies Script -based Procedures Adequate Time Margins Test Insertion and Test Pattern Generation Design for Testability Placement, Routing, Layout Generation Justification of Proven in Use for Applied Hard Cores Application of Validated Hard Cores Gate Netlist Simulation after Layout Analysis of Power Network Comparison of the Gate Netlist after Layout with the Model Design Rule Check Layout Versus Schematic (LVS) Check Safety-related Special Characteristics during Chip Production Application of a Proven in Use Process Technology Application of a Proven in Use Device-Series Application of a Proven in Use Production Process Quality Control of the Production Process Final Verification and Validation of the FPGA Prototype in the System Final Verification and Validation During Mass Production Known Problems in the Altera Tools and Software Development Interface Agreement Safety Manager The Safety Lifecycle Activities Performed by Altera and Customer Responsibilities Information Provided by Altera Responsible Parties for Activities Communication of Target Values Supporting Processes and Tools Software Development with the Nios II Processor Using Qsys to Create a Nios II System Creating a Board Support Package for your Nios II System Creating an Application Framework Developing Application Software Integrating Software and Hardware

5 Cyclone V SoCs Automotive Safety Manual TOC-5 Tools and Libraries included in the ISO26262 Qualification Third-party Tools and Libraries Excluded in the ISO26262 Qualification Supported (V)HDL versions

6 Introduction to Cyclone V SoCs and Safety 1 MNL-1079 Subscribe The Cyclone V SoC device family includes a user programmable FPGA fabric and a Hard Processor System (HPS) with parts you commonly find in microprocessors and microcontrollers as hardened macros. This application note provides information for implementing safety critical systems, to allow you to meet ISO26262: compliance on the item level. TÜV Rheinland successfully assessed previous generations of Altera FPGAs and tools to meet IEC61508:2010 requirements up to SIL3 level. This expertise and work carries over to meet ISO26262: Altera is an active member of the ISO26262 USTAG and participates in the ISO26262 semiconductor subgroup for clarifications of the standard with regard to semiconductors. Note: The user of Altera components, software, and tools must meet all regulatory and safety requirements. All information in this document is for reference only and cannot be held against Altera in any damages, claims, suites or expenses resulting from use of the Altera components in a safety critical system. Cyclone V SoC Overview Cyclone V SoC is the fifth generation of Cyclone products and now includes the HPS and user programmable logic fabric. The devices are manufactured in a 28nm low power process. Devices in the family differ mainly in the amount of available logic element (LE) in the FPGA fabric. The HPS is identical between all members of the family All rights reserved. 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. All other words and logos identified as trademarks or service marks are the property of their respective holders as described at Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera 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 Altera. 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. ISO 9001:2008 Registered Innovation Drive, San Jose, CA 95134

7 1-2 Targeted Applications Figure 1-1: Block Diagram of Cyclone V SoCs MNL-1079 Configuration Controller FPGA-to-HPS HPS-to-FPGA Lightweight HPS-to-FPGA FPGA Fabric FPGA-to-HPS SDRAM FPGA Manager HPS Ethernet MAC (2x) USB OTG (2x) NAND Flash Controller SD/MMC/SDIO Controller DMA Controller Level 3 Interconnect 64 KB Boot ROM CPU0 (ARM Cortex-A9 with NEON/FPU, 32 KB Instruction Cache, 32 KB Data Cache, and Memory Management Unit) ACP ARM Cortex-A9 MPCore CPU1 (ARM Cortex-A9 with NEON/FPU, 32 KB Instruction Cache, 32 KB Data Cache, and Memory Management Unit) SCU L2 Cache (512 KB) Multiport DDR SDRAM Controller with Optional ECC ETR (Trace) Debug Access Port 64 KB On-Chip RAM Low Speed Peripherals (Timers, GPIOs, UART, SPI, I2C, CAN, Quad SPI Flash Controller, System Manager, Clock Manager, Reset Manager, and Scan Manager) The microprocessor unit (MPU) subsystem integrates two ARM Cortex -A9 processors with each of its own L1 instruction and data caches. Both processors connect to a L2 Cache that fetches instructions and data via the L3 Interconnect or directly from the DDR SDRAM controller. The MPU subsystem snoops any transaction from other masters in the system via the accelerator coherency port (ACP) to ensure that the processors use the latest data. You can store data in the on-chip RAM connected to the L3 interconnect. The L3 interconnect allows flexible multimaster (e.g. MPU, direct memory access controller (DMAC), or EMAC) access to slave modules (e.g. UART, Timer, or I2C). Transfers can be concurrent when you access different slave modules. You can exchange data between the HPS and the FPGA fabric via the FPGA-to-HPS (F2H), HPS-to-FPGA (H2F) and lightweight HPS-to-PGA (LH2F) bridges. Targeted Applications The Altera Cyclone V SoCs meet a wide variety of application requirements including use in safety critical applications in the industrial and automotive sector, which may include: Advanced driver assistance systems Motor control and DC-DC converters for hybrid electric vehicles and electric vehicles Infotainment systems Introduction to Cyclone V SoCs and Safety

8 MNL-1079 Targeted Applications 1-3 Altera used a safety element out of context (SEooC) approach for the development of Cyclone V SoCs. FPGAs provide an immense flexibility to integrate application and user specific logic IP that shifts some responsibilities to the user compared to using standard components (e.g. microcontroller). You cannot achieve functional safety for ISO26262: solely on the component level, but it is as a function of the overall safety concept of the item. Altera s Cyclone V SoC products simplify and enable the achievement of a targeted ASIL level for the item. Introduction to Cyclone V SoCs and Safety

9 Systematic Fault Management 2 MNL-1079 Subscribe To minimize the risk of faults in the item or element, reduce the potential for systematic faults. A robust development flow allows you to achieve this goal. This topic describes the structure of the Altera internal flow and also provides an example user flow to meet the ISO26262 requirements. Altera Development Flow Altera is successfully certified to I.S. EN ISO9001:2008 (certificate: NAIS ). 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 IEC61508:2010 up to SIL3 since 2010, with the most recent certification in 2012 (No.: 968/EL /12) All rights reserved. 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. All other words and logos identified as trademarks or service marks are the property of their respective holders as described at Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera 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 Altera. 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. ISO 9001:2008 Registered Innovation Drive, San Jose, CA 95134

10 2-2 Discovery Phase Figure 2-1: Altera Development Flow MNL-1079 The figure shows the Altera development flow, which is split into seven phases. 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. Systematic Fault Management

11 MNL-1079 Concept Phase 2-3 Concept Phase Plan Phase In the concept phase, Altera defines a solution to address specific markets and Altera creates a plan for the next 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. The following section describes a V-model flow, which you can use to create IP cores and circuits. TÜV Rheinland assesses this flow according to the IEC61508:2010 requirements. TÜV Rheinland deems it suitable for use for the design of safety critical circuits. Altera amended the flow with specific ISO26262: requirements. Systematic Fault Management

12 2-4 User Development Flow Figure 2-2: User V-Model Development Flow MNL-1079 Specify F P G A R equ iremen ts Generate F P G A A rch itec ture Plan T es ts Va lida te Design Log ica l Modu le D es ign Generate B its tream Create Design Description Create T es t P la n T es t Perform FMEDA Perform G a te -Leve l S imu la tion C od e Inject Faults Log ica l Modu le I nteg ra tion Create Design Description Create T es t P la n T es t Perform S ta tic Ti ming Analysis C od e Perform Syn thes is Perform P lace 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

13 MNL-1079 Specify FPGA Requirements 2-5 Specify 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. The FPGA requirements specification may include: High-level functional requirements Subsystem performance 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, separation). No specific Altera process or tool is applicable for this V-model step. Inputs: Item requirements specification Safety concept Outputs: Detailed FPGA requirements specification Verification report Verification: Procedural crosscheck of detailed FPGA requirements specification against input documents. For example, using numbered items. Peer review detailed FPGA requirements specification Suggested tools: Requirement management tool (e.g. IBM DOORS or TechnoSolutions TopTeam) 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. Generating FPGA Architecture In this step: 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. Systematic Fault Management

14 2-6 Generating FPGA Architecture Take the overall FPGA system requirements and partition the required functionality into submodules. You should separately define and bound each of these submodules to allow you to develop and test them in isolation. You can specify any third-party IP cores or standard interface. 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 Nios II embedded soft processor Standard internal interfaces (for example Avalon memory-mapped (Avalon-MM) or Avalon streaming (Avalon-ST) interfaces Inputs: Item safety requirements specification (Item SRS) FPGA requirements specification FPGA safety requirements specification (FPGA SRS) Errata and known issues 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. For example, using numbered items. 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 MNL-1079 For detailed requirements about the hardware architectural design, refer to ISO :2011 clause Systematic Fault Management

15 MNL-1079 Creating Design Description for Logical Module Design 2-7 For more information, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 1: Design and Synthesis Section I: Design Flows Chapter 2: Design Planning with the Quartus II Software Related Information on page 5-1 Creating 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 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. 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 No specific Altera process or tool is applicable for this V-model step. Inputs: FPGA architecture document Detail module requirements specification Outputs: Detailed design description document Module-level behavioral model Verification report Verification: Procedural crosscheck of input specification with output design document. For example, numbered items. 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 Systematic Fault Management

16 2-8 Creating Test Description for Logical Module Design For detailed requirements about the hardware detailed design, refer to ISO :2011 clause Creating Test Description for Logical Module Design 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. Inputs: Item requirements specification (for overall safety requirements) FPGA requirements specification (for FPGA level requirements) Logical module design functional description Outputs: Logical module design test description Verification report Verification: Cross check of testable items from design document to numbered tests in test description 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 Coding Logical Module Design 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. 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 ( ISO26262 Specific Techniques and Measures for FPGA Design on page 4-1) to assess the suitability of each design entry method. The references in ISO26262 describe details of how you can use Altera tools to implement these techniques and measures. MNL-1079 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. Systematic Fault Management

17 MNL-1079 Testing Logical Module Design 2-9 Inputs: Logical module design functional description Outputs: Synthesizable design files (usually (V)HDL) Verification: Use of lint tool (if applicable) Code inspection or walkthrough Simulation Suggested tools: Standard text editor Quartus II analysis and elaboration Specific techniques and measures: Refer to Structured Description on page 4-1 Refer to Design Description in HDL on page 4-1 Refer to Restricted use of Asynchronous Constructs on page 4-6 Refer to Code Inspection or Walkthrough on page 4-9 For more information, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 1: Design and Synthesis Section I: Design Flows Chapter 1: Managing Quartus II Projects For more information about analysis and elaboration, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 1: Design and Synthesis Section IV: Synthesis Chapter 17: Quartus II Integrated Synthesis Related Information on page 4-1 Testing Logical Module Design 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 Systematic Fault Management

18 2-10 Testing Logical Module Design 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. ISO26262: defines requirements for establishing a tool confidence level (ISO :2011 clause 11). For example, increased confidence from use. 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. 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. Inputs: 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 4-4 Refer to Functional Test on Module Level on page 4-5 Refer to Functional and Structural coverage-driven Verification on page 4-7 Refer to Documentation of Simulation Results on page 4-12 Refer to Application of Proven in Use Libraries/CPLD Technologies on page 4-18 MNL-1079 Systematic Fault Management

19 MNL-1079 Injecting Faults Logical Module Design 2-11 For more information, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification Section I: Simulation Chapter 1: Simulating Altera Designs For more information about Tcl scripting, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 2: Design Implementation and Optimization Section I: Scripting and Constraint Entry Chapter 3: Tcl Scripting Injecting Faults Logical Module Design 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. Inputs: 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: Refer to HDL Simulation on page 4-4 Refer to Documentation of Simulation Results on page 4-12 Refer to Application of Proven in Use Libraries/CPLD Technologies on page 4-18 Refer to Testing Logical Module Integration on page 2-13 For more information, refer to: ISO :2011, Section ISO :2011, Section Performing FMEDA 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

20 2-12 Creating Design Description for Logical Module Integration and diagnostic analysis, (FMEDA). You should refine the FMEDA during the product development cycle with the most accurate information. Inputs: Failure modes Failure mode distribution Failure rate of circuit Diagnostic coverage of diagnostic measure Outputs: FMEDA Verification: Peer review of results Suggested tools: Altera FMEDA Spreadsheet Specific techniques and measures: Not applicable Creating Design Description for Logical Module Integration In this step, use the same techniques as Creating 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. Related Information Creating Design Description for Logical Module Design on page 2-7 Creating Test Description for Logical Module Integration In this step, use the same techniques as the Creating Test Description for Logical Module Design on page 2-8, except that testing is specified for higher level blocks or subsystems. You can target this test description at full-chip testing. Related Information on page 2-8 Coding Logical Module Integration 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 and the Nios II processor. Inputs: Module design files Logical Module Design Functional Description FPGA Architecture MNL-1079 Systematic Fault Management

21 MNL-1079 Testing Logical Module Integration 2-13 Outputs: Chip level or subsystem level design files Verification: Analyze report file output for automated steps (also applies to the Nios II software build tools) Check for VHDL source files time and date stamp (also applies to the output from the Nios II software build tools) Inspect Qsys generated hierarchy (when used) Suggested tools: Standard text editor Quartus II Qsys Specific techniques and measures: Refer to Modularization on page 4-3 Refer to Application of Validated Soft Cores on page 4-9 Refer to Validation of Soft IP Cores on page 4-11 Testing Logical Module Integration In this step, use the same techniques as the module-level V-model step. However, the verification focus is on higher level blocks or perhaps on full chip testing. Inputs: 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 Cadence: NCSIM Synopsys: VCS Altera simulation libraries (optional) Systematic Fault Management

22 2-14 Performing Synthesis Specific techniques and measures: Refer to HDL Simulation on page 4-4 Refer to Functional Test on Module Level on page 4-5 Refer to Functional and Structural coverage-driven Verification on page 4-7 Refer to Documentation of Simulation Results on page 4-12 Refer to Application of Proven in Use Libraries/CPLD Technologies on page 4-18 For more information, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification MNL-1079 Related Information on page 2-9 Performing Synthesis 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. Inputs: 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). Outputs: Post synthesis database (internal tool files) 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 Systematic Fault Management

23 MNL-1079 Performing Place and Route 2-15 Specific techniques and measures: Refer to Internal Consistency Checks on page 4-12 Refer to Documentation of Synthesis Constraints, Results and Tools on page 4-16 Refer to Application of Proven in Use Synthesis on page 4-17 Refer to Application of Proven in Use Libraries/CPLD Technologies on page 4-18 Refer to Script -based Procedures on page 4-19 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 v13.0: Volume 1: Design and Synthesis Section IV: Synthesis Related Information on page 8-1 Performing Place and Route 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. Inputs: Post synthesis database Project constraints for example target family/device Timing constraints (optional, for timing driven place and route) 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 Justification of Proven in Use for Applied Hard Cores on page 4-23 Refer to Application of Validated Hard Cores on page 4-24 Systematic Fault Management

24 2-16 Performing Static Timing Analysis For more information, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 2: Design Implementation and Optimization Section III: Area, Timing, Power, and Compilation Time Optimization Chapter 12: Timing Closure and Optimization Chapter 14: Area Optimization MNL-1079 Performing Static Timing Analysis 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. Inputs: Timing constraints FPGA architecture FPGA requirements specification Device timing model Post place and route netlist Outputs: Timing report files 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 Suggested tools: Quartus II TimeQuest Timing Analyzer Specific techniques and measures: Refer to Documentation of Synthesis Constraints, Results and Tools on page 4-16 Refer to Static Timing Analysis (STA) of the Propagation Delay on page 4-13 Refer to Adequate Time Margins on page 4-19 Systematic Fault Management

25 MNL-1079 Performing Gate-Level Simulation 2-17 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 4-19 Performing Gate-Level Simulation 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 Testing Logical Module Design on page 2-9 and Testing Logical Module Integration 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. A timing accurate gate-level simulation is identical to a regular gate-level simulation, except that you provide all relevant timing information to the logic simulator. This process may show timing violations within the design. You may perform this step in addition to a functional gate-level simulation or it may replace this step. Refer to Adequate Time Margins on page 4-19 for the specific requirement to modify timing constraints when using device families for which the process technology is in use less than three years. Inputs: 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 Suggested tools: Third-party simulator tool, which are not within the scope of this document: Mentor ModelSim Cadence NCSIM Synopsys VCS Altera simulation libraries Systematic Fault Management

26 2-18 Generating Bitstream Specific techniques and measures: Application of Proven in Use Libraries/CPLD Technologies on page 4-18 Verification of the Gate Netlist Against a Model by Simulation on page 4-14 Comparison of Gate Netlist with Model (Formal Equivalence Check) on page 4-15 Related Information Testing Logical Module Design on page 2-9 Testing Logical Module Integration on page 2-13 Generating Bitstream In this step, you generate the programming file (also known as bitstream generation). Perform this step before you can program a device with the compiled design. The assembler in the Quartus II software takes the final netlist and generates a programming sequence that sets the FPGA logic cells to the desired function. The Quartus II software often performs this step automatically. You have several options when using the assembler for generating bitstream and storage. Inputs: Post place and route netlist FPGA requirements specification (contains bitstream storage approach) Outputs: Device programming file (.sof,.pof,.hex, and so on) Verification: Review of tool generated report files Hardware check Check programming files time and date stamp Suggested tools: Quartus II Assembler Specific techniques and measures: None For more information about the assembler, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification Section VI: Device Programming Chapter 18: Quartus II Programmer Validating the Design MNL-1079 In this step, validate the final design in hardware. You should take the bitstream that the programming file generation stage generates and use a suitable technique to apply this file to the device in hardware. After this step, you should validate the device functionality by whatever means the Test Description document specifies. Systematic Fault Management

27 MNL-1079 Altera Tools 2-19 If this validation is not successful, Altera provides various in-system debugging tools that may help debugging: SignalTap II logic analyzer Nios II Debugger Quartus II PowerPlay power analyzer Quartus II In-System Memory Editor You should use these techniques and tools for debugging only, and you should not apply them in the final system. Inputs: Device programming file (.sof,.pof,.hex, and so on) Outputs: Hardware test results (document) Verification: SignalTap II logic analyzer: Check fitter report file for inclusion of debugging IP core Check SignalTap II logic analyzer for valid results Nios II debugger: Check debugging tool for valid results Use the SignalTap II logic analyzer to check debugger or memory editor consistency Use hardware verification to ensure that debug tools give correct output Quartus II PowerPlay Analyzer: Manually check for valid results Check database consistency (time and date stamp) Check report file time and date stamp and inclusion of modules Monitor hardware power consumption Peer review of test results Check fitter report file for inclusion of debugging IP core Check debugging tool for valid results Use SignalTap II logic analyzer to check debugger or memory editor consistency Use hardware verification to ensure that debug tools give correct output Suggested tools: SignalTap II logic analyzer Nios II Debugger Quartus II PowerPlay power analyzer Quartus II In-System Memory Editor Specific techniques and measures: Final Verification and Validation During Mass Production on page 4-29 Altera Tools Altera provides various tools that you can use in the V-model steps. Systematic Fault Management

28 2-20 Qsys Qsys The Qsys code generation tool has specific requirements within ISO26262: Refer to ISO :2011 clause 10 for more details. Qsys provides a graphical representation of the connectivity between generated modules and Altera standard IP cores. The connectivity between these blocks uses the following Altera bus protocols: The Avalon-MM interface. The Avalon-ST interface. After you specify the connectivity between the submodules and IP cores, a code generation stage is performed. This stage takes the graphical representation of the connections and generates a (V)HDL description of the module instances and connectivity including arbitration logic, bridges, and so on. You can then include this (V)HDL file within the design in the same way as manually coded (V)HDL. For more information about Qsys, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 1: Design and Synthesis Section II: System Design with Qsys SignalTap II Logic Analyzer The Altera SignalTap II Logic Analyzer captures and displays real-time signal transitions within the FPGA. In short, you specify which nodes within the device are of interest. The Quartus II compiler connects these nodes to a SignalTap II block that it also instantiates within the device. During operation, the SignalTap block captures the signal transitions into on-chip memory based on certain trigger conditions. The SignalTap II Logic Analyzer then transfers the contents of this memory to a host computer, via JTAG and presents them in a graphical format. Do not use the SignalTap II Logic Analyzer when the safety application is "online" when the design is responsible for functional safety. For more information about the SignalTap II Logic Analyzer, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification Section IV: System Debugging Tools Chapter 13: Design Debugging Using the SignalTap II Logic Analyzer Nios II Debugger The Nios II software debugger allows a host computer to connect to a Nios II processor within the FPGA using a JTAG interface. Use the debugger for standard software debug techniques such as break pointing, STD out reporting, and so on. Do not use the Nios II debugger when the safety application is "online" when the design is responsible for functional safety. For more information about the Nios II debugger, refer to the Nios II Software Developer s Handbook. MNL-1079 Systematic Fault Management

29 MNL-1079 Quartus II In-System Memory Editor 2-21 Quartus II In-System Memory Editor The Quartus II In-System Memory Editor allows read back and modification of on-chip memory contents from a host computer. Connect this host computer to the device using a JTAG connection. This tool is useful for analyzing memory contents during run-time operation of the design. You can only access the on-chip memories if you configure them at design time to allow this in-system feature. Do not use the In-system memory editor when the safety application is "online when the design is responsible for functional safety. For more information about the In-System Memory Editor, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification Section IV: System Debugging Tools Chapter 15: In-System Modification of Memory and Constants Quartus II PowerPlay Power Analyzer The Quartus II PowerPlay power analyzer tool allows you to estimate power consumption from early design concept through design implementation. To gain preliminary results, you input information about environmental conditions and the number of device resources (such as clocks, DSP blocks) that you expect to use in the design. When your design is partially complete, the Quartus II software can generate a PowerPlay early power estimator file, which provides a more accurate estimation of device power consumption. For more information about the PowerPlay power analyzer, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 3: Verification Section III: Power Estimation and Analysis Chapter 8: PowerPlay Power Analysis Altera IP Cores It may be appropriate for you to implement various functions of the design by using Altera IP cores. Altera offers the following two types of IP core: Megafunctions MegaCore functions An Altera megafunction is typically a low-level hard IP function, for example a PLL. Many of these functions are user-configurable. Altera commonly provides a GUI for configuring these IP cores, which produces a text-based configuration file. An Altera MegaCore function is typically a high-level function that you implement in general purpose resources in the FPGA. For example, a DDR SDRAM controller or an Ethernet MAC. For more information about IP cores, refer to the following topics in the Quartus II Software Handbook v13.0: Volume 1: Design and Synthesis Section I: Design Flows Chapter 2: Design Planning with the Quartus II Software Systematic Fault Management