Post on 28-Apr-2018
Cyclone V SoCsAutomotive Safety Manual
Subscribe
Send Feedback
MNL-10792013.11.19
101 Innovation DriveSan Jose, CA 95134www.altera.com
Contents
Introduction to Cyclone V SoCs and Safety....................................................... 1-1Cyclone V SoC Overview............................................................................................................................1-1Targeted Applications................................................................................................................................. 1-2
Systematic Fault Management............................................................................ 2-1Altera Development Flow........................................................................................................................... 2-1
Discovery Phase................................................................................................................................2-2Concept Phase.................................................................................................................................. 2-3Plan Phase......................................................................................................................................... 2-3Design Phase.....................................................................................................................................2-3Rollout Phase.................................................................................................................................... 2-3Production Phase............................................................................................................................. 2-3End-of-Life Phase.............................................................................................................................2-3
User Development Flow..............................................................................................................................2-3Specify FPGA Requirements.......................................................................................................... 2-5Generating FPGA Architecture..................................................................................................... 2-5Creating Design Description for Logical Module Design.......................................................... 2-7Creating Test Description for Logical Module Design...............................................................2-8Coding Logical Module Design......................................................................................................2-8Testing Logical Module Design..................................................................................................... 2-9Injecting Faults Logical Module Design..................................................................................... 2-11Performing FMEDA...................................................................................................................... 2-11Creating Design Description for Logical Module Integration................................................ 2-12Creating Test Description for Logical Module Integration..................................................... 2-12Coding Logical Module Integration............................................................................................2-12Testing Logical Module Integration............................................................................................2-13Performing Synthesis.....................................................................................................................2-14Performing Place and Route.........................................................................................................2-15Performing Static Timing Analysis............................................................................................. 2-16Performing Gate-Level Simulation..............................................................................................2-17Generating Bitstream.................................................................................................................... 2-18Validating the Design....................................................................................................................2-18Altera Tools.....................................................................................................................................2-19Altera IP Cores............................................................................................................................... 2-21Nios II Processor............................................................................................................................2-22
Architecture for Random Hardware Fault Management...................................3-1Cyclone V SoC Hardware Architecture....................................................................................................3-1Diagnostic Mechanisms and Usage Assumptions...................................................................................3-3
Power Supply.................................................................................................................................... 3-3Clock.................................................................................................................................................. 3-4
TOC-2 Cyclone V SoCs Automotive Safety Manual
Altera Corporation
Reset................................................................................................................................................... 3-9Input/Outputs................................................................................................................................ 3-11FPGA Configuration..................................................................................................................... 3-13FPGA User Memory......................................................................................................................3-15HPS Interconnect...........................................................................................................................3-16HPS to FPGA interconnect...........................................................................................................3-18HPS Cortex-A9 MPU Subsystem................................................................................................ 3-20HPS Debug and Trace................................................................................................................... 3-29HPS SDRAM Controller............................................................................................................... 3-31HPS On-Chip RAM.......................................................................................................................3-33HPS On-Chip Boot ROM............................................................................................................. 3-35HPS NAND Flash Controller.......................................................................................................3-36HPS SD/MMC Controller............................................................................................................ 3-38HPS Quad SPI Flash Controller...................................................................................................3-39HPS FPGA Manager......................................................................................................................3-41HPS System Manager.................................................................................................................... 3-42HPS Scan Manager........................................................................................................................ 3-43HPS DMAC.................................................................................................................................... 3-45HPS Ethernet Media Access Controller......................................................................................3-47HPS USB 2.0 OTG Controller......................................................................................................3-50HPS SPI Controller........................................................................................................................3-52HPS I2C Controller....................................................................................................................... 3-54UART Controller........................................................................................................................... 3-55HPS Timer...................................................................................................................................... 3-57HPS Watchdog Timer................................................................................................................... 3-58HPS CAN Controller.....................................................................................................................3-60
ISO26262 Specific Techniques and Measures for FPGA Design....................... 4-1Design Entry................................................................................................................................................. 4-1
Structured Description....................................................................................................................4-1Design Description in HDL............................................................................................................4-1Schematic Entry................................................................................................................................4-2Design Description using Boolean Equations..............................................................................4-3Modularization.................................................................................................................................4-3Application of a Proven in Use Design Environment................................................................ 4-4HDL Simulation............................................................................................................................... 4-4Functional Test on Module Level.................................................................................................. 4-5Functional Test on Top Level.........................................................................................................4-5Restricted use of Asynchronous Constructs................................................................................ 4-6Synchronization of Primary Inputs and Control of Metastability............................................ 4-7Functional and Structural coverage-driven Verification............................................................4-7Observation of Coding Guidelines................................................................................................ 4-8Application of Code Checker......................................................................................................... 4-8Code Inspection or Walkthrough..................................................................................................4-9Application of Validated Soft Cores..............................................................................................4-9Validation of Soft IP Cores...........................................................................................................4-11Documentation of Simulation Results........................................................................................4-12
Synthesis......................................................................................................................................................4-12
Cyclone V SoCs Automotive Safety Manual TOC-3
Altera Corporation
Internal Consistency Checks........................................................................................................ 4-12Gate Netlist Simulation................................................................................................................. 4-13Static Timing Analysis (STA) of the Propagation Delay .........................................................4-13Verification of the Gate Netlist Against a Reference Model by Simulation.......................... 4-14Comparison of Gate Netlist with Reference Model (Formal Equivalence Check)...............4-15IC Vendor Requirements and Constraints Check.................................................................... 4-15Documentation of Synthesis Constraints, Results and Tools..................................................4-16Application of Proven in Use Synthesis......................................................................................4-17Application of Proven in Use Libraries/CPLD Technologies..................................................4-18Script -based Procedures...............................................................................................................4-19Adequate Time Margins............................................................................................................... 4-19
Test Insertion and Test Pattern Generation...........................................................................................4-22Design for Testability.................................................................................................................... 4-22
Placement, Routing, Layout Generation................................................................................................ 4-23Justification of Proven in Use for Applied Hard Cores............................................................4-23Application of Validated Hard Cores......................................................................................... 4-24Gate Netlist Simulation after Layout...........................................................................................4-24Analysis of Power Network.......................................................................................................... 4-25Comparison of the Gate Netlist after Layout with the Reference Model...............................4-25Design Rule Check.........................................................................................................................4-26Layout Versus Schematic (LVS) Check...................................................................................... 4-26
Safety-related Special Characteristics during Chip Production.......................................................... 4-27Application of a Proven in Use Process Technology................................................................ 4-27Application of a Proven in Use Device-Series........................................................................... 4-27Application of a Proven in Use Production Process.................................................................4-28Quality Control of the Production Process................................................................................ 4-28Final Verification and Validation of the FPGA Prototype in the System..............................4-29Final Verification and Validation During Mass Production................................................... 4-29
Known Problems in the Altera Tools and Software........................................... 5-1
Development Interface Agreement.....................................................................6-1Safety Manager............................................................................................................................................. 6-1The Safety Lifecycle......................................................................................................................................6-1Activities Performed by Altera and Customer Responsibilities............................................................ 6-2Information Provided by Altera................................................................................................................ 6-3Responsible Parties for Activities...............................................................................................................6-4Communication of Target Values............................................................................................................. 6-4Supporting Processes and Tools................................................................................................................ 6-4
Software Development with the Nios II Processor.............................................7-1Using Qsys to Create a Nios II System......................................................................................................7-1Creating a Board Support Package for your Nios II System..................................................................7-1Creating an Application Framework.........................................................................................................7-2Developing Application Software..............................................................................................................7-2Integrating Software and Hardware.......................................................................................................... 7-3
TOC-4 Cyclone V SoCs Automotive Safety Manual
Altera Corporation
Tools and Libraries included in the ISO26262 Qualification................................................................ 7-3Third-party Tools and Libraries Excluded in the ISO26262 Qualification......................................... 7-4
Supported (V)HDL versions............................................................................... 8-1
Cyclone V SoCs Automotive Safety Manual TOC-5
Altera Corporation
Introduction to Cyclone V SoCs and Safety 12013.11.19
MNL-1079 Subscribe Send Feedback
The Cyclone V SoC device family includes a user programmable FPGA fabric and a Hard ProcessorSystem (HPS) with parts you commonly find in microprocessors and microcontrollers as hardenedmacros.
This application note provides information for implementing safety critical systems, to allow you to meetISO26262:2011-2012 compliance on the item level.
TÜV Rheinland successfully assessed previous generations of Altera FPGAs and tools to meetIEC61508:2010 requirements up to SIL3 level. This expertise and work carries over to meetISO26262:2011-2012. Altera is an active member of the ISO26262 USTAG and participates in theISO26262 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 require‐ments. All information in this document is for reference only and cannot be held against Altera inany damages, claims, suites or expenses resulting from use of the Altera components in a safetycritical system.
Cyclone V SoC OverviewCyclone V SoC is the fifth generation of Cyclone products and now includes the HPS and user program‐mable logic fabric. The devices are manufactured in a 28nm low power process. Devices in the familydiffer mainly in the amount of available logic element (LE) in the FPGA fabric. The HPS is identicalbetween all members of the family.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
Figure 1-1: Block Diagram of Cyclone V SoCs
FPGA Fabric
HPS
HPS-to-FPGALightweight
HPS-to-FPGAFPGA-to-HPS FPGA-to-HPS SDRAMConfiguration
Controller
FPGAManager
64 KBOn-Chip
RAM
64 KBBootROM
Level 3Interconnect
EthernetMAC (2x)
USBOTG (2x)
NAND Flash Controller
SD/MMC/SDIO Controller
DMAController
ETR(Trace)
DebugAccess Port
ARM Cortex-A9 MPCore
CPU0(ARM Cortex-A9with NEON/FPU,
32 KB Instruction Cache,32 KB Data Cache, and
Memory Management Unit)
CPU1(ARM Cortex-A9with NEON/FPU,
32 KB Instruction Cache,32 KB Data Cache, and
Memory Management Unit)
SCUACP
L2 Cache (512 KB)
MultiportDDR SDRAM
Controllerwith
Optional ECC
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 itsown L1 instruction and data caches. Both processors connect to a L2 Cache that fetches instructions anddata via the L3 Interconnect or directly from the DDR SDRAM controller. The MPU subsystem snoopsany transaction from other masters in the system via the accelerator coherency port (ACP) to ensure thatthe processors use the latest data. You can store data in the on-chip RAM connected to the L3 intercon‐nect. 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 concurrentwhen you access different slave modules. You can exchange data between the HPS and the FPGA fabricvia the FPGA-to-HPS (F2H), HPS-to-FPGA (H2F) and lightweight HPS-to-PGA (LH2F) bridges.
Targeted ApplicationsThe Altera Cyclone V SoCs meet a wide variety of application requirements including use in safety criticalapplications 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
1-2 Targeted ApplicationsMNL-1079
2013.11.19
Altera Corporation Introduction to Cyclone V SoCs and Safety
Send Feedback
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 someresponsibilities to the user compared to using standard components (e.g. microcontroller).
You cannot achieve functional safety for ISO26262:2011-2012 solely on the component level, but it is as afunction of the overall safety concept of the item. Altera’s Cyclone V SoC products simplify and enable theachievement of a targeted ASIL level for the item.
MNL-10792013.11.19 Targeted Applications 1-3
Introduction to Cyclone V SoCs and Safety Altera Corporation
Send Feedback
Systematic Fault Management 22013.11.19
MNL-1079 Subscribe Send Feedback
To minimize the risk of faults in the item or element, reduce the potential for systematic faults. A robustdevelopment flow allows you to achieve this goal. This topic describes the structure of the Altera internalflow and also provides an example user flow to meet the ISO26262 requirements.
Altera Development FlowAltera is successfully certified to I.S. EN ISO9001:2008 (certificate: NAIS 19.1804). Altera develops itstools, devices and IP cores with this flow. TÜV Rheinland qualified this flow to be suitable for use inapplications requiring compliance to IEC61508:2010 up to SIL3 since 2010, with the most recent certifica‐tion in 2012 (No.: 968/EL 850.00/12).
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
Figure 2-1: Altera Development Flow
The figure shows the Altera development flow, which is split into seven phases.
Discovery
Review?no
yes
Concept
Review?no
yes
Plan
Review?no
yes
Design
Review?no
yes
Rollout
Review?no
yes
Production
Review?no
yes
End of Life
Review?
no
At the end of each phase Altera completes a review of the entire phase with a decision to proceed to thenext phase.
Discovery PhaseIn the discovery phase, Altera assesses market opportunities and a potential fit for Altera devices.
2-2 Discovery PhaseMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
Concept PhaseIn the concept phase, Altera defines a solution to address specific markets and Altera creates a plan for thenext phase.
Plan PhaseIn the plan phase, Altera develops a project plan with inputs from various functional groups. Alteraperforms feasibility studies and creates high-level specifications.
Design PhaseIn the design phase, Altera refines the high-level specification to a detailed specification, which it uses toimplement the product. Altera creates test plans and verifies that the design meets the detailed specifica‐tion.
Rollout PhaseIn the rollout phase, Altera validates and qualifies the product, if it is a device. Altera identifies and notesanomalies and potentially fixes them.
Production PhaseIn the production phase, Altera creates production ready devices, tools, and IP cores. Customers can usethe Altera deliverables for production.
End-of-Life PhaseIn the end-of-life phase, Altera informs customers that at the end of the product's life Altera will take theproduct off the market. Customers can, during a defined time period, change to a newer Altera product.
User Development FlowAltera products allow hardware programmability. You design your own circuit and program it to theFPGA. You may have to perform many design steps that normally the silicon provider performs. Thefollowing section describes a V-model flow, which you can use to create IP cores and circuits. TÜVRheinland assesses this flow according to the IEC61508:2010 requirements. TÜV Rheinland deems itsuitable for use for the design of safety critical circuits. Altera amended the flow with specificISO26262:2011-2012 requirements.
MNL-10792013.11.19 Concept Phase 2-3
Systematic Fault Management Altera Corporation
Send Feedback
Figure 2-2: User V-Model Development Flow
Create DesignDescription
GenerateF P G A A rch itec ture
Specify F P G A R equ iremen ts
CreateT es t P la n
C od e
T es t
PerformSyn thes is
PerformP lace and Route
PerformS ta tic Ti ming Analysis
PerformG a te -Leve l S imu la tion
GenerateB its tream
Va lida te Design
Log ica l Modu le D es ign
Log ica l Modu le I nteg ra tion
Plan T es ts
PerformFMEDA
InjectFaults
Create DesignDescription
CreateT es t P la n
C od e
T es t
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 mustassess the tool output to aid verification. You should assess tool generated, errors, warnings or reportfiles.
• Suggested tools. You may use this list of software tools to implement the particular V-model step. Insome 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 toeach step. Later topics in this document describe Altera specific information that describes how youcan satisfy these techniques and measures.
Note: You should provide methods for requirements traceability through your development. Alteraassumes this process as part of the overall safety requirements specification and each V-model stepdoes not explicitly mention it.
2-4 User Development FlowMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
Specify FPGA RequirementsIn this step, specify the gross functionality of the FPGA subsystem. The description details the high-levelspecification items and overall device functionality. You analyze the high-level system requirements andderive 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. Forexample, 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 ISO26262-8:2011clause 6 and in ISO26262-5:2011 clause 6.
Generating FPGA ArchitectureIn 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 externalinterfaces.
3. Typically, generate a block diagram showing the major blocks and their interconnections.
MNL-10792013.11.19 Specify FPGA Requirements 2-5
Systematic Fault Management Altera Corporation
Send Feedback
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 themin 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 safetydesigns.
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, usingnumbered 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
For detailed requirements about the hardware architectural design, refer to ISO26262 -5:2011 clause 7.4.1.
2-6 Generating FPGA ArchitectureMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
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 DesignIn this step, create a description for the design phase of each module that the FPGA architecture stepspecifies. In a document describe the methods of achieving the module requirements. This document maybe at the level of specifying state machine functions, mathematical functions, detailed module I/Odefinitions. It may be desirable to model the behavior of a module to allow you to verify the FPGAarchitecture and to allow a method of checking the final module implementation. You can implement thismodel 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 fullyimplement each module, including diagnostics, within an FPGA device.
Clearly define the function, performance, and safety relevance of each module. Also clearly define theperformance 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, numbereditems.
• 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
MNL-10792013.11.19 Creating Design Description for Logical Module Design 2-7
Systematic Fault Management Altera Corporation
Send Feedback
For detailed requirements about the hardware detailed design, refer to ISO26262-5:2011 clause 7.4.2.
Creating Test Description for Logical Module DesignThis V-model step involves taking a module-level functional description and generating a test specifica‐tion or test description. If run, the test description should give sufficient test coverage to satisfy therequirements of the design. The overall system safety requirements and target ASIL drive the require‐ments.
Analyze each specification point or functional requirement. Then describe specific tests to test for boththe correct functionality and possible fault conditions. Also develop tests that check the capability of thediagnostic 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 ISO26262-5:2011 clause 7.4.4.
Coding Logical Module DesignIn 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 astandard 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 forthe implementation of the design. You should refer to the large number of specific techniques andmeasures ( ISO26262 Specific Techniques and Measures for FPGA Design on page 4-1) to assess thesuitability of each design entry method. The references in ISO26262 describe details of how you can useAltera 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 softwareyou may use the analysis and elaboration function to check for correct language syntax and or elaborationerrors. Analysis and elaboration is the part of the Analysis and Synthesis process that checks your designfor correct source code syntax and connectivity.
2-8 Creating Test Description for Logical Module DesignMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
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 IISoftware 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 DesignIn this step, generate the design and run test code or testbenches. Translate each individual item from thepreviously 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 failstatus of the test should be easily accessible to you and the project managers. Many techniques areapplicable for this step and you should select those that are appropriate for your own safety-relateddesign.
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
MNL-10792013.11.19 Testing Logical Module Design 2-9
Systematic Fault Management Altera Corporation
Send Feedback
Use scripts to run tests during this step. To allow you to run tests with a high degree of reliability andrepeatability, Altera supports the Tcl scripting language that the EDA community widely supports anduses.
Carefully consider the selection of the third-party simulator. ISO26262:2011-2012 defines requirementsfor establishing a tool confidence level (ISO26262-8:2011 clause 11). For example, increased confidencefrom use.
Typically in this step, standard (V)HDL describes the design, therefore you only require a third-partysimulator that supports the chosen language. If the design contains instances of Altera IP cores, ensurethat you use the appropriate Altera simulation libraries. Altera provides these libraries with the Quartus IIsoftware. You must ensure that your simulation configuration targets the correct Altera libraries (from thespecific Quartus II software version that this document specifies).
You may choose to implement a methodology that uses the System Verilog HDL language for verificationpurposes. You should ensure that the tool and methodology you choose is appropriate for safety-relateddesign and verification.
In this step, you may synthesize your design and run the gate-level code through the same simulationtestbench. Altera recommends this step as it gives an early indication if the code produced synthesizesinto 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
2-10 Testing Logical Module DesignMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
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 SoftwareHandbook v13.0:
• Volume 2: Design Implementation and Optimization• Section I: Scripting and Constraint Entry• Chapter 3: Tcl Scripting
Injecting Faults Logical Module DesignThis step is optional and is only applicable if the module design incorporates any fault detectioncapability. In this step, analyze the diagnostic coverage of the implemented measure by injecting faultsinto 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 performfault injection testing at the integration of the module design to determine the diagnostic coverage of thehigher 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:
• ISO26262-5:2011, Section 7.4.4.1• ISO26262-5:2011, Section 10.4.5
Performing FMEDAIn this step, determine the diagnostic capability and evaluate the achieved metrics of the design. Youshould consider information about the failure modes, the failure mode distribution, the failure rates, andthe diagnostic coverage of any implemented diagnostic measure as an input to the failure mode, effects,
MNL-10792013.11.19 Injecting Faults Logical Module Design 2-11
Systematic Fault Management Altera Corporation
Send Feedback
and diagnostic analysis, (FMEDA). You should refine the FMEDA during the product development cyclewith 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 IntegrationIn this step, use the same techniques as Creating Design Description for Logical Module Design on page2-7, except that the abstraction level is at the module integration level. You can use the FPGA architecturedocument as a basis for describing the integration between each module.
Related InformationCreating Design Description for Logical Module Design on page 2-7
Creating Test Description for Logical Module IntegrationIn this step, use the same techniques as the Creating Test Description for Logical Module Design onpage 2-8, except that testing is specified for higher level blocks or subsystems. You can target this testdescription at full-chip testing.
Related Information
• on page 2-8
Coding Logical Module IntegrationIn this step, integrate the individual modules developed in previous stages. At this point, combine thesemodules together to create higher level functions and ultimately the top-level FPGA design. The QuartusII software includes a code generation tool (Qsys) that can simplify module integration particularly whenusing Altera IP cores and the Nios II processor.
Inputs:
• Module design files• Logical Module Design – Functional Description• FPGA Architecture
2-12 Creating Design Description for Logical Module IntegrationMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
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 IntegrationIn this step, use the same techniques as the module-level V-model step. However, the verification focus ison 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)
MNL-10792013.11.19 Testing Logical Module Integration 2-13
Systematic Fault Management Altera Corporation
Send Feedback
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
Related Information
• on page 2-9
Performing SynthesisIn this step, use an FPGA synthesis tool. The synthesis tool takes the input design files you specify andtranslates the logic functions into a format that the Quartus II software can implement within the logiccell structure of the target Altera FPGA. The Quartus II software includes the Quartus II IntegratedSynthesis, which is a high-performance synthesis tool that integrates with other parts of the developmentflow. 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 shouldensure that your design sources conform to these standards. Ideally, you specify the specific version of thelanguage 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 thedesign 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 constraintscontrol 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
2-14 Performing SynthesisMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
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 effectthey 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 RouteIn this step, take the result of the logic synthesis and create a netlist that includes the specific placement ofeach 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 routeprocess.
Altera developed the internal algorithms, which are complex in nature, over many versions of the QuartusII 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 thanjust 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-widelevel.
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
MNL-10792013.11.19 Performing Place and Route 2-15
Systematic Fault Management Altera Corporation
Send Feedback
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
Performing Static Timing AnalysisIn this step, perform static timing analysis, to gain accurate knowledge of the timing-related performanceof 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. TheFPGA 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 comprehen‐sive 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 andmanage them. Develop timing constraints early in the FPGA design cycle. The Quartus II software usestiming constraints during synthesis and fitting. For example the synthesis and place and route steps canuse 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
2-16 Performing Static Timing AnalysisMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
For more information about the specific requirement to modify timing constraints when using devicefamilies for which the process technology is in use less than three years, refer to Adequate Time Marginson page 4-19
Performing Gate-Level SimulationIn this step, validate the previous processes. Simulate the design with the netlist that is output from theplace and route step. As the tool can only generate this netlist by also performing logic synthesis, you alsotest the operation of the synthesis tool.
It is typical to re-use the simulation testbenches you generate in the Testing Logical Module Design onpage 2-9 and Testing Logical Module Integration on page 2-13. However, you may decide that yourdevelopment should apply additional testing at this stage. Describe this requirement in the FPGA Require‐ments Specification or FPGA Architecture documents.
A timing accurate gate-level simulation is identical to a regular gate-level simulation, except that youprovide all relevant timing information to the logic simulator. This process may show timing violationswithin 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 timingconstraints 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
MNL-10792013.11.19 Performing Gate-Level Simulation 2-17
Systematic Fault Management Altera Corporation
Send Feedback
Specific techniques and measures:
• Application of Proven in Use Libraries/CPLD Technologies on page 4-18• Verification of the Gate Netlist Against a Reference Model by Simulation on page 4-14• Comparison of Gate Netlist with Reference 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 BitstreamIn this step, you generate the programming file (also known as bitstream generation). Perform this stepbefore you can program a device with the compiled design. The assembler in the Quartus II software takesthe final netlist and generates a programming sequence that sets the FPGA logic cells to the desiredfunction. 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 SoftwareHandbook v13.0:
• Volume 3: Verification• Section VI: Device Programming• Chapter 18: Quartus II Programmer
Validating the DesignIn this step, validate the final design in hardware. You should take the bitstream that the programming filegeneration stage generates and use a suitable technique to apply this file to the device in hardware. Afterthis step, you should validate the device functionality by whatever means the Test Description documentspecifies.
2-18 Generating BitstreamMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
If this validation is not successful, Altera provides various in-system debugging tools that may helpdebugging:
• 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 finalsystem.
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 ToolsAltera provides various tools that you can use in the V-model steps.
MNL-10792013.11.19 Altera Tools 2-19
Systematic Fault Management Altera Corporation
Send Feedback
Qsys
The Qsys code generation tool has specific requirements within ISO26262:2011-2012. Refer toISO26262-8:2011 clause 10 for more details.
Qsys provides a graphical representation of the connectivity between generated modules and Alterastandard 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 isperformed. This stage takes the graphical representation of the connections and generates a (V)HDLdescription 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 Handbookv13.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 theFPGA. In short, you specify which nodes within the device are of interest. The Quartus II compilerconnects 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 triggerconditions. The SignalTap II Logic Analyzer then transfers the contents of this memory to a hostcomputer, 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 isresponsible for functional safety.
For more information about the SignalTap II Logic Analyzer, refer to the following topics in the QuartusII 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 FPGAusing 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 responsiblefor functional safety.
For more information about the Nios II debugger, refer to the Nios II Software Developer’s Handbook.
2-20 QsysMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
Quartus II In-System Memory Editor
The Quartus II In-System Memory Editor allows read back and modification of on-chip memory contentsfrom a host computer. Connect this host computer to the device using a JTAG connection. This tool isuseful for analyzing memory contents during run-time operation of the design. You can only access theon-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 isresponsible for functional safety.
For more information about the In-System Memory Editor, refer to the following topics in the Quartus IISoftware 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 earlydesign concept through design implementation. To gain preliminary results, you input information aboutenvironmental conditions and the number of device resources (such as clocks, DSP blocks) that youexpect to use in the design. When your design is partially complete, the Quartus II software can generate aPowerPlay early power estimator file, which provides a more accurate estimation of device powerconsumption.
For more information about the PowerPlay power analyzer, refer to the following topics in the Quartus IISoftware Handbook v13.0:
• Volume 3: Verification• Section III: Power Estimation and Analysis• Chapter 8: PowerPlay Power Analysis
Altera IP CoresIt 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 thesefunctions are user-configurable. Altera commonly provides a GUI for configuring these IP cores, whichproduces a text-based configuration file.
An Altera MegaCore function is typically a high-level function that you implement in general purposeresources 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 Handbookv13.0:
• Volume 1: Design and Synthesis• Section I: Design Flows• Chapter 2: Design Planning with the Quartus II Software
MNL-10792013.11.19 Quartus II In-System Memory Editor 2-21
Systematic Fault Management Altera Corporation
Send Feedback
Nios II ProcessorAltera provides the Nios II soft processor with the Quartus II software. The Nios II processor is a 32-bitreduced instruction set computer (RISC) processor.
When you implement the Nios II processor, it is constructed from general FPGA resources, which allowsmany user selectable configuration options.
Altera performs regression testing on the Nios II processor with each Quartus II release. This test data,and significant in-use experience, is evidence for the suitability of the Nios II processor core in safety-related designs. If you use the Nios II processor, ensure you provide sufficient diagnostic coverage withinyour Nios II based design. You typically implement this diagnostic coverage in software running on theNios II processor. You can use these routines to verify the correct operation of the firmware and hardwareof the processor. An example of such a routine is the calculation of a cyclic redundancy check (CRC) orsignature over the Nios II program code. The Nios II processor can run this operation in its own programcode if you use an appropriate system architecture. Refer to the ISO26262:2011-2012 for other diagnosticmeasures.
The Nios II processor runs user-designed software. Running safety related software means thatISO26262-6:2011 is also applicable.
This document contains guidance on the hardware inclusion and synthesis of the Nios II processor, butensure you design your safety-related software within the scope of ISO26262:2011-2012.
Related InformationGenerating FPGA Architecture on page 2-5
on page 2-5
on page 7-1
2-22 Nios II ProcessorMNL-1079
2013.11.19
Altera Corporation Systematic Fault Management
Send Feedback
Architecture for Random Hardware FaultManagement 3
2013.11.19
MNL-1079 Subscribe Send Feedback
In addition to the handling of systematic faults, you must also consider random hardware faults. Thistopic describes the Cyclone V SoC hardware architecture, the diagnostic mechanisms, and specificassumptions in using the device in an application.
Cyclone V SoC Hardware ArchitectureThe architecture of Cyclone V SoCs comprise diagnostic measures, which continuously operate, such asclock, power, memory, and other measures that you can use on demand during the application. Theapplication should ensure the proper operation of these mechanisms before using them during the safetycritical portion of running the application.
Figure 3-1: Cyclone V SoC High Level Block Diagram
The figure shows a high level block diagram of the Cyclone V SoC architecture and shows the HPS andthe FPGA, with dedicated interfaces between both.
Altera SoC FPGA Device
HPS Portion
FlashControllers
SDRAM ControllerSubsystem
Cortex-A9 MPU Subsystem
On-ChipMemories
SupportPeripherals
PLLs InterfacePeripherals
Debug
HPS-FPGAInterfaces
ControlBlock
UserI/O
HSSITransceivers
FPGA Fabric(LUTs, RAMs, Multipliers & Routing)
PLLs HardPCIe
Hard MemoryControllers
FPGA Portion
Both parts are virtually independent from each other with their own dedicated core power supplies, clock,and I/O structures with physical separation between the two parts. The HPS includes two Cortex-A9processors that can operate in a symmetric multiprocessing (SMP) and asymmetric multiprocessing
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
(AMP) configuration. You often use them as the main controller of the application. The FPGA provides,with its flexibility, options for you to implement your own hardware accelerators. You may also createcustom diagnostic functions to detect faults in the system or on chip.
Figure 3-2: Cyclone V SoC Detailed Block Diagram
The figure shows a more detailed block diagram of Cyclone V SoCs.
DAP
ETR
SD/MMC
EMAC(2)
USBOTG(2)
NANDFlash
CAN(2)
Timer(4)
WatchdogTimer
(2)
UART(2)
GPIO(3)
SPI(4)
ClockManager
ResetManager
I C(4)
ScanManager
SystemManager
L4, 32-Bit Bus
32-Bit
32-Bit
32-Bit
32-Bit
32-Bit
L3 Interconnect(NIC-301)
L3 MasterPeripheral
Switch 32-Bit
32-Bit
64-Bit
64-Bit
32-Bit
32-Bit
64-Bit
32-Bit
32-Bit32-Bit
32-Bit
32-Bit 64-Bit
L3 Slave Peripheral Switch
ACP
CPU0 CPU1
SCU
ARM Cortex-A9MPCore
MPU Subsystem
ACP IDMapper
SDRAMControllerSubsystem
STM
Boot ROM
On-Chip RAM
DMA
QuadSPI
Flash
FPGAManager
FPGA-to-HPSBridge
HPS-to-FPGABridge
LightweightHPS-to-FPGA Bridge
L4, 32-Bit Bus32-Bit AXI
2
32-Bit 64-Bit AXI 64-Bit AXI
L3 MainSwitch
FPGA Portion
ControlBlock
Masters Slaves Slaves
32-, 64-, 128-Bit AXI 32-, 64-, 128-Bit AXI 32-Bit AXI
1 - 6Masters
FPGA to HPS HPS to FPGA Lightweight HPS to FPGA
32-Bit
L2Cache
Some modules on Cyclone V SoCs already have built-in hardware diagnostics; others rely on a systemlevel concept to detect random hardware faults.
3-2 Cyclone V SoC Hardware ArchitectureMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Diagnostic Mechanisms and Usage AssumptionsThis topic discusses the implemented diagnostic mechanisms for each IP core or function and usageassumptions for the IP core or function in the application, to detect potential faults. This topic refers toISO26262:2011-2012 or other documentation if applicable.
The assumptions’ tables for the specific IP core or function have the following recommendations:
• M for mandatory• ++ for highly recommended• + for recommended• O for optional
In addition, each table shows possible latent diagnostic measures according to ISO26262:2011-2012.
Power Supply
Voltage Rails
Cyclone V SoC supports different voltage rails for the HPS and FPGA fabric, both for the core logic andI/Os. You can effectively mitigate the influence of supply voltage related common cause faults in both theHPS and the FPGA fabric.
Altera assumes that the application provides dedicated power supplies for the HPS and FPGA fabric.
For more information refer to “Cyclone V Device Family Pin Connection Guidelines” document numberPCG-01014.
Internal Voltage Monitors
Cyclone V SoCs implement internal voltage monitoring for some supply rails. If the voltage of a specificrail is out of specification, the device issues an internal reset. Altera assumes that the item implementsseparate external voltage monitoring, for the voltage rails that are not monitored.
Refer to Cyclone V Device Handbook:
• Volume 1: Device Interface and Integration• Chapter 10: Power Management in Cyclone V Devices
Power Assumptions of Use
Table 3-1: Power Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
PWR1 Separate supply for HPSand FPGA fabric
++ External VoltageMonitor
PWR2 Internal Voltage Monitor M External VoltageMonitor
MNL-10792013.11.19 Diagnostic Mechanisms and Usage Assumptions 3-3
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
PWR3 External VoltageSupervisor
++ Internal VoltageMonitor
Clock
Clock Input
Cyclone V SoCs support multiple clock inputs, which allow you to independently clock the HPS and theFPGA fabric. Multiple clock inputs can guard against clock related common cause faults. The HPSprovides two clock inputs to drive the different clock domains in the HPS. In addition, you can drive theclocks in the FPGA fabric by multiple input clocks and you can drive the logic in the FPGA fabric bymultiple separate clock networks.
Refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Chapter 2: Clock Manager
Refer to Cyclone V Device Handbook:
• Volume 1: Device Interface and Integration• Chapter 4: Clock Networks and PLLs in Cyclone V Devices
HPS Clocking
Separate PLLs drive the different clock domains in the HPS. Different input clocks can drive these PLLs,including clocks routed from the FPGA fabric. The output of the PLLs connect to the different clockdomains and the FPGA fabric.
Refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Chapter 2: Clock Manager
Clock Checker Diagnostic IP Core
You may instantiate a Clock Checker Diagnostic IP core in the FPGA fabric to determine the correctnessof the PLL output clock by feeding an independent reference clock to the diagnostic IP core.
Related Information
• on page 3-7
Watchdog in HPS
The HPS provides several watchdogs that you can use for basic clock supervision. The Cortex-A9 MPUprovides a watchdog for each of the Cortex-A9 processors. The HPS provides two system watchdogs.
3-4 ClockMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Refer to “Cortex-A9 MPCore Technical Reference Manual ARM DDI 0407” and Cyclone V DeviceHandbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 24: Watchdog Timer
Watchdog in FPGA Fabric
You may create a watchdog for the FPGA fabric that a clock independent from the HPS clocks drives.Altera does not make any specific recommendations regarding the implementation of the watchdog.ISO26262-5:2011 Annex D Table D.10 provides some recommendations for the watchdog implementa‐tion. Implement such a watchdog if you can show that it is sufficiently independent from the HPS.
Table 3-2: ISO26262 Reference: Watchdog with separate time base without time-window
Source Reference
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base without time-window
ISO26262-5:2011 Annex D Section D.2.9.1
Table 3-3: ISO26262 Reference: Watchdog with separate time base and time-window
Source Reference
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base and time-window
ISO26262-5:2011 Annex D Section D.2.9.2
Table 3-4: ISO26262 Reference: Temporal and Logical Monitoring of Program Sequence
Source Reference
ISO26262-5:2011 Annex D Table D.10 Combination of temporal and logical monitoring ofprogram sequences
ISO26262-5:2011 Annex D Section D.2.9.4
External Watchdog
An external watchdog provides the benefit for independent clocking, power and reset making it lesssusceptible to common cause faults. Altera does not make any specific recommendations regarding theimplementation of the watchdog. ISO26262-5:2011 Annex D Table D.10 provides some recommenda‐
MNL-10792013.11.19 Watchdog in FPGA Fabric 3-5
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
tions for the watchdog implementation. Implement an external watchdog if you cannot implement awatchdog in the FPGA fabric with sufficient independence from the HPS.
Table 3-5: ISO26262 Reference: Watchdog with separate time base without time-window
Source Reference
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base without time-window
ISO26262-5:2011 Annex D Section D.2.9.1
Table 3-6: ISO26262 Reference: Watchdog with separate time base and time-window
Source Reference
ISO26262-5:2011 Annex D Table D.10 Watchdog with separate time base and time-window
ISO26262-5:2011 Annex D Section D.2.9.2
Table 3-7: ISO26262 Reference: Temporal and Logical Monitoring of Program Sequence
Source Reference
ISO26262-5:2011 Annex D Table D.10 Combination of temporal and logical monitoring ofprogram sequences
ISO26262-5:2011 Annex D Section D.2.9.4
FPGA Clocking
The FPGA fabric provides a very flexible clock network topology that allows you to generate individualclocks with different PLLs. You may separate logic driven by different clock networks. For more informa‐tion, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 4: Clock Networks and PLLs in Cyclone V Devices
Also refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section I: Overview• Chapter 2: Clock Manager
PLLs
PLLs provide robust clock management and synthesis for device clock management, external system clockmanagement, and high-speed I/O interfaces.
3-6 FPGA ClockingMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
The Cyclone V device family contains fractional PLLs that can function as fractional PLLs or integer PLLs.The output counters in Cyclone V devices are dedicated to each fractional PLL that support integer orfractional frequency synthesis.
Clock Switchover Feature
The clock switchover feature allows the PLL to switch between two reference input clocks. Use this featurefor clock redundancy or for a dual-clock domain application where a system turns on the redundant clockif the previous clock stops running. The design can perform clock switchover automatically when theclock is no longer toggling or based on a user control signal.
Output of PLL Clock
Most of the PLLs can also drive a dedicated clock output per PLL, which external checking logic can use todetect any PLL related clock issues.
FPGA PLL Locked Signal
The PLLs in the FPGA fabric also provide a “locked” signal that indicates that the PLL is locked to theinput clock. Use this signal to make sure the PLL is running with the correct frequency relative to theinput clock.
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Section 4: Clock Networks and PLLs in Cyclone V Devices• Chapter: Cyclone V PLLs
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-8: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Clock Checker Diagnostic IP Core
Use this IP core to extend the diagnostic coverage of a design by providing on-line checking of thepresence and frequency of an input clock against a stable reference clock. You can also use this IP core tocheck the correct function of a PLL within the FPGA device or check other system clocks within a safety-related design. You can specify high and low frequency thresholds. If the clock under test falls outside ofthese thresholds, the IP core produces an error signal to alert your system.
MNL-10792013.11.19 Clock Switchover Feature 3-7
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Table 3-9: ISO26262 Reference: Comparator
Source Reference
ISO26262-5:2011 Annex D Table D.2 Comparator
ISO26262-5:2011 Annex D Section D.2.1.2
Related InformationClock Checker Diagnostic IP Core on page 3-7
Clock Assumptions of Use
Table 3-10: Clock Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CLK1 Usage of separate externalclock inputs for HPS andFPGA fabric
+ 1. Clock CheckerDiagnostic IP Coreby routing HPSclock groups toFPGA fabric.
2. Watchdog3. Clock domain
output on externalpin
CLK2 Supervision of HPS clockdomains with the ClockChecker Diagnostic IPCore instantiated in theFPGA fabric
++ 1. Watchdog2. Clock domain
output on externalpin
CLK3 Cortex-A9 MPU watchdog O 1. Watchdog in FPGAfabric
2. External watchdog3. SW test configura‐
tion registers andintended function‐ality.
CLK4 HPS system watchdog O 1. Watchdog in FPGAfabric.
2. External watchdog.3. SW test configura‐
tion registers andintended function‐ality.
3-8 Clock Assumptions of UseMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CLK5 Watchdog in the FPGAfabric
++ 1. External watchdog2. SW test configura‐
tion registers andintended function‐ality
CLK6 External watchdog ++ 1. Internal watchdog2. SW test configura‐
tion registers andintended function‐ality.
CLK7 FPGA fabric PLL missinginput clock detection andautomatic switch tosecondary clock
++ 1. Clock CheckerDiagnostic IP Core
2. Clock output.3. SW test of configu‐
ration registers.
CLK8 FPGA fabric PLL clockoutput
O 1. Clock CheckerDiagnostic IP Core
2. PLL missing inputclock detection.
CLK9 FPGA fabric PLL lockedsignal
O 1. Clock CheckerDiagnostic IP Core
2. PLL missing inputclock detection.
CLK10 Periodic read back ofconfiguration registers
+ 1. Read back registercontent with bothCortex-A9processors.
Related Information
• Clock Checker Diagnostic IP Core on page 3-7• Clock Checker Diagnostic IP Core on page 3-7• Clock Checker Diagnostic IP Core on page 3-7• Clock Checker Diagnostic IP Core on page 3-7• Clock Checker Diagnostic IP Core on page 3-7
ResetCyclone V SoCs provide flexible reset handling of the FPGA and HPS.
MNL-10792013.11.19 Reset 3-9
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
FPGA Reset
During power on, the internal reset voltage supervisor, which monitors the voltages necessary toconfigure the FPGA, generates an internal power-on-reset (POR). The duration of the reset is userselectable. The nSTATUS and CONF_DONE signals indicate the configuration completion. The INIT_DONEsignal can indicate the proper initialization and the design runs after you pull the signal high.
You are responsible for the proper reset of the logic programmed into the FPGA fabric.
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 7: Configuration, Design Security, and Remote System Upgrades in Cyclone V Devices
HPS Reset
The HPS has three reset sources:
• Cold reset (Power On Reset)• Warm reset• Debug reset
Use a cold reset during the power up sequence of the device. The nPOR input pin and other internal resetrequest signals control the cold reset. Use an external voltage supervisor to drive the nPOR reset inputwhen the supply voltages are out of range.
Use a warm reset to recover from a non-responsive condition, when the HPS has already been through acold reset sequence. It does not reset all domains. Initiate a warm reset by the nRST pin, software orwatchdogs. The nRST pin is a bidirectional pin that you can monitor with external logic to determine thestate of the HPS.
Use debug reset during debugging of the application. Initiate it by a request from the debug access port(DAP) or the FPGA fabric.
The reset manager controls the resets into the HPS system, which also handles other reset sources, e.g.,watchdogs, scan manager, and inputs from the FPGA fabric. It can also export the cold and warm reset tothe FPGA logic.
The application software can read the source of the last reset in the reset manager status register.
For more information refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Chapter 3: Reset Manager
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
3-10 FPGA ResetMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-11: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
HPS Reset Assumptions of Use
Table 3-12: Reset: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
RST1 Power On Reset (POR) M 1. External monitoringof signals nSTATUS,CONF_DONE, INIT_DONE.
RST2 FPGA user logic reset + 1. External monitoringof reset signaloutput.
RST3 Monitoring of HPS coldreset
O 1. Dedicatedsupervisor in FPGAfabric.
RST4 Monitoring of HPS warmreset
O 1. External Watchdog2. Dedicated
supervisor in FPGAfabric.
RST5 Software check of last reset ++ 1. Redundant read ofstatus register withcompare of readresult.
RST6 Periodic read back ofconfiguration registers.
+ 1. Read back registercontent with bothCortex-A9processors.
Input/Outputs
FPGA Fabric I/Os
The I/O structures of the FPGA fabric are very flexible and you can configure them to meet many applica‐tion requirements. Cyclone V SoCs implement each single ended I/O as a bidirectional pin that allowsreading back the status of a pin configured as output via the input buffer.
MNL-10792013.11.19 HPS Reset Assumptions of Use 3-11
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 5: I/O Features in Cyclone V Devices
HPS I/Os
Cyclone V SoCs multiplex the HPS single ended I/Os between different peripherals. The system managerand scan manager perform the pin multiplexing and configuration.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 15: Scan Manager
Testing the Pin Interface
To test the pin interface, configure the pins initially to GPIO mode, toggle the pins and read back thestatus of the pin. After you complete the test, you can change the pin multiplexing to the proper applica‐tion configuration.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 22: General-Purpose I/O Interface
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-13: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
3-12 HPS I/OsMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
I/Os Assumptions of Use
Table 3-14: I/Os: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
IO1 FPGA fabric I/O read backof output pin status viainput buffer
++ 1. Dedicatedindependentchecking logic.
IO2 HPS I/O configure asGPIO to test pinconnection
++ 1. Redundant read ofinput status withcompare of readresult.
IO3 Periodic read back ofconfiguration registers
+ 1. Read-back ofregister contentwith both Cortex-A9
FPGA ConfigurationAt power up, the FPGA loads with the configuration to create the application circuit. You can implementthe booting mechanism to either boot HPS and FPGA independent from each other, HPS first and thenthe FPGA or the FPGA first and then the HPS. During the configuration sequence, you can use the statussignals (nSTATUS, nCONFIG, CONF_DONE, INIT_DONE) to monitor the progress using the HPS or an externalmonitor.
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 7: Configuration, Design Security, and Remote System Upgrades in Cyclone V Devices
CRC Background Check
The configuration RAM (CRAM) stores the configuration of the FPGA fabric. You can enable acontinuous background check that calculates a CRC over each configuration frame stored in CRAM. TheCRC can detect single and multibit faults and indicates a detected problem via the CRC_ERROR pin. Thisbackground check has no impact on the normal functionality of the implemented circuit. To validate thatthe CRC circuitry detects faults properly, inject faults into the CRC calculation to emulate CRAMchanges.
MNL-10792013.11.19 I/Os Assumptions of Use 3-13
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Sensitivity Map
Designs do not use all SRAM cells. Only faults in the used cells have an impact on the behavior of thecircuit. The Quartus II software generates a sensitivity map that you can use to determine if a detectedfault is in a “care” or “don’t care” bit.
Sensitivity Map
CRCEngine
SensitivityProcessor
(Soft Logic)
MemoryAccess Logic
ExternalSerial/Parallel
Flash
CRC Error
CRITICAL_ERRORLocationInformation
FPGA
The operation of the critical error detection solution is:
1. The built-in soft error detection circuitry detects and locates the configuration soft error and assertsthe CRC_ERROR pin.
2. The soft logic then takes the error information and uses it to calculate an address within a filecontaining a map indicating which configuration bits are “care” or “don't care.”
3. Using a user-specified memory interface, such as the active serial configuration port, the soft logic thenaccesses the appropriate bit in a sensitivity map file to determine if the particular configuration softerror is critical to the design currently configured into the FPGA.
4. If the configuration soft error is a “don't care,” the FPGA can continue operating without a functionalerror. If the configuration soft error is a “care” and may affect functionality, the Cyclone V SoC assertsthe CRITICAL_ERROR pin and you can take the appropriate action within the system.
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 8: SEU Mitigation in Cyclone V Devices
3-14 Sensitivity MapMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Implementing Redundant Logic
To help detect faults in the configuration of the FPGA fabric, implement redundant logic in the design,and subsequently compare the output of the redundant logic.
FPGA Configuration Assumptions of Use
Table 3-15: FPGA Configuration Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
FPGA_CONF1 Monitoring of configura‐tion status signals witheither the HPS or externalmonitor
+ 1. Watchdog
FPGA_CONF2 HPS I/O configure asGPIO to test pinconnection
++ 1. Redundant read ofinput status withcompare of readresult.
FPGA_CONF3 Continuous CRCbackground check ofCRAM configuration
++ 1. Periodic faultinjection inbackground check
FPGA_CONF4 Determine sensitivity map O 1. Redundant running
FPGA_CONF5 Redundant logic + 1. Test pattern
FPGA User MemoryThe FPGA fabric in the Cyclone V SoC provides user memory in M10K blocks or in MLABs. Each ofthose blocks implements dedicated parity bits which a specific user function for an error detection codeand error correction code (ECC) can use. This functionality is supported by a soft IP in the Quartus IIsoftware.
For more information, refer to Cyclone V Device Handbook:
• Volume 1: Device Interfaces and Integration• Chapter 2: Embedded Memory Blocks in Cyclone V Devices
FPGA User Memory Assumptions of Use
Table 3-16: FPGA User Memory: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
FPGA_UM1 ECC for user memory ++ 1. Fault injectiontesting
MNL-10792013.11.19 Implementing Redundant Logic 3-15
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
HPS InterconnectThe HPS implements an L3 and several L4 interconnects. The L4 segments connect to the variousperipherals, which allows for multiple transactions going on at the same time.
Transmission Redundancy
You can redundantly read the same information multiple times with a subsequent compare of the data orread back write data to verify that the data has not changed during the write operation.
Table 3-17: ISO26262 Reference: Transmission Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Transmission redundancy
ISO26262-5:2011 Annex D Section D.2.7.5
Information Redundancy
You can calculate CRC or other checksum over a larger amount of data, which you should check with apredetermined checksum before you use it.
Table 3-18: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Using a Watchdog
Use an internal or external watchdog to detect transactions that result in a timeout situation or for faultsthat lead to runaway code.
Table 3-19: ISO26262 Reference: Program Sequence Monitoring and Clock
Source Reference
ISO26262-5:2011 Annex D Table D.10 Program sequence monitoring and clock
Software Selftest
You can perform a basic software based transaction test to ensure the functionality of the interconnect.Perform this test at application startup and during running the application.
3-16 HPS InterconnectMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-20: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.14 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-21: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Interconnect Assumptions of Use
Table 3-22: Interconnect Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HPS_BUS1 Internal Watchdog in HPS O 1. External watchdog2. Software test of
watchdog with errorresponse
HPS_BUS2 Internal Watchdog inFPGA fabric
+ 1. External watchdog2. Software test of
watchdog with errorresponse
HPS_BUS3 External Watchdog ++ 1. Internal watchdog2. Software test of
watchdog with errorresponse
HPS_BUS4 Information redundancy ++ 1. Test of CRC engine
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-17
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HPS_BUS5 Transmission redundancy ++ 1. Usage of bothCortex-A9processors tocrosscheck eachother
HPS_BUS6 SW selftest ++ 1. Supervision bysecond Cortex-A9processor
HPS_BUS7 Periodic read back ofconfiguration registers
+ 1. Read back registercontent with bothCortex-A9processors
HPS to FPGA interconnectThere are three AXIs that connect the HPS and FPGA fabric over which the two can communicate witheach other. In addition, other signals are also directly connect to respective IP (e.g. interrupts routed fromthe FPGA to the HPS, or vice versa).
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section II: System Interconnect• Chapter 5: HPS FPGA AXI Bridges
Transmission Redundancy
You can redundantly read the same information multiple times with a subsequent compare of the data orto read back write data to verify that the data does not change during the write operation.
Table 3-23: ISO26262 Reference: Transmission Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Transmission redundancy
ISO26262-5:2011 Annex D Section D.2.7.5
Information Redundancy
You can calculate CRC or other checksum over a larger amount of data, which the Cyclone V SoC checksbefore it is uses it.
Table 25: ISO26262 Reference: Information Redundancy
3-18 HPS to FPGA interconnectMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-24: Source Reference
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Using a Watchdog
Use an internal or external watchdog to detect transactions that result in a timeout situation or for faultsthat lead to runaway code.
Table 3-25: ISO26262 Reference: Program Sequence Monitoring and Clock
Source Reference
ISO26262-5:2011 Annex D Table D.10 Program sequence monitoring and clock
Software Selftest
You can perform a basic software based transaction test to ensure the functionality of the bus or signalconnection. Perform this test at application startup and during running the application.
Table 3-26: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.14 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-27: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792013.11.19 Using a Watchdog 3-19
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
Interconnect Assumptions of Use
Table 3-28: Interconnect Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HPS_FPGA_BUS1 Internal watchdog in HPS O 1. External watchdog2. Software test
watchdog with errorresponse.
HPS_ FPGA_BUS2 Internal watchdog inFPGA fabric
+ 1. External watchdog2. Software test
watchdog with errorresponse.
HPS_ FPGA_BUS3 External watchdog ++ 1. Internal watchdog2. Software test
watchdog with errorresponse.
HPS_ FPGA_BUS4 Information redundancy ++ 1. Test CRC engine.
HPS_ FPGA_BUS5 Transmission redundancy ++ 1. Use both Cortex-A9processors tocrosscheck eachother.
HPS_ FPGA_BUS6 SW selftest ++ 1. Supervision bysecond Cortex-A9processors.
HPS_ FPGA_BUS7 Periodically read backconfiguration registers.
+ 1. Read back registercontent with bothCortex-A9processors.
HPS Cortex-A9 MPU SubsystemThe Cyclone V SoC integrates a Cortex-A9 MPU subsystem for general purpose processing tasks.Depending on the configuration of the device it implements a single Cortex-A9 or dual Cortex-A9processor.
3-20 Interconnect Assumptions of UseMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
The processors in the MPU subsystem are single instantiations. Therefore, the Cyclone V SoC does notimplement redundant logic for error checking purposes. The Cyclone V SoC relies on you to implementdiagnostic mechanisms in software.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section III: Cortex-A9 Microprocessor
For more information on abort handling, refer to the ARM Cortex-A9 and ARM v7A ArchitectureReference Manuals.
Memory Accesses
The Cortex-A9 processor provides mechanisms to detect illegal accesses to specific memory sections,which the MMU can define. The Cyclone V SoCs generate data aborts in this case. Cyclone V SoCs alsoimplement some limited hardware features to detect AXI transaction errors on the internal buses. TheCyclone V SoCs also indicate transaction errors as an abort to the processor.
Table 3-29: ISO26262 Reference: Integrated Hardware Consistency Monitoring
Source Reference
ISO26262-5:2011 Annex D Table D.4 Integrated Hardware consistency monitoring
ISO26262-5:2011 Annex D Section D.2.3.9
Testing the Processor for Permanent Faults
To test for permanent faults in the silicon, implement a test by running test patterns in software. Performthis test at application startup and during running the application.
Table 3-30: ISO26262 Reference: Self-test by Software
Source Reference
ISO26262-5:2011 Annex D Table D.4 Self-test by software
ISO26262-5:2011 Annex D Section D.2.3.1
Run test patterns on both Cortex-A9 processor and compare the results in both processors. Because thesame power rail supplies the processors and the same clock signal clocks them, run the tests with a slightoffset to account for common cause faults.
Table 3-31: ISO26262 Reference: Self-test by Software Cross Exchanged Between Two Independent Units
Source Reference
ISO26262-5:2011 Annex D Table D.4 Self-test by software cross exchanged between twoindependent units
MNL-10792013.11.19 Memory Accesses 3-21
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.3
Testing the Processor for Transient Faults
To test for transient faults:
1. Redundantly implement diverse software that you can run either on a single Cortex-A9 processor ordistributed between the two processors.
2. Check the result of the diverse software running, before you perform any system action.
Table 3-32: ISO26262 Reference: Software Diversified Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.4 Software diversified redundancy
ISO26262-5:2011 Annex D Section D.2.3.4
Alternatively, compare the end result of a software algorithm, and intermediate results and test data byrunning the software on both Cortex-A9 processor.
Table 3-33: ISO26262 Reference: Reciprocal Comparison by Software in Separate Processing Units
Source Reference
ISO26262-5:2011 Annex D Table D.4 Reciprocal comparison by software in separateprocessing units
ISO26262-5:2011 Annex D Section D.2.3.5
Handling Processor Interrupts
Develop specific strategies to cover interrupts. In some cases, you can avoid interrupts and implement apolling mode for software portions that are usually only run once.
If the same program runs on both Cortex-A9 processors, store two copies of the program at differentlocations in memory. Have one Cortex-A9 processor running from one copy and the other Cortex-A9processor running from the other one. This action covers potential memory related issues and alsopotential faults that the transfer of the data from the memory to the L2 cache introduces as the Cyclone VSoC stores the data twice in the cache.
Table 3-34: ISO26262 Reference: Software Architectural Design
Source Reference
ISO26262-6:2011 Software architectural design
3-22 Testing the Processor for Transient FaultsMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-6:2011 Table 3 Restricted use of interrupts
Using a Watchdog
Use an internal or external watchdog to detect transactions that result in a timeout situation or for faultsthat lead to runaway code.
Table 3-35: ISO26262 Reference: Program Sequence Monitoring and Clock
Source Reference
ISO26262-5:2011 Annex D Table D.10 Program sequence monitoring and clock
L1 Cache
Each of the Cortex-A9 processors includes dedicated L1 instruction and data caches, with parityprotection. The protection covers also the cache TAG memories. The parity detection logic initiates animprecise abort to the CPU when it detects an error.
For more information, refer to the ARM Cortex-A9 documentation.
Table 3-36: ISO26262 Reference: Parity Bit
Source Reference
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
BTAC / GHB
Parity protects the branch target access cache and global history buffer of the branch prediction unit ineach Cortex-A9 processor. After parity error detection, the processor refetches the invalid data after itremoves it from the pipeline and generates a parity error interrupt.
Table 3-37: ISO26262 Reference: Parity Bit
Source Reference
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
L2 Cache
The L2 cache is a unified cache that both Cortex-A9 processors can use simultaneously. ECC protects thedata words of the L2 cache and parity protects the TAG RAMs.
MNL-10792013.11.19 Using a Watchdog 3-23
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Table 3-38: ISO26262 Reference: Parity Bit
Source Reference
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
Table 3-39: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes (EDC)
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section III: Cortex-A9 Microprocessor• Chapter 6: Cortex-A9 MPU Subsystem Components
Generic Interrupt Controller
The Cyclone V SoC instantiates the generic interrupt controller once in the design and it serves bothCortex-A9 processors.
Test the functionality of the generic interrupt controller at application startup by performing test patterns.
Table 3-40: ISO26262 Reference: Self-test by Software
Source Reference
ISO26262-5:2011 Annex D Table D.4 Self-test by software
ISO26262-5:2011 Annex D Section D.2.3.1
During running the application, software can implement timeout monitoring for periodic interrupts.
Table 3-41: ISO26262 Reference: Timeout Monitoring
Source Reference
ISO26262-5:2011 Annex D Table D.8 Timeout monitoring
ISO26262-5:2011 Annex D Section D.2.7.8
3-24 Generic Interrupt ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
The Cyclone V SoC routes the HPS peripheral interrupts to the FPGA fabric, which allows you toimplement a dedicated interrupt watchdog in the fabric, or instantiate a Nios II processor to handle orsupervise interrupts.
Table 3-42: ISO26262 Reference: Timeout Monitoring
Source Reference
ISO26262-5:2011 Annex D Table D.8 Timeout monitoring
ISO26262-5:2011 Annex D Section D.2.7.8
In some cases it may be necessary to avoid interrupts and implement a polling mode for softwareportions, which usually only run once.
Table 43:
Table 3-43: ISO26262 Reference: Software Architectural Design
Source Reference
ISO26262-6:2011 Software architectural design
ISO26262-6:2011 Table 3 Restricted use of interrupts
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section III: Cortex-A9 Microprocessor• Chapter 6: Cortex-A9 MPU Subsystem
Memory Management Unit
The memory management unit (MMU) in the Cortex-A9 processor supports basic memory protectionfeatures. The operating system can use these features to separate software tasks from each other to avoidinfluence of these tasks with each other. This should also consider running different software on the twoCortex-A9 processors.
For more information about the MMU, refer to the Memory Management Unit chapter of the Cortex-A9Technical Reference Manual, Revision r3p0, available on the ARM website.
Table 3-44: ISO26262 Reference: Criteria for Coexistence of Elements
Source Reference
ISO26262-9:2011 Section 6 Criteria for coexistence of elements
Related Informationinfocenter.arm.com
MNL-10792013.11.19 Memory Management Unit 3-25
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Snoop Control Unit
The Cortex-A9 processor implements a snoop control unit (SCU) that allows for L1 data cache coherencybetween the two processors and with the L2 cache. The Cyclone V SoC implements parity for the SCUmemory. It generates an interrupt for any parity error. The SCU can be left in its default off state withsoftware ensuring the coherency between multiple masters in the system.
Table 3-45: ISO26262 Reference: Parity Bit
Source Reference
ISO26262-5:2011 Annex D Table D.6 Parity bit
ISO26262-5:2011 Annex D Section D.2.5.2
MPCore Timers
Each of the Cortex-A9 processor implements a dedicated timer module that you can use for the timebaseof the operating system. The Cortex-A9 processor does not implement dedicated hardware measures todetect faults in the processor timers.
The application can implement a cross-check of timer events from one timer with the other timer todetect potential issues in one of the timers, or you can use the global timer in the MPU subsystem forplausibility checking.
Alternatively, use the two timers implemented in the HPS system for similar cross-checks. In addition,you can implement a dedicated timer block in the FPGA fabric for checking of the interrupts of theprocessors. You can then supply the FPGA with different power rails and clocks to account for commoncause faults.
For more information about the watchdog, refer to the Global timer, private timers, and watchdogregisters chapter of the Cortex-A9 MPCore Technical Reference Manual, Revision r3p0, available on theARM website.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 23: Timer
Related Informationinfocenter.arm.com
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
3-26 Snoop Control UnitMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-46: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Internal and External Watchdog
A watchdog can provide measures to detect program sequencing and clock related issues. The Cortex-A9processor implements a dedicated watchdog per processor that you can use for detecting such problems.In addition the HPS implements two separate watchdogs which you can use for the same task.
Alternatively, implement a watchdog in the FPGA fabric. Further, you can use an external watchdog forthe same purpose.
Table 3-47: ISO26262 Reference: Program Sequence Monitoring Clock
Source Reference
ISO26262-5:2011 Annex D Table D.10 Program sequence monitoring clock
For more information about the watchdog, refer to the Global timer, private timers, and watchdogregisters chapter of the Cortex-A9 MPCore Technical Reference Manual, Revision r3p0, available on theARM website.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 24: Watchdog Timer
Related InformationWatchdog in FPGA Fabric on page 3-5
on page 3-5
on page 3-5
infocenter.arm.com
Cortex-A9 MPU Assumptions of Use
Table 3-48: Cortex-A9 MPU: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CA9_MPU1 Processor selftest bysoftware
++ 1. Watchdog
MNL-10792013.11.19 Internal and External Watchdog 3-27
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CA9_MPU2 Software cross-exchange ++ 1. Watchdog
CA9_MPU3 Software diversifiedredundancy
++ 1. Watchdog
CA9_MPU4 Reciprocal comparison bysoftware
++ 1. Watchdog
CA9_MPU5 Storage of and runningfrom two copies of theprogram
+ 1. CRC check ofmemory
CA9_MPU6 Restricted use of interrupts + 1. Watchdog2. Redundant run on
both Cortex-A9processors
CA9_MPU7 Configuration register test + 1. Redundant runningon both Cortex-A9processors
CA9_MPU8 Parity for L1 caches ++ 1. Redundant runningon both Cortex-A9processors
CA9_MPU9 Parity for BTAC and GHB ++ 1. Redundant runningon both Cortex-A9processors
CA9_MPU10 ECC/Parity for L2 cache ++ 1. Watchdog
CA9_MPU11 Generic InterruptController test by testpattern
++ 1. Watchdog
CA9_MPU12 Interrupt timeoutmonitoring via software
+ 1. Redundant runningon both Cortex-A9processors
CA9_MPU13 Interrupt timeoutmonitoring via FPGAfabric watchdog
+ 1. Test pattern tocheck timeoutmonitoringfunctionality
3-28 Cortex-A9 MPU Assumptions of UseMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CA9_MPU14 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
CA9_MPU15 Use of MemoryManagement Unit
++ 1. Test pattern tocheck functionality
2. Check functionalityof one MMU withthe MMU from theother Cortex-A9
CA9_MPU16 Internal watchdog O 1. External Watchdog2. Watchdog in FPGA
fabric
CA9_MPU17 External watchdog ++ 1. Internal Watchdog2. Watchdog in FPGA
fabric
CA9_MPU18 Watchdog in FPGA fabric ++ 1. Internal Watchdog2. External Watchdog
CA9_MPU19 Global Timer for OS timercross-check
+ 1. HPS timer2. FPGA timer3. Watchdog
CA9_MPU20 HPS timer + 1. Global timer2. FPGA timer3. Watchdog
CA9_MPU21 FPGA timer ++ 1. Global timer2. Watchdog
HPS Debug and TraceThe HPS debug infrastructure provides visibility and control of the HPS modules, the ARM Cortex-A9MPU subsystem, and user logic implemented in the FPGA fabric. The debug system design incorporatesARM CoreSight™ components.
The CoreSight components provide normal debugging access into the system, but also trace support andcross-triggering between different components. Use a JTAG interface to access the components, which theCyclone V SoC converts internally to the APB bus over which all debug communication takes place. Inaddition, a master can access the debug and trace components directly via the slave port of the DAP thatalso provides the JTAG interface.
MNL-10792013.11.19 HPS Debug and Trace 3-29
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Tying-off of JTAG Signals
To avoid any adverse effects of the debug and trace logic during running the application, tie off followingsignals:
• HPS_TRST to GND• HPS_TMS to VCCIO_HPS• HPS_TCK to GND
Resetting of Debug and Trace Logic
In addition, keep the rest of the debug and trace logic in reset by setting the dbg bit in the miscmodrstregister of the reset manager.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section IV: Debug and Trace
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-49: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Debug and Trace Assumptions of Use
Table 3-50: Debug and Trace Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
DBG1 Tie off JTAG signals ++ 1. Set the dbg bit inmiscmodrst registerof reset Manager
DBG2 Set the dbg bit inmiscmodrst register ofreset Manager
++ 1. Read reset managerregisters using theFPGA fabric
3-30 Tying-off of JTAG SignalsMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
DBG3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS SDRAM ControllerThe HPS SDRAM controller subsystem provides efficient access to external SDRAM for the ARM Cortex-A9 MPU subsystem, the level 3 (L3) interconnect, and the FPGA fabric. The SDRAM controller providesan interface between the FPGA fabric and HPS. The interface accepts Advanced Microcontroller BusArchitecture (AMBA®) Advanced eXtensible Interface (AXI™) and Avalon® Memory-Mapped (Avalon-MM) transactions, converts those commands to the correct commands for the SDRAM, and manages thedetails of the SDRAM access.
SECDED
The HPS SDRAM controller supports ECC for the 16-bit and 32-bit memory width configuration.Cyclone V SoCs use a separate memory to store the ECC parity bits. The ECC supports single-bit errorcorrection and double-bit errors detection (SECDED) and generates interrupts in case of detected faults.Separate error counters for single and double bit errors count the number of corrections and detections.An error address register holds the address of the most recent error.
Test the ECC logic by inserting single bit and double bit faults in the memory, before running the applica‐tion. You cannot insert directly bit faults via the HPS, because the ECC bits are not memory mapped.Instead address the separate memory that stores the ECC bits via the FPGA fabric. Using an Avalon-MMinterface, use the ECC memory as normal data memory. Therefore, in a 32-bit data configuration, theCyclone V SoCs treat 40-bit (32-bit of data + 8-bit of ECC) as a regular 40-bit data word. The logic in theSoC can write 40-bit data words to the memory, while the ECC logic is turned off. With complete controlover what data the SoC writes, you can introduce single bit or double bit faults. After you write tomemory, the SoC enables the ECC logic and you either read the data via the HPS or the FPGA fabric. Thisprocedure tests the decoder of the ECC logic. Normal operation tests the encoder. The decoder is separatelogic from the encoder, so if there is a fault in the encoder, the decoder detects it.
Table 3-51: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes (EDC)
ISO26262-5:2011 Annex D Section D.2.4.1
MNL-10792013.11.19 HPS SDRAM Controller 3-31
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Using Memory Protection
Use a memory protection feature to isolate specific memory regions for access by specific masters. Set upto 20 different rules in the SDRAM controller to define access permissions for different regions.
Table 3-52: ISO26262 Reference: Criteria for Coexistence of Elements
Source Reference
ISO26262-9:2011 Section 6 Criteria for coexistence of elements
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section V: Memory and Memory Controllers• Chapter 8: SDRAM Controller Subsystem
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
Table 3-53: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-54: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
3-32 Using Memory ProtectionMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
SDRAM Assumptions of Use
Table 3-55: SDRAM Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
SDRAM1 SECDED (ECC) ++ 1. Run test pattern totest detection andcorrection function‐ality
SDRAM2 Memory protectionfeature
++ 1. Run test pattern totest detection andcorrection function‐ality
SDRAM3 CRC check of non-changing data
+ 1. Test pattern forCRC engine
SDRAM4 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS On-Chip RAMThe on-chip RAM serves as general-purpose volatile memory for application data storage.
SECDED
The on-chip RAM supports SECDED, by storing the ECC bits in separate memory cells. The on-chipRAM uses five ECC bits for each data byte, which eliminates read-modify-write operations, compared toimplementing ECC on words. Therefore, the ECC has no performance impact on the application.
The system manager controls the ECC functionality. You may inject single and double bit errors to testthe functionality of the ECC logic. When enabled, the ECC injects an error in each byte of a memory wordto test the different ECC decoders.
Table 3-56: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC
MNL-10792013.11.19 SDRAM Assumptions of Use 3-33
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manger
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
Table 3-57: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-58: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
3-34 Performing CRCMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
On-Chip RAM Assumptions of Use
Table 3-59: On-Chip RAM Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
OCRAM1 SECDED (ECC) ++ 1. Run test pattern totest detection andcorrection function‐ality
OCRAM2 CRC check of non-changing data
+ 1. Test pattern forCRC engine
OCRAM3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS On-Chip Boot ROMThe boot ROM only boots the system. On a cold or warm reset of the MPU subsystem, MPU0 runs thepre-bootloader code stored in the boot ROM. The prebootloader loads a user provided bootloader thatloads the application.
Altera assumes that the booting process is not safety critical as it performs no safety function during thistimeframe.
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
Table 3-60: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
MNL-10792013.11.19 On-Chip RAM Assumptions of Use 3-35
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.5.4
On-Chip Boot ROM Assumptions of Use
Table 3-61: On-Chip Boot ROM: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
BROM1 CRC check of boot ROM O 1. Test pattern forCRC engine
HPS NAND Flash ControllerThe HPS NAND flash controller provides interfaces with external NAND flash memory. You can useexternal flash memory to store a processor boot image, software, or as extra storage capacity for largeapplications or user data. The HPS NAND flash controller is based on the Cadence Design IP NANDFlash Memory Controller.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section V: Memory and Memory Controllers• Chapter 10: NAND Flash Controller
SECDED
The controller supports ECC for different sector sizes and automatically inserts the ECC check bits whenyou write data and strips off the ECC bits when you read data. The ECC supports SECDED. The internalmemories of the NAND controller are also protected by ECC, which supports SECDED.
Table 3-62: ISO26262 Reference: Memory Monitoring using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes
ISO26262-5:2011 Annex D Section D.2.4.1
Injecting Faults
The system manager controls the ECC functionality. You can inject single- and double-bit errors to testthe functionality of the ECC logic. Once enabled, inject an error in each byte of a memory word to test thedifferent ECC decoders.
3-36 On-Chip Boot ROM Assumptions of UseMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manger
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
Table 3-63: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-64: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
NAND Controller Assumptions of Use
Table 3-65: NAND Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
NAND1 ECC ++ 1. Fault injectiontesting
NAND2 CRC checksum ++ 1. Test pattern forCRC engine
MNL-10792013.11.19 Performing CRC 3-37
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
NAND3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS SD/MMC ControllerThe HPS Secure Digital/MultiMediaCard (SD/MMC) controller interfaces to external SD and MMC flashcards, secure digital I/O (SDIO) devices, and Consumer Electronics Advanced Transport Architecture(CE-ATA) hard drives.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section V: Memory and Memory Controllers• Chapter 11: SD/MMC Controller
SECDED
The controller implements ECC for the integrated read and write FIFO. The ECC supports SECDED.
Table 3-66: ISO26262 Reference: Memory Monitoring using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes
ISO26262-5:2011 Annex D Section D.2.4.1
Injecting Faults
The system manager controls the ECC functionality. You can inject single- and double-bit errors to testthe functionality of the ECC logic. Once enabled, inject an error in each byte of a memory word to test thedifferent ECC decoders.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manger
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
3-38 HPS SD/MMC ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-67: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-68: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
SD/MMC Controller Assumptions of Use
Table 3-69: SD/MMC Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
SDMMC1 ECC ++ 1. Fault injectiontesting
SDMMC2 CRC checksum ++ 1. Test pattern forCRC engine
SDMMC3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS Quad SPI Flash ControllerThe HPS provides a quad serial peripheral interface (SPI) flash controller for access to serial NOR flashdevices.
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-39
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section V: Memory and Memory Controllers• Chapter 12: Quad SPI Flash Controller
SECDED
The controller implements ECC for the local memory buffer. The ECC supports SECDED.
Table 3-70: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using error-detection-correction codes (EDC)
ISO26262-5:2011 Annex D Section D.2.4.1
Injecting Faults
The system manager controls the ECC functionality. You can inject single- and double-bit errors to testthe functionality of the ECC logic. Once enabled, inject an error in each byte of a memory word to test thedifferent ECC decoders.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manger
Performing CRC
For data, which does not change during running the application (e.g. instruction memory, constants),check the integrity of the data with a CRC checksum. Perform at application startup or periodicallyduring running the application.
Table 3-71: ISO26262 Reference: Running Checksum/CRC
Source Reference
ISO26262-5:2011 Annex D Table D.6 Running checksum/CRC
ISO26262-5:2011 Annex D Section D.2.5.4
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
3-40 SECDEDMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-72: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Quad SPI Flash Controller Assumptions of Use
Table 3-73: Quad SPI Flash Controller: Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
QSPI1 ECC ++ 1. Fault injectiontesting
QSPI2 CRC checksum ++ 1. Test pattern forCRC engine
QSPI3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS FPGA ManagerThe HPS FPGA manager manages and monitors the FPGA portion of the SoC device. The FPGAmanager can configure the FPGA fabric from the HPS, monitor the state of the FPGA, and drive orsample signals to or from the FPGA fabric.
The FPGA manager cannot detect errors. However, you can use some blocks and techniques to diagnosepotential faults in the FPGA manager that influence the behavior of the FPGA fabric.
Monitor
The FPGA manager implements a block that samples key configuration and status signals of the FPGAfabric to monitor the status and health of the FPGA fabric. A fault in the FPGA manager can influence thestatus of the FPGA fabric. You can generate an interrupt, for each of the monitored signals, to the Cortex-A9 MPU.
MNL-10792013.11.19 Quad SPI Flash Controller Assumptions of Use 3-41
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 13: FPGA Manager
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-74: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
FPGA Manager Assumptions
Table 3-75: FPGA Manager Assumptions
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
FMGR1 Monitor block + 1. Monitor signalsduring FPGAconfiguration
FMGR2 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS System ManagerThe HPS system manager contains memory-mapped control and status registers (CSRs) and logic tocontrol system level functions as well as other modules in the HPS. It also routes the parity and ECCinterrupts to the Cortex-A9 MPU.
The system manager does not implement specific safety features, but the system manager allows you toinject errors in the ECC of several modules to test the ECC functionality. It injects a single bit error in theMSB of a data word and for double bit errors in the MSB and LSB of the data word.
3-42 Periodic Reading Back of Configuration RegistersMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-76: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
System Manager Assumptions of Use
Table 3-77: System Manager Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
SYSMGR1 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS Scan ManagerThe scan manager configures and manages the HPS I/O pins, and communicates with the FPGA JTAGtest access port (TAP) controller. The scan manager drives the HPS I/O scan chains to configure the I/Obank properties before the peripherals in HPS uses the pins. The scan manager can also optionallycommunicate with the FPGA JTAG TAP controller to send commands for purposes such as managingcyclic redundancy check (CRC) errors that the FPGA control block detects.
Configuring the I/Os
You can configure the I/Os in two ways:
• Software• JTAG
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-43
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Configuring the I/Os via software involves multiple steps, which can guard against single-point faults thathave a direct impact on the configuration of the pins. Before the configuration can change, one of therequired steps is to enable a scan chain.
Configuring the I/Os via the FPGA JTAG TAP also involves multiple steps:
1. Ensure the TAP receives the CONFIG_IO JTAG instruction and then receives data via the JTAG port.2. Go through the different states of the JTAG TAP state machine to toggle multiple JTAG signals at the
correct times. A correct sequence of random events leading to a change in state and shifting inmeaningful data is very remote.
3. Tie the JTAG signals to either GND or VCCIO to further decrease the risk of changing the configura‐tion of the I/Os via the JTAG interface.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 15: Scan Manager
Tying off JTAG Signals
To avoid any adverse effects of the debug and trace logic during running the application, tie off followingsignals:
• TMS to VCCIO• TCK to GND
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-78: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
3-44 Tying off JTAG SignalsMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
Scan Manager Assumptions of Use
Table 3-79: Scan Manager Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
SCMGR1 Tie-off JTAG signals ++ 1. Set dbg bit inmiscmodrst registerof reset manager
SCMGR2 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS DMACThe DMAC transfers data between memory and peripherals and other memory locations in the system.The DMAC is an instance of the ARM® Corelink™ DMAC (DMA-330).
The HPS provides one DMAC to handle the data transfer between memory-mapped peripherals andmemories, off-loading this work from the MPU subsystem. The DMAC supports memory-to-memory,memory-to-peripheral, and peripheral-to-memory transfers.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 16: DMA Controller
SECDED
The DMAC contains a multiFIFO (MFIFO) data buffer that it uses to store data that it reads, or writes,during a DMA transfer. ECC protects this buffer and supports SECDED. The DMAC generates interruptsto the Cortex-A9 MPU for both error cases and the system manager controls them. You can inject errorsinto the DMAC to test the detection and correction capability.
Table 3-80: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
MNL-10792013.11.19 Scan Manager Assumptions of Use 3-45
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
Abort Handling
The DMAC also generates precise or imprecise aborts when errors from different sources are detected,including a watchdog abort when the DMAC is in a lockup state.
Table 3-81: ISO26262 Reference: Integrated Hardware consistency monitoring
Source Reference
ISO26262-5:2011 Annex D Table D.4 Integrated Hardware consistency monitoring
ISO26262-5:2011 Annex D Section D.2.3.9
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 16: DMA Controller
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-82: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
3-46 Abort HandlingMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
DMA Controller Assumptions of Use
Table 3-83: DMA Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
DMA1 SECDED (ECC) ++ 1. Run test pattern totest detection andcorrection function‐ality
DMA2 Abort handling M 1. Monitor timeoutmonitoring with theCortex-A9processor.
DMA3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS Ethernet Media Access ControllerThe HPS provides two Ethernet media access controller (EMAC) peripherals. Use each EMAC to transmitand receive data at 10/100/1000 Mbps over Ethernet connections in compliance with the IEEE 802.3specification. The EMACs are instances of the Synopsys® DesignWare® 3504-0 Universal 10/100/1000Ethernet MAC (DWC_gmac).
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 17: Ethernet Media Access Controller
SECDED
ECC protects the transmit and receive data FIFO buffers. The ECC supports SECDED. The ECCgenerates interrupts for both error cases to the Cortex-A9 MPU and the system manager controls them.You can inject errors into the EMAC to test the detection and correction capability.
MNL-10792013.11.19 DMA Controller Assumptions of Use 3-47
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Table 3-84: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 17: Ethernet Media Access Controller
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
Testing I/O Interface
Many Ethernet PHYs support a loopback mode, which allows you to test the physical pin connectionbetween the EMAC and the PHY. Perform this loopback testing at application startup.
Table 3-85: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
Table 3-86: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
3-48 Testing I/O InterfaceMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-87: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
Ethernet MAC Assumptions of Use
Table 3-88: Ethernet MAC Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
EMAC1 SECDED (ECC) ++ 1. Run test pattern totest detection andcorrection function‐ality
EMAC2 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
EMAC3 Information redundancy ++ 1. Test pattern
EMAC4 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-49
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
HPS USB 2.0 OTG ControllerThe HPS provides two instances of a USB On-The-Go (OTG) controller that supports both device andhost functions.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 18: USB 2.0 OTG Controller
SECDED
A single-port RAM (SPRAM) connected to the USB OTG controller stores USB data packets for both hostand device modes. The Cyclone V SoC configures it as FIFO buffers for receive and transmit data packetson the USB link. ECC protects this RAM. The ECC supports SECDED. The ECC generates interrupts forboth error cases to the Cortex-A9 MPU and the system manager controls them. You can inject errors intothe USB Controller to test the detection and correction capability.
Table 3-89: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 18: USB 2.0 OTG Controller
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
Testing I/O Interface
Perform I/O interface tests before you use USB in the application. If the external transceiver supportsloopback mode, a transmission test can test the interface between Cyclone V SoC and the transceiver.Alternatively, implement a defined handshaking protocol between the endpoints and test the connectionat application startup
Table 3-90: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
3-50 HPS USB 2.0 OTG ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
Table 3-91: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-92: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
USB 2.0 OTG Controller Assumptions of Use
Table 3-93: USB 2.0 OTG Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
USB1 SECDED (ECC) ++ 1. Running of testpattern to testdetection andcorrection function‐ality
MNL-10792013.11.19 Implementing Information Redundancy 3-51
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
USB2 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
USB3 Information redundancy ++ 1. Test pattern
USB4 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS SPI ControllerThe HPS provides two serial peripheral interface (SPI) masters and two SPI slaves. The SPI masters andslaves are instances of the Synopsys® DesignWare® Synchronous Serial Interface (SSI) controller(DW_apb_ssi).
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 19: SPI Controller
Testing I/O Interface
Perform I/O interface tests before you use the SPI in the application. A transmission test can test theinterface between Cyclone V SoC and the other endpoint. Alternatively, implement a definedhandshaking protocol between the endpoints and test the connection at application startup
Table 3-94: ISO26262 Reference: Test pattern
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
3-52 HPS SPI ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-95: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-96: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
SPI Controller Assumptions of Use
Table 3-97: SPI Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
SPI1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
SPI2 Information redundancy ++ 1. Test pattern
SPI3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-53
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
HPS I2C ControllerThe I2C controller provides support for a communication link between integrated circuits on a board. Itis a simple two-wire bus which consists of a serial data line (SDA) and a serial clock (SCL) for use inapplications such as temperature sensors and voltage level translators to EEPROMs, A/D and D/Aconverters, CODECs, and many types of microprocessors.
The hard processor system (HPS) provides four I2C controllers to enable system software to communi‐cate serially with I2C buses. These I2C controllers are instances of the Synopsys DesignWare APB I2C(DW_apb_i2c) controller.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 20: I2C Controller
Testing I/O Interface
Perform I/O interface tests before you use the I2C in the application. A transmission test can test theinterface between Cyclone V SoC and the other endpoint. Alternatively, implement a definedhandshaking protocol between the endpoints and test the connection at application startup
Table 97: ISO26262 Reference: Test pattern
Table 3-98: Source Reference
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
Table 3-99: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
3-54 HPS I2C ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-100: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
I2C Controller Assumptions of Use
Table 3-101: I2C Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
I2C1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
I2C2 Information redundancy ++ 1. Test pattern
I2C3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
UART ControllerThe hard processor system (HPS) provides two UART controllers for asynchronous serial communica‐tion. The UART controllers are based on an industry standard 16550 UART controller. The UARTcontrollers are instances of the Synopsys® DesignWare® APB Universal Asynchronous Receiver/Transmitter (DW_apb_uart) peripheral.
MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-55
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 21: UART Controller
Testing I/O Interface
Perform I/O interface tests before you use the UART in the application. The UART supports internalloopback mode, which internally connects the TX and RX pins together. It also configures the TX pin asinactive to avoid external logic to be influenced by the loopback test. In addition, a transmission test cantest the interface between Cyclone V SoC and the other endpoint. Alternatively, implement a definedhandshaking protocol between the endpoints and test the connection at application startup.
Table 3-102: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
Table 3-103: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
3-56 Testing I/O InterfaceMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-104: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
UART Controller Assumptions of Use
Table 3-105: UART Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
UART1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
UART2 Information redundancy ++ 1. Test pattern
UART3 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS TimerThe HPS provides four, 32-bit, general-purpose timers connected to the level four (L4) peripheral bus.The timers optionally generate an interrupt when the 32-bit binary count-down timer reaches zero. Thetimers are instances of the Synopsys® DesignWare® APB Timers (DW_apb_timers) peripheral.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 23: Timer
HPS Timer Cross Check
The application can implement a cross check of timer events from one timer with the other timer to detectpotential issues in one of the timers. Or you can use the global timer in the MPU subsystem forplausibility checking.
For more information about the global timer, refer to the global timer, private timers, and watchdogregisters chapter of the Cortex-A9 MPCore Technical Reference Manual, Revision r3p0, available on theARM website.
MNL-10792013.11.19 UART Controller Assumptions of Use 3-57
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
In addition, you can implement a dedicated timer block in the FPGA fabric for checking of the interruptsof the processors. You can supply the FPGA with different power rails and clocks to account for commoncause faults.
Related Informationinfocenter.arm.com
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-106: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
HPS Timer Assumptions of Use
Table 3-107: HPS Timer Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HTIM1 Timer cross-check + 1. Test pattern
HTIM2 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS Watchdog TimerThe primary function of a watchdog timer is to provide a way for the system to recover from anunresponsive state. The hard processor system (HPS) provides two programmable watchdog timers,which are connected to the level four (L4) peripheral bus. The watchdog timers are instances of theSynopsys® DesignWare® APB Watchdog Timer (DW_apb_wdt) peripheral.
The external oscillator clock drives the watchdogs directly. Once enabled, only a reset can disable them.
3-58 Periodic Reading Back of Configuration RegistersMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 24: Watchdog Timer
Testing Watchdog
Test the watchdog at application startup. Configure the watchdog and allow it to time out to ensure itgenerates a reset.
Table 3-108: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Section D.2.6.1
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-109: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
ISO26262-5:2011 Annex D Section D.2.3.7
HPS Watchdog Timer Assumptions of Use
Table 3-110: HPS Watchdog Timer Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HWD1 Test pattern + 1. External Watchdog2. Watchdog in FPGA
fabric
MNL-10792013.11.19 Testing Watchdog 3-59
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
HWD2 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
HPS CAN ControllerThe HPS provides two CAN controllers. The CAN controllers are instances of the Bosch® D_CANcontroller and compliant with ISO 11898-1.
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 25: CAN Controller
SECDED
ECC protects the CAN message buffers. The ECC supports SECDED. The ECC generates interrupts forboth error cases to the Cortex-A9 MPU and the system manager controls them. You can inject errors intothe CAN to test the detection and correction capability.
Table 3-111: ISO26262 Reference: Memory Monitoring Using EDC Codes
Source Reference
ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC codes.
ISO26262-5:2011 Annex D Section D.2.4.1
For more information, refer to Cyclone V Device Handbook:
• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager
Loopback Mode
Many CAN transceivers support a loopback mode, which allows you to test the physical pin connectionbetween the CAN controller and the transceiver. Perform this loopback testing at application startup. Inaddition, the CAN controller supports a silent mode and loopback mode. In loopback mode, thecontroller internally connects the TX pin with the RX pin to read back a transmitted message. In loopbackmode, the CAN controller connects the TX pin to the CAN transceiver and transmits the message on theCAN bus. A combination of silent mode and loopback mode configures the internal connection betweenTX and RX pins, but also ensures that the message is not transmitted via the CAN TX pin.
3-60 HPS CAN ControllerMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
Table 3-112: ISO26262 Reference: Test Pattern
Source Reference
ISO26262-5:2011 Annex D Table D.7 Test pattern
ISO26262-5:2011 Annex D Section D.2.6.1
Implementing Information Redundancy
You should implement redundancy techniques for the transmitted data. For example, additional CRCover a block of data transmitted, read back of transmitted data, or question and answer protocols. Usingan appropriate method can provide diagnostic capabilities over the whole path of the data transmissionfrom internal storage in Cyclone V SoC, over the internal buses, the communication module, externalinterface and the endpoint.
Table 3-113: ISO26262 Reference: Information Redundancy
Source Reference
ISO26262-5:2011 Annex D Table D.8 Information redundancy
ISO26262-5:2011 Annex D Section D.2.7.6
Periodic Reading Back of Configuration Registers
To check the correctness of configuration registers, read back the register content and compare it with theintended value. Perform this read back after you write the value to the registers and periodicallythereafter.
Note: Some registers may implement bits that automatically clear when reading the register. Ensure aread cannot influence the status of some bits, which may have an impact on the applicationbehavior.
Table 3-114: ISO26262 Reference: Configuration Register Test
Source Reference
ISO26262-5:2011 Annex D Table D.4 Configuration Register Test
MNL-10792013.11.19 Implementing Information Redundancy 3-61
Architecture for Random Hardware Fault Management Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Annex D Section D.2.3.7
CAN Controller Assumptions of Use
Table 3-115: CAN Controller Assumptions of Use
Identifier Safety or DiagnosticFeature
Recommendation Possible Latent Diagnostic
CAN1 SECDED (ECC) ++ 1. Run test pattern totest detection andcorrection function‐ality
CAN2 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results
CAN3 Information redundancy ++ 1. Test pattern
CAN4 Periodic configurationregister test
+ 1. Read back theregister settingswith the secondCortex-A9processor andcompare results
3-62 CAN Controller Assumptions of UseMNL-1079
2013.11.19
Altera Corporation Architecture for Random Hardware Fault Management
Send Feedback
ISO26262 Specific Techniques and Measuresfor FPGA Design 4
2013.11.19
MNL-1079 Subscribe Send Feedback
The following topics describe the specific techniques and measures as described in ISO26262-10:2012Table A.8 with reference to ISO26262-5:2011 and additional other measures. Also consider ASIC design,because many of the techniques for ASIC design are relevant to FPGA design.
Design EntryThe first section of ISO26262-10:2012 Table A.8 describes design entry for microcontroller devices, but isapplicable in general also to FPGA development. These topics describe whether you can apply an Alteratool or process to satisfy each of the Table A.8 items.
Structured Description
Table 4-1: Design Entry: Structured Description
Source Reference
ISO26262-10:2012: Table A.8 Ref 1: Structured description
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: coding guidelines
Suggested Tool NA
Using these techniques is part of your design processes or coding standards. The Quartus II softwaresupports hierarchical and modular design.
Design Description in HDL
Table 4-2: Design Entry: Design Description in HDL
Source Reference
ISO26262-10:2012: Table A.8 Ref 2: Design description in HDL
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
Source Reference
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Technical: tool use
Suggested Tool Standard text editor
Note: The Quartus II software has extensive multilanguage compilation support and can supportmodules of either VHDL or Verilog HDL within the same design. Use this feature when incorpo‐rating third-party IP cores that may be coded in a different (V)HDL.
You can implement text based (V)HDL design entry with a standard text editor. Various text editors havecertain enhancements related to (V)HDL design. For example, tools such as J-Edit and Emacs have(V)HDL modes that have context highlighting and other language related features.
The Quartus II software has a built in text editor with many of these language related features, which youmay use for safety-related development.
You can specify which language version the design uses during Quartus II compilation by adjusting theproject settings.
You should make the selection of which (V)HDL language and version ahead of the coding cycle. Youshould specify this selection in the project requirements specification.
Schematic Entry
Table 4-3: Design Entry: Schematic Entry
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Technical: tool use
Suggested Tool Quartus II schematic entry tool
The Quartus II software supports schematic capture design entry. For current, high complexity designsthis approach is not suitable. The difficulty in maintaining and checking schematic-based designs makes itinappropriate for complex designs.
Note: Altera strongly recommends you do not use this flow. Ensure your design includes no .bdf ormodule.bsf files. Check your project directories for these file types at the design review stage.
4-2 Schematic EntryMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Design Description using Boolean Equations
Table 4-4: Design Entry: Design Description using Boolean Equations
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: coding style
Suggested Tool NA
The Quartus II software flow does not support Boolean descriptions as a design entry method.
Modularization
Table 4-5: Design Entry: Modularization
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 Clause 7.4.1
Compliance Type Procedural: coding style
Suggested Tool NA
The Quartus II software supports hierarchical and modular design. Your coding guidelines should specifyhow you apply modularization in the design. Aspects of the Quartus II software and features can helpwith a modular design methodology.
Project Navigator
The Project Navigator pane in the Quartus II software shows design hierarchy of the modules within yourdesign. The Project Navigator helps you visualize the design structure. Additionally, the Quartus II reportfile shows data in this same hierarchical or modular manner.
Design Partitions
The Quartus II software allows you to define encapsulated blocks of code known as design partitions. Youcan separately compile these partitions. You can reuse results from previous compilations in subsequentsynthesis and place and route procedures. Use this scheme for the following reasons:
• Reduction in compile time• Performance increase• Team-based design
MNL-10792013.11.19 Design Description using Boolean Equations 4-3
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
The Quartus II software shows a visualization of the partitions within a particular design. This interfaceshows the relative sizing of the partitions and the number of interconnections between them.
For more information about design partitions and on team based hierarchical design, refer to thefollowing 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
Application of a Proven in Use Design Environment
Table 4-6: Design Entry: Application of a Proven in Use Design Environment
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-8:2011 Clause 14
Compliance Type Technical: tool use
Suggested Tool Quartus II
The Quartus II software may satisfy this clause in the following ways:
• It has been in the market for a significant period of time (since 2001, and previously as the Quartussoftware)
• Altera has a substantial number of users spread over multiple markets• Substantial testing by Altera satisfies many aspects of ISO26262-8:2011 clause 11 requirements
Within the Quartus II software, the Nios II Integrated Development Environment (IDE) tool uses theGCC compiler tool chain (preprocessor, compiler, linker). This tool compiles C/C++ source codetargeting the Nios II processor. A complete bug list for the specific build of GCC is available from theGNU website.
For up-to-date information about this tool and version, visit the GCC website.
You must use the Quartus II software, for compilation and place-and-route. In areas where you have achoice of tool for example, logic simulators, ensure that the tool satisfies your established tool confidencelevel.
Related Informationhttp://gcc.gnu.org/
HDL Simulation
Table 4-7: Design Entry: HDL Simulation
Source Reference
ISO26262-10:2012: Table A.8 Ref 3: HDL simulation
4-4 Application of a Proven in Use Design EnvironmentMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Source Reference
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Supported third-party simulators
Altera FPGA users may use a third-party simulator within their development. You should seek your owntool confidence level for this purpose. Refer to ISO26262-8:2011 clause 11 for the requirements.
Altera provides integration with various popular simulators through its NativeLink feature.
For more information about supported third-party simulators, refer to the following topics in the QuartusII Software Handbook v13.0:
• Volume 3: Verification• Section I: Simulation• Chapter 1. Simulating Altera Designs
Functional Test on Module Level
Table 4-8: Design Entry: Functional Test on Module Level
Source Reference
ISO26262-10:2012: Table A.8 Ref 4: Functional test on module level
(using for example HDL test
benches)
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: testbench coding
Suggested Tool NA
This measure describes writing an appropriate testbench that allows you to test functionality at a modulelevel. You should refer to any test descriptions created for the module under test. The test descriptionshould specify items such as individual test items, coverage levels, test exclusions, expected failures, and soon.
Functional Test on Top Level
Table 4-9: Design Entry: Functional Test on Top Level
Source Reference
ISO26262-10:2012: Table A.8 Ref 5: Functional test on top level
MNL-10792013.11.19 Functional Test on Module Level 4-5
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Source Reference
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: testbench coding
Suggested Tool NA
This measure describes writing an appropriate testbench that allows you to test functionality at a top level.You should refer to any test descriptions created for the module under test and the top level. The testdescription should specify items such as individual test items, coverage levels, test exclusions, expectedfailures, and so on.
Restricted use of Asynchronous Constructs
Table 4-10: Design Entry: Restricted use of Asynchronous Constructs
Source Reference
ISO26262-10:2012: Table A.8 Ref 6: Restricted use of asynchronous constructs
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Procedural: coding style
Suggested Tool NA
You should adopt a methodology that restricts the use of asynchronous constructs, specifically masterSET and RESET synchronization. For smaller process nodes, you may include more than two flip-flopstages. Perform a metastability analysis of the design to ensure correct operation of this and similarstructures. To perform this action, use the Quartus II metastability reporting tool.
For more information relating to metastability and synchronization chain length, refer to the followingtopics in the Quartus II Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section 3: Design Guidelines• Chapter 15: Managing Metastability with the Quartus II software
For more information about design coding recommendations, refer to the following topics in the QuartusII Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section 3: Design Guidelines• Chapter 13: Recommended Design Practices
4-6 Restricted use of Asynchronous ConstructsMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Synchronization of Primary Inputs and Control of Metastability
Table 4-11: Design Entry: Synchronization of Primary Inputs and Control of Metastability
Source Reference
ISO26262-10:2012: Table A.8 Ref 7: Synchronization of Primary Inputs andControl of Metastability
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Technical: tool use
Suggested Tool Timing Analyzer
Perform a metastability analysis of the design to ensure correct operation of this and similar structures. Toperform this action, use the Quartus II metastability reporting tool.
For more information relating to metastability and synchronization chain length, refer to the followingtopics in the Quartus II Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section 3: Design Guidelines• Chapter 15: Managing Metastability with the Quartus II software
Functional and Structural coverage-driven Verification
Table 4-12: Design Entry: Functional and Structural coverage-driven Verification
Source Reference
ISO26262-10:2012: Table A.8 Ref 8: Functional and Structural coverage-drivenVerification
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Code coverage tool
The Quartus II software does not include code coverage calculation. You should select and use anappropriate tool if you wish to provide this information as part of your certification. This functionality istypically available within logic simulator tools.
MNL-10792013.11.19 Synchronization of Primary Inputs and Control of Metastability 4-7
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Observation of Coding Guidelines
Table 4-13: Design Entry: Observation of Coding Guidelines
Source Reference
ISO26262-10:2012: Table A.8 Ref 9: Observation of coding guidelines
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Procedural: coding style
Suggested Tool Third-party lint checker tool
Observe coding guidelines or rules as part of your design process. Specify any guidelines at the start of theproject. If you allow deviations, specifically review them as part of the code review process.
Use the coding styles described in the Quartus II Software Handbook. You may include these recommen‐dations in your coding guidelines.
The Quartus II Design Assistant helps with the analysis of various parts of a design. This tool is similar inapplication to a design rule checking tool. Additionally, it can offer suggestions for the increase inperformance of a particular design.
For more information about coding style, refer to the following topics in the Quartus II SoftwareHandbook v13.0:
• Volume 1: Design and Synthesis• Section III: Design Guidelines• Chapter 14: Recommended HDL Coding Styles
Application of Code Checker
Table 4-14: Design Entry: Application of Code Checker
Source Reference
ISO26262-10:2012: Table A.8 Ref 10: Application of code checker
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural: coding style
Suggested Tool Third-party lint checker tool
You should run the code checking tool automatically in the design flow.
Related Information
• on page 4-8
4-8 Observation of Coding GuidelinesMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Code Inspection or Walkthrough
Table 4-15: Design Entry: Code Inspection or Walkthrough
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural: observation of documented process
Suggested Tool NA
The code inspection or walkthrough is part of your design and development process. Appropriatemembers of the design or verification team should perform and record this step. As this is a process step,Altera recommends no specific tool for this item.
Application of Validated Soft Cores
Table 4-16: Design Entry: Application of Validated Soft Cores
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Technical: tool
Suggested Tool NA
The Quartus II software allows you to include IP cores in your design. These IP cores can either be fromAltera's broad portfolio of IP cores or obtained from a third-party supplier. In general, soft IP cores arecompiled in the same way as any other source code. They can differ in the inclusion and or parameteriza‐tion steps.
Altera provides various methods of implementing IP cores within the Altera tools.
Including the Nios II Processor in Safety-Related Designs
You can include the Nios II processor within safety-related designs. However, you should fully assess therequirements of the ISO26262:2011-2012 specification and specifically construct your system architecturein response to all relevant clauses.
Nios II Data Caches
Data cache structures can lead to a specific level of variability in the running of code. Because of thecomplexities of maintaining cache coherency, it may not be appropriate to use data caches in a safety-related design. This decision should be made on a design-by-design basis and is not within the scope ofthis document.
MNL-10792013.11.19 Code Inspection or Walkthrough 4-9
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Discuss with your certification assessor the decision whether to use data cache structures.
When configuring the Nios II processor in Qsys, you can independently select the data and address cachesizes for that particular processor instance. Refer to the Nios II documentation for details on sizing of thecaches within the Nios II processor.
Nios II Processor Interrupts
You should carefully consider using interrupts in the software part of safety developments. Their use maynot be appropriate for some applications. The project team should judge this decision and you shouldspecify it in the FPGA or general requirements specification documents.
When including a Nios II processor in a Qsys system, you have the option to connect interrupts to theprocessor core. If the requirements specification states that the design should not use interrupts, theseconnections must remain unconnected.
Quartus II and Nios IDE versions
The Nios II processor runs code that the Nios II IDE tool compiles. This tool is part of the Quartus IIsoftware but has a separate installation process. The Nios II IDE version should match the version of theQuartus II software for the safety development. While some version cross-compatibility exists betweenthe Quartus II software and the Nios II IDE, Altera only presents test data for cases where the Quartus IIsoftware and the Nios IDE tool versions are identical (Altera presents this test data to relevant certifica‐tion bodies under NDA).
Note: Some Altera documents refer to the Nios II IDE as the Nios II Embedded Design Suite. Theseterms are interchangeable.
Nios II GNU Tools
The Nios II IDE uses the industry standard GNU Tools.
Table 4-17: GNU Version
The table shows which GNU version is included with a particular Nios II IDE build.
Nios II Embedded Design Suite Version and Build GNU GCC Version and Build
13.0 build 156 GCC build 4.1.2
The Nios II IDE uses the following parts of the GNU tools:
• Make (GNU make v3.8)• Compiler (GCC)• Linker (GCC)• Binutils (GCC)• Assembler (GCC)• Debugger (GCC)
The GCC tool development is not under the control of Altera development processes, so you must ensureyou visit the GNU website for the latest information related to bug fixes and errata for this tool.
4-10 Nios II Processor InterruptsMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
For GNU make, you should obtain the latest bug fixes and errata from the GNU website:
You should evaluate this information and provide evidence that the GCC and GNU tools meet therequirements of ISO26262-8:2011 clause 11.
Additionally, the Nios II IDE uses the Eclipse development environment editor.
The Eclipse tool development is not under the control of Altera development processes, so you mustensure you visit the Eclipse website for the latest information related to bug fixes and errata for this tool.
Related Information
• http://gcc.gnu.org/gcc-4.1/changes.html#4.1.2• http://www.gnu.org/software/make/• http://www.eclipse.org/platform/
On-line Diagnostic Coverage of Nios II Processors.
The precise configuration of the Nios II processor and the software and hardware system surrounding it iscomplex. Various parts of ISO26262:2011-2012 are relevant. To gain sufficient acceptance in using theNios II processor, it may be necessary to provide a certain degree of online diagnostic coverage to thecore. ISO26262-5:2011 Annex D Table D.4 lists areas to consider when implementing diagnostic coveragetechniques.
Including non-Altera Validated Soft IP Cores
In some cases, you can integrate third-party IP cores in the Quartus II software and you can include themin your design in the same way as Altera-provided IP cores.
Note: You must perform all the steps required when installing or using a third-party IP core. Each IP coredocument details these requirements and is beyond the scope of this document.
Validation of Soft IP Cores
Table 4-18: Design Entry: Validation of Soft IP Cores
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: design and validation processes
Suggested Tool NA
If you include an IP core in a safety-related design that is not previously validated, you should treat this IPcore as if it were design source code. That is, it should be validated in the same manner as other designsources. This procedural step requires no tool or Quartus II step.
MNL-10792013.11.19 On-line Diagnostic Coverage of Nios II Processors. 4-11
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Documentation of Simulation Results
Table 4-19: Design Entry: Documentation of Simulation Results
Source Reference
ISO26262-10:2012: Table A.8 Ref 11: Documentation of simulation results
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural: documentation steps
Suggested Tool NA
No Altera tool is relevant for this item.
SynthesisThe following section of ISO26262-10:2012 Table A.8 describes the synthesis step of programmable deviceusage. This topic describes whether you can apply an Altera tool or process to satisfy each of the table A.8items.
Internal Consistency Checks
Table 4-20: Synthesis: Internal Consistency Checks
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Technical: tool use
Suggested Tool Quartus II, third-party synthesis tool
The Quartus II synthesis process includes consistency checks by default. It includes these checks as part ofthe normal operation of the synthesis process. If you run the synthesis step as specified in the documenta‐tion, no special action is needed.
If you decide to use a third-party synthesis tool, you must refer to the documentation provided with thattool to ensure internal consistency checks are included.
For more information, refer to the following topics in the Quartus II Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section 4: Synthesis
4-12 Documentation of Simulation ResultsMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Gate Netlist Simulation
Table 4-21: Synthesis: Gate Netlist Simulation
Source Reference
ISO26262-10:2012: Table A.8 Ref 12: Simulation of the gate netlist
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Supported third-party simulator
This technique involves running a simulation on the gate-level netlist at all timing corners of the design.In this manner the important timing aspects of the circuit are simulated and any errors highlightedthrough simulation mismatches. Altera does not directly support this approach.
An alternative approach is to perform a static timing analysis of the design. You can use the AlteraTimeQuest Timing Analyzer tool for this analysis.
For the simulator to operate, the correct Altera libraries must be present and included in the simulatorsearch path. Refer to individual simulator documentation for instructions on library inclusion.
For more information about netlist generation and simulation in various simulators, refer to the followingtopics in the Quartus II Software Handbook v13.0:
• Volume 3: Verification• Section I: Simulation
Static Timing Analysis (STA) of the Propagation Delay
Table 4-22: Synthesis: STA of the Propagation Delay
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Technical: tool use
Suggested Tool Quartus II TimeQuest
The Quartus II software includes the TimeQuest Timing Analyzer. This tool performs static timing. Thiscomprehensive tool analyzes the complete chip design using timing constraints and the appropriatecircuit delay models. The timing constraints are important for correct operation of the circuit whenimplemented in hardware. Altera provides the circuit delay models and are included within the particularinstallation of the Quartus II software.
Part of a design flow and signoff might be to ensure that the TimeQuest report files show a "timing clean"design—a design with zero violations against the constraints.
MNL-10792013.11.19 Gate Netlist Simulation 4-13
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
A comprehensive description of the operation of the TimeQuest tool is beyond the scope of thisdocument.
Note: The Quartus II software that this document specifies includes the Classic timing analyzer. You mayuse this tool where appropriate. However, Altera is no longer developing this tool and encouragesyou to use the TimeQuest Timing Analyzer tool.
For more information on the TimeQuest Timing Analyzer, refer to the following topics in the Quartus IISoftware Handbook v13.0:
• Volume 3: Verification• Section II: Timing Analysis
Related Information
• on page 4-17
Verification of the Gate Netlist Against a Reference Model by Simulation
Table 4-23: Synthesis: Verification of the Gate Netlist Against a Reference Model by Simulation
Source Reference
ISO26262-10:2012: Table A.8 Ref 13: Comparison of gate netlist to referencemodel
ISO26262-5:2011 7.4.4
Compliance Type Technical: tool use
Suggested Tool Quartus II simulator
You can simulate the gate netlist to check the output of the synthesis and place and route sections of thecompilation flow. The Quartus II software provides the EDA Netlist Writer, which generates a simulationcompatible gate netlist for this purpose.
The EDA Netlist Writer takes input from the place and route and timing analysis steps to produce a timedgate netlist for simulation. For this reason, perform these steps before you produce a gate netlist.
For the simulator to operate, the correct Altera libraries must be present and included in the simulatorsearch path. Refer to individual simulator documentation for instructions on library inclusion.
For more information about netlist generation and simulation in various simulators, refer to the followingtopics in the Quartus II Software Handbook v13.0:
• Volume 3: Verification• Section I: Simulation
4-14 Verification of the Gate Netlist Against a Reference Model by SimulationMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Comparison of Gate Netlist with Reference Model (Formal Equivalence Check)
Table 4-24: Synthesis: Comparison of Gate Netlist with Reference Model (Formal Equivalence Check)
Source Reference
ISO26262-10:2012: Table A.8 Ref 13: Comparison of gate netlist to referencemodel
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Third-party formal equivalence tool
The Quartus II software does not have a formal equivalence check feature. To use this technique, youmust use a third-party formal equivalence checking tool. This flow requires you to turn off synthesisoptimizations and has limited support within the Quartus II software, therefore Altera strongly adviseagainst using this technique. Instead, you should satisfy this item using gate-level netlist simulation. TheEDA Netlist Writer takes input from the place and route and timing analysis steps to produce a timed gatenetlist for simulation. For this reason, perform these steps before you produce a gate netlist.
For more information about formal equivalence checking and third party tools, refer to the followingtopics in the Quartus II Software Handbook v13.0:
• Volume 3: Verification• Section V: Formal Verification
IC Vendor Requirements and Constraints Check
Table 4-25: Synthesis: IC Vendor Requirements and Constraints Check
Source Reference
ISO26262-10:2012: Table A.8 Ref 14: Documentation of Synthesis Constraints,Results and Tools
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: document check
Suggested Tool NA
MNL-10792013.11.19 Comparison of Gate Netlist with Reference Model (Formal Equivalence Check) 4-15
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
You should ensure that you use the most up-to-date data and information available for your safety-relateddesign. While design libraries and binaries are static for a particular version of the Quartus II software,you should pay particular attention to the following items:
• Product change notes (PCNs). These notes detail any FPGA changes that may have an impact on userdesigns. These notes are not specifically generated for safety-related designs and are general purpose innature. You should analyze these changes to understand any implication to safety-related designs. Youshould contact Altera for a list PCNs.
• Silicon reliability report. The Altera silicon reliability report included with this package was correctwhen published. You can use the figures included as a basis for any calculations required for a design.You should, however, contact Altera for the most up-to-date figures before submitting your design forcertification. Typically, this data is updated twice yearly.
Note: Altera calculates the data in the reliability report with a certain confidence level. Perform a recalcu‐lation to the confidence level that your project uses.
• Single event upset (SEU) data. System safety calculations use this information. Before releasing thisinformation a non-disclosure agreement (NDA) must be in place. You should contact Altera for thelatest figures before submitting your design for certification.
Documentation of Synthesis Constraints, Results and Tools
Table 4-26: Synthesis: Documentation of Synthesis Constraints, Results and Tools
Source Reference
ISO26262-10:2012: Table A.8 Ref 14: Documentation of Synthesis Constraints,Results and Tools
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: document check
Suggested Tool NA
Applying Timing Constraints
Generation and maintenance of accurate timing constraints is important for FPGA and ASIC designs.The Quartus II software supports timing constraints in the Synopsys Design Constraints (. sdc) fileformat. The FPGA and ASIC industry widely use this industry-standard constraints format.
Apply timing constraints during:
• Synthesis. Timing constraints drive Quartus II synthesis to apply effort to timing critical areas of thedesign. This optional part of the flow increases the performance and or decreases the logic utilizationof the design.
• Timing analysis. The timing analysis part of the Quartus II flow (in TimeQuest) uses timingconstraints. This critical aspect of the flow checks that the design meets the timing parametersspecified by the requirements specification of the design. If the design does not meet constraints, thedesign may not perform correctly when run in hardware.
You can generate or modify the . sdc file within a standard text editor. The TimeQuest tool has a GUI thathelps constraint generation. Typically, designs have multiple . sdc files that contain information forspecific modules.
4-16 Documentation of Synthesis Constraints, Results and ToolsMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
For more information about the TimeQuest Timing Analyzer tool and constraints generation, refer to thefollowing topics in the Quartus II Software Handbook v13.0:
• Volume 3: Verification• Section II: Timing Analysis
Also refer to the TimeQuest Timing Analyzer: Native SDC Support for Timing Analysis of FPGA-BasedDesigns White Paper.
Applying General Design Constraints
The Quartus II settings file (.qsf) stores general design constraints.
Design constraints have a significant effect on the operation and performance of the design. Treat themwith the same level of importance as a design source file. Always perform the following actions on any .qsf or . sdc files:
• Include them within the project revision control system.• Perform a design review on them with design source files.
Documenting Synthesis Results
The Quartus II software generates a number of useful report files at various stages of the compilation flow.These plain text files are overwritten on each running of the various tool steps. If you wish to archiveintermediate report files, put in place procedures.
You can specify the output location of all project files, including report files. This setting may helpseparate the generated files from other project related files. To set this option in the Quartus II software,on the Assignments menu, click Settings, and then click Compilation Process Settings.
Application of Proven in Use Synthesis
Table 4-27: Synthesis: Application of Proven in Use Synthesis
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: tool specification
Suggested Tool Quartus II integrated synthesis
The analysis and synthesis process translates the logic functions into elements that map into FPGA logicelements. The synthesis process performs the following functions:
1. Checks the syntax of all design source files2. Elaborates and expands the design hierarchy3. Translates the (V)HDL logic into FPGA logic elements4. Creates a design database that represents the complete design in FPGA logic elements and logical
connections
Note: Steps 1) and 2) comprise the Quartus II Analysis and Elaboration process, which may form part ofthe V-model coding step.
MNL-10792013.11.19 Applying General Design Constraints 4-17
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Analysis and synthesis builds a single project database that integrates all the design files in a design entityor project hierarchy. The Quartus II software uses this database for the remainder of project processing.Other compiler modules update the database until it contains the fully optimized project.
As the synthesis process translates the (V)HDL source code, the requirements specification of the designshould define which languages and versions you should use within the safety development. Altera expectsthat when you define the language and version, you use it throughout the project.
The Quartus II software has mixed language support, thus it can support design files of differentlanguages. For example, using a third-party IP core. You should ensure that any language choice made isalso supported by third-party tools that you may use, for example a logic simulator.
Many third-party synthesis tools are available. You can use these tools within the Quartus II developmentflow. Altera does not evaluate the suitability of these tools for safety-related designs. For this reason, youmust perform your own evaluation of these tools.
With respect to the particular requirement of proven-in-use synthesis; Altera has extensive history withthe development of logic synthesis technology. Altera performs significant testing of its internal modulesand complete design flow. Additionally, Altera has significant usage and market data to support a provenin use claim.
Note: To view the results of the synthesis or place and route stage, use one of the Quartus II netlistviewers. These viewers give a graphical representation of the tool output and allows visual checkingof the tool output.
For information on how to integrate third-party synthesis tools into a standard Quartus II flow, refer tothe following topics in the Quartus II Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section 4: Synthesis
For more information about netlist viewer technology, refer to the following topics in the Quartus IISoftware Handbook v13.0:
• Volume 1: Design and Synthesis• Section 4: Synthesis• Chapter 21: Analyzing Designs with Quartus II Netlist Viewers
Application of Proven in Use Libraries/CPLD Technologies
Table 4-28: Synthesis: Application of Proven in Use Libraries / CPLD Technologies
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: tool specification
Suggested Tool Quartus II integrated synthesis
The Quartus II software includes all the synthesis libraries necessary for the compilation of both AlteraCPLD- and FPGA-based products. Always use the Quartus II software for the compilation of designstargeting these products. Altera has significant test and usage data that you can use as evidence of theQuartus II software proven-in-use.
4-18 Application of Proven in Use Libraries/CPLD TechnologiesMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Script -based Procedures
Table 4-29: Synthesis: Script based Procedures
Source Reference
ISO26262-10:2012: Table A.8 Ref 15: Script based procedures
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Technical: tool use
Suggested Tool Quartus II Tcl scripting flow
The Quartus II software has extensive support for Tcl (tool control language) scripting. Altera offersscripting control for each portion of the compilation process. Use scripted flows as they allow robust andrepeatable compilation.
The following areas of particular applicability exist:
• Managing Quartus II project• Defining constraints (timing and device level)• Running compilation flow• Timing analysis• Generating reports and parsing• Running tests• Parsing and reporting test output
Additionally, the Quartus II software supports an interactive mode for running Tcl commands.
For information about Tcl scripting as part of the Altera FPGA design flow, refer to the following topics inthe Quartus II Software Handbook v13.0:
• Volume 2: Design Implementation and Optimization• Section I: Scripting and Constraint Entry• Chapter 3: Tcl Scripting
Adequate Time Margins
Table 4-30: Synthesis: Adequate Time Margins
Source Reference
ISO26262-10:2012: Table A.8 Ref 16: Adequate time margin for process technolo‐gies in use for less than 3 years
ISO26262-5:2011 Section 7.4.2.4
Compliance Type Technical: tool use
Suggested Tool Quartus II TimeQuest
MNL-10792013.11.19 Script -based Procedures 4-19
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
You must satisfy this clause, by applying clock uncertainty constraints to your design. Clock constraintsfor the design are in the project.sdc file.
• The setup uncertainty constraint brings the effective clock latch edge earlier in the cycle, to applymargin to maximum timing.
• The hold uncertainty constraint brings the effective clock latch edge later in the cycle, to apply marginto minimum timing.
Both these constraints reduce the effective data valid window and hence provide the additional marginrequired.
Figure 4-1: Effect of Clock Uncertainty on Data Valid Window
Se tup unce rta inty(>20% of c lock cyc le )
H old unce rta inty10 0 ps
E ffec tive da ta va lid wi ndo w
E ffec tive c lock edg eN om ina l/Pe rfec t c lock edg e
Cl oc k
D a ta
Applying Clock Uncertainty Contraints
For setup timing, apply a clock uncertainty constraint of 20% of the clock period to your clock setup time.
set_clock_uncertainty –to {<user clock>} –setup <uncertainty>
For hold timing, as hold timing is clock frequency independent, adding 20% of the clock period is notapplicable. Add a hold time of 100 ps to achieve a safe margin.
For base clocks:
set_clock_uncertainty –to {<user clock>} –hold <original hold uncertainty + 0.1>
For derived PLL clocks:
set_clock_uncertainty –to {<user clock>} –hold 0.1 -add
For example:
• Clock name = pllclk[1]• Frequency = 100 MHz• Period = 10 ns• Setup uncertainty = 20% of 10 ns = 2 ns• Hold uncertainty = 100 ps = 0.1 ns• set_clock_uncertainty -to { u_alt_pll|altpll_component|pll|clk[1] } - setup 2
• set_clock_uncertainty -to { u_alt_pll|altpll_component|pll|clk[1] } - hold 0.1
4-20 Applying Clock Uncertainty ContraintsMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
To determine if your design requires this additional slack:
1. Determine the process technology of your chosen device. The date of the family introductions reflectsthe date when Altera received first samples in this technology node.
2. Look up the date for the first use of this process in production.3. From this date, you should determine if your certification falls within 3 years of this date, to decide if
the additional slack (>20%) for process technologies in use for less than 3 years applies.
Table 4-31: Stratix Family Introduction
Device Family Year of Introduction Process Technology (nm)
Stratix 2002 130
Stratix GX 2003 130
Stratix II 2004 90
Stratix II GX 2005 90
Stratix III 2006 65
Stratix IV 2008 40
Stratix V 2011 (April) 28HP
Table 4-32: Cyclone Family Introduction
Device Family Year of Introduction Process Technology (nm)
Cyclone 2002 130
Cyclone II 2004 90
Cyclone III2007 65
2009 60
Cyclone IV 2010 60
Cyclone V 2012 (March) 28LP
Cyclone V SoC 2013 (September) 28LP
Table 4-33: Process First Use
Process Technology (nm) Year of First Use
130 2002
MNL-10792013.11.19 Applying Clock Uncertainty Contraints 4-21
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Process Technology (nm) Year of First Use
90 2004
65 2006
60 2009 (January)
40 2008 (December)
28HP/LP 2011 (October)
Table 4-34: CPLD Device Families
Device Family Name Type Power and TimingModel Final in v13.0
Process Technology Greater Than 3 Years
FLEX 10K, A, E CPLD Yes Yes
FLEX 6000 CPLD Yes Yes
MAX II CPLD Yes Yes
MAX II Z CPLD Yes Yes
MAX 7000AE, B,S
CPLD Yes Yes
Other device families may not have final timing or power models in the Quartus II software v13.0. Fordevice timing or power model support status, contact Altera.
For more information on timing analysis and the application of clock uncertainty constraints, refer to thefollowing topics in the Quartus II Software Handbook v13.0:
• Volume 3: Verification• Section II: Timing Analysis
Test Insertion and Test Pattern Generation
Design for Testability
Table 4-35: Test Insertion: Design for Testability
Source Reference
ISO26262-10:2012: Table A.8 Ref 17: Design for testability (depending on the testcoverage in percent)
4-22 Test Insertion and Test Pattern GenerationMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Source Reference
ISO26262-5:2011 Section 7.4.1.6
Compliance Type Procedural: coding style
Suggested Tool NA
You should adopt a methodology that reduces non-testable or poorly testable structures within the design.
The Quartus II software can aid in the analysis of a design that contains certain structures that are difficultto test. For example, the Quartus II software warns of latch inference in your design files.
For more information, refer to the following topics in the Quartus II Software Handbook v13.0:
• Volume 1: Design and Synthesis• Section III: Design Guidelines• Chapter 14: Recommended HDL Coding Styles
Placement, Routing, Layout GenerationThe third section of ISO26262-10:2012 Table A.8 describes placement, routing and layout steps. Thefollowing section describes whether you can apply an Altera tool or process to satisfy each of the table A.8items. Altera performs many of these items during the development of the FPGA and are of less relevanceto users of these products.
Justification of Proven in Use for Applied Hard Cores
Table 4-36: Justification of Proven in Use for Applied Hard Cores
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: data collection
Suggested Tool NA
Altera only releases FPGA products into production after extensive validation and testing. Altera also hasextensive production experience as a result of its time in the market and volume of shipped units.
MNL-10792013.11.19 Placement, Routing, Layout Generation 4-23
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Application of Validated Hard Cores
Table 4-37: Application of Validated Hard Cores
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: core specification
Suggested Tool NA
Altera only releases FPGA products into production after extensive validation and testing. Altera also hasextensive production experience as a result of its time in the market and volume of shipped units
Gate Netlist Simulation after Layout
Table 4-38: Gate Netlist Simulation after Layout
Source Reference
ISO26262-10:2012: Table A.8 Ref 21: Simulation of the gate netlist after layout, tocheck timing constraints, or static analysis of thepropagation delay (STA)
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Supported third-party simulators
Table 4-39: STA of the Propagation Delay
Source Reference
ISO26262-10:2012: Table A.8 Ref 21: Simulation of the gate netlist after layout, tocheck timing constraints, or STA of the propagationdelay
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Quartus II TimeQuest
The Quartus II software includes the TimeQuest Timing Analyzer. This tool performs STA. Thiscomprehensive tool analyzes the complete chip design using timing constraints and the appropriate
4-24 Application of Validated Hard CoresMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
circuit delay models. The timing constraints are important for correct operation of the circuit whenimplemented in hardware. Altera provides the circuit delay models and are included within the particularinstallation of the Quartus II software.
Part of a design flow and signoff might be to ensure that the TimeQuest report files show a "timing clean"design—a design with zero violations against the constraints.
A comprehensive description of the operation of the TimeQuest tool is beyond the scope of thisdocument.
For more information on the TimeQuest Timing Analyzer, refer to the following topics in the Quartus IISoftware Handbook v13.0:
• Volume 3: Verification• Section II: Timing Analysis
Related Information
• on page 4-16
Analysis of Power Network
Table 4-40: Analysis of Power Network
Source Reference
ISO26262-10:2012: Table A.8 Ref 22: Analysis of power network
ISO26262-5:2011 Section 7.4.4
Compliance Type Technical: tool use
Suggested Tool Quartus II PowerPlay Power Analyzer
The PowerPlay power analyzer tool allows you to estimate power consumption from early design conceptthrough design implementation.
Related Information
• on page 2-21
Comparison of the Gate Netlist after Layout with the Reference Model
Table 4-41: Comparison of the Gate Netlist after Layout with the Reference Model
Source Reference
ISO26262-10:2012: Table A.8 Ref 23: Comparison of the gate netlist after layoutwith the reference model (formal equivalencecheck)
ISO26262-5:2011 Section 7.4.4
MNL-10792013.11.19 Analysis of Power Network 4-25
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Source Reference
Compliance Type Technical: tool use
Suggested Tool Third-party formal equivalence tool
Related Information
• on page 4-15
Design Rule Check
Table 4-42: Design Rule Check
Source Reference
ISO26262-10:2012: Table A.8 Ref 24: Design rule check (DRC)
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural
Suggested Tool N/A
This item describes the design rule checking that Altera performs on their FPGA design. No user action isrequired for this item.
Layout Versus Schematic (LVS) Check
Table 4-43: LVS Check
Source Reference
ISO26262-10:2012: Table A.8 Ref 25: LVS check
ISO26262-5:2011 Section 7.4.4
Compliance Type Procedural
Suggested Tool Quartus II
All the connections between elements on the FPGA are pre-routed and are checked by Altera. Only theconfiguration determines the actual path of data.
Altera tools do not support LVS check. The Chip Planner in the Quartus II software can visualize theconnections between the different elements on the chip, which you can then manually analyze for correct‐ness. The tool includes various configuration options for different tasks, including exploration of pathswithin the design.
4-26 Design Rule CheckMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
For more information on the Chip Planner, refer to the following topics in the Quartus II SoftwareHandbook v13.0:
• Volume 2: Design Implementation and Optimization• Section III: Area, Timing, Power, and Compilation Time Optimization• Chapter 15: Analyzing and Optimizing the Design Floorplan with the Chip Planner
Safety-related Special Characteristics during Chip ProductionThe next section of ISO26262-10:2012 Table A.8 describes production items. Altera carries out many ofthese items during the production of the FPGA and are of less relevance to users of these products. Thefollowing topics provide some insight into the Altera production process.
Application of a Proven in Use Process Technology
Table 4-44: Production: Application of a Proven in Use Process Technology
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: device selection specification
Suggested Tool NA
Altera has extensive production experience as a result of its time in the market and volume of shippedunits. Altera use TSMC as a foundry partner who, similarly, have an extensive customer base.
Application of a Proven in Use Device-Series
Table 4-45: Production: Application of a Proven in Use Device-Series
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: selection of appropriate design team
Suggested Tool NA
This calls for FPGA users to have sufficient application experience. Consider this procedural measurewhen constructing the safety project team.
MNL-10792013.11.19 Safety-related Special Characteristics during Chip Production 4-27
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
Application of a Proven in Use Production Process
Table 4-46: Production: Application of a Proven in Use Production Process
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: device selection specification
Suggested Tool NA
Altera has extensive production experience as a result of its time in the market and volume of shippedunits. Altera use TSMC as a foundry partner who, similarly, have an extensive customer base.
Quality Control of the Production Process
Table 4-47: Production: Quality Control of the Production Process
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: device selection specification
Suggested Tool NA
Altera has a quality system that meets ISO 9001:2008 standards and is audited periodically by the NationalStandards Authority of Ireland (NSAI). For copies of the certificates, refer to the Altera website.
In additional to Altera’s quality certificates, Altera ensures that our suppliers also conform to variousindustry-recognized standards. Altera conducts yearly assessments of the quality process and performanceof our major suppliers. Altera hold periodic (weekly or monthly) review meetings to ensure the continuedquality of Altera's end product. Altera records the results of this assessment and any ongoing items in acomputerized corrective action system. Altera employees are typically onsite at our wafer and packagingsubcontractors every day and TSMC and Amkor Technology employees visit Altera offices multiple timesduring each working week.
The Altera silicon provider (TSMC) has certificates for the following quality standards:
• ISO 9001• QS-9000• ISO 9001:2000• ISO/TS 16949:2002
For more information, visit the TSMC quality and reliability web page.
4-28 Application of a Proven in Use Production ProcessMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
The Altera packaging supplier (AMKOR Technology) has the following quality certifications:
• ISO 9001• ISO 14001• TS 16949• OHSAS 18001
For more information, refer to the Amkor Technology quality management web page.
The Altera packaging supplier (ASE Group) has the following quality certifications:
• ISO 9002• ISO 14000
For more information, refer to the ASE Group quality policy web page.
Related Information
• http://www.altera.com/support/devices/reliability/certifications/19.1804-Altera-Cert.pdf• http://www.tsmc.com/english/aboutTSMC/quality_management_system.htm• http://www.amkor.com/go/about-us/quality-management/qualitymanagement• http://www.aseglobal.com/content/2-2.htm
Final Verification and Validation of the FPGA Prototype in the System
Table 4-48: Production: Quality Control of the Production Process
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural: Running of hardware validation
Suggested Tool NA
This user procedural measure has no specific Altera tool or process recommended.
Final Verification and Validation During Mass Production
Table 4-49: Production: Quality Control of the Production Process
Source Reference
ISO26262-10:2012: Table A.8 NA
ISO26262-5:2011 NA
Compliance Type Procedural
Suggested Tool NA
MNL-10792013.11.19 Final Verification and Validation of the FPGA Prototype in the System 4-29
ISO26262 Specific Techniques and Measures for FPGA Design Altera Corporation
Send Feedback
This user procedural measure has no specific Altera-recommended tool or process.
4-30 Final Verification and Validation During Mass ProductionMNL-1079
2013.11.19
Altera Corporation ISO26262 Specific Techniques and Measures for FPGA Design
Send Feedback
Known Problems in the Altera Tools andSoftware 5
2013.11.19
MNL-1079 Subscribe Send Feedback
For known problems with the Quartus II software, refer to the Quartus II release notes.
For known problems with IP cores and the Nios II software build tools, refer to the Nios II and IP coreerrata web page.
Related Information
• http://www.altera.com/literature/lit-rn-q2_archive.jsp• http://www.altera.com/literature/lit-es.jsp
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
Development Interface Agreement 62013.11.19
MNL-1079 Subscribe Send Feedback
The Development Interface Agreement describes the responsibilities and activities of the customer andthe supplier in a distributed development of an item or element. Cyclone V SoC and the tools used todevelop applications for Cyclone V SoC are developed as Safety Element out of Context (SEooC) and notfor one specific use case.
This topic describes the deliverables Altera provides when using these commercial-off-the-shelf (COTS)products.
Safety ManagerThe tools described in the Cyclone V SoC Safety Manual have existed for many years in their basic formand are updated periodically with new features and fixes. They have been assessed previously with regardto IEC61508:2010 and are planned to be assessed to ISO26262:2011-2012. No dedicated Safety Managerwas appointed for the development of the tools. As shown by the assessment to IEC61508:2010,appropriate processes are in place for systematic fault reduction. The adherence to these processes ismanaged by the responsible functional managers and the quality organization.
Cyclone V SoC started development before the ISO26262 standard was release in November 2011. Aswith the tools development, it has been shown with the assessment to IEC61508 that the FPGA productsof Altera are fit for use in safety critical applications. No Safety Manager was appointed during theproduct development of Cyclone V SoC. Systematic fault reduction is part of the Altera standard develop‐ment process and the individual functional managers are responsible for adherence to the definedprocesses.
Altera has appointed a Safety Manager for release to production and the remaining product lifecycle.
For new customer developments that intend to use Cyclone V SoC and dedicated tools, Altera canappoint a Safety Manager to work with the customer Safety Manager during their application develop‐ment.
The Safety LifecycleThe products of Altera are developed as SEooC. The processes used for the development are incompliance with IEC61508:2010.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
To establish the requirements and features, Altera made assumptions of the intended use of the productsduring experience gained in shipping these products for several years into specific safety critical applica‐tions. Altera established these assumptions with several customers in the industry.
Altera performed a qualitative failure analysis as shown in the FMEDA. Reliability predictions are madeboth on Altera internal evaluations and industry standard models.
Related Information
• on page 2-1
Activities Performed by Altera and Customer ResponsibilitiesThis topic defines the activities Altera performs during the safety lifecycle, the support Altera can provideto its customers and the activities Altera expects the customer to perform.
Table 6-1: Definition of Responsibilities of Safety Lifecycle Activities
Safety Lifecycle Activity Altera Customer
Management of functional safety Yes Yes
Item definition No Yes
Hazard and Risk Analysis No Yes
Functional Safety Concept SEooC Yes
Product development at systemlevel
No Yes
Specification of technical safetyrequirements
SEooC Yes
Item design No Yes
Specification of HPS hardwarerequirements
Yes No
Specification of FPGA hardwarerequirements
No Yes
HPS hardware design Yes No
FPGA hardware design Support provided Yes
Verification of HPS hardwaredesign
Yes No
6-2 Activities Performed by Altera and Customer ResponsibilitiesMNL-1079
2013.11.19
Altera Corporation Development Interface Agreement
Send Feedback
Safety Lifecycle Activity Altera Customer
Verification of FPGA hardwaredesign
No Yes
Evaluation of HPS architecturalmetrics
Support provided Yes
Evaluation of FPGA architec‐tural metrics
Support provided Yes
Evaluation of safety goalviolations
No Yes
Software development Support provided Yes
Item integration and testing No Yes
Safety assessment Support provided Yes
Release to production Support provided Yes
Production, maintenance,decommissioning
Support provided Yes
Confidence in the use of SWtools
Support provided Yes
Information Provided by AlteraThe table lists the information Altera provides to customers for their safety development.
Table 6-2: Information Provided by Altera
Altera Information Availability
Safety Manual (this document) Public information
Summary FMEDA Public information
Detailed FMEDA NDA; for purchase
Assessment certificate NDA; for purchase
MNL-10792013.11.19 Information Provided by Altera 6-3
Development Interface Agreement Altera Corporation
Send Feedback
Responsible Parties for ActivitiesAltera can work closely with the customer during the item development to perform the activities definedin Activities Performed by Altera and Customer Responsibilities. The responsible persons and interac‐tion can be defined with the customer.
Communication of Target ValuesAltera provides the values of the quantitative safety analysis in the FMEDA. The customer can tailor thesetarget values based on their specific integration of the component. Altera can provide support to thecustomer discussing strategies to achieve the hardware architectural metrics on the item level.
Supporting Processes and ToolsAltera provides the following tools to the customer.
Table 6-3: Processes and Tools Output Format
Processes and Tools Output Format
Safety Manual PDF
Summary FMEDA PDF
Detailed FMEDA Microsoft Excel
Quartus II software Various
6-4 Responsible Parties for ActivitiesMNL-1079
2013.11.19
Altera Corporation Development Interface Agreement
Send Feedback
Software Development with the Nios IIProcessor 7
2013.11.19
MNL-1079 Subscribe Send Feedback
The following topic gives a summary of the steps required to develop software with the Nios II processorin safety applications. You should refer to ISO26262-6:2011 for complete requirements for safety softwaredevelopment.
Using Qsys to Create a Nios II SystemAt this stage, you create a Nios II system by connecting a Nios II processor to the components requiredfor your system design. This stage uses the Qsys tool to make the connections between the componentsand set the component base addresses. When you successfully generate the system, it provides a descrip‐tion of the Nios II system in the .sopcinfo file.
Perform this task as part of the Logical Module Integration step of the hardware design. This task usesinformation from the FPGA architecture description with detailed module requirements specification.
Suggested tool:
• Qsys
For a complete description of creating Nios II systems in Qsys, refer to the following topic in theQuartusII Handbook Version 13.0:
• Volume 1: Design and Synthesis• Chapter 7: Creating a System with Qsys
Creating a Board Support Package for your Nios II SystemIn this step, you create a board support package (BSP) for your Nios II system. The BSP contains informa‐tion about the hardware components in your Nios II system and allows the software programmer toaccess to the Nios II system hardware components.
The BSP contains software drivers, system header files and HAL components that your Nios II systemrequires. Additionally, this step creates a makefile, with the correct dependencies, which allows you torebuild the BSP if necessary.
You select the software drivers for the components you include in your Nios II system from a library thatAltera provides. Do not modify the drivers, or use alternative drivers, otherwise additional safety qualifi‐cation is required.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134
Suggested tools:
• Nios II software build tools GUI• Nios II software build tools BSP wizard• Nios II software build tools build scripts
Verification steps:
• Check the generated system.h file has correct base addresses:
• Cross check with Qsys GUI or design .sopcinfo file.• Check the generated system.h file has header code for all components:
• Cross check with Qsys GUI or design .sopcinfo file.• Check that the component settings are correct by referring to component documentation (descrip‐
tions in the Qsys component GUI).• Check the generated alt_sys_init.c file. Perform a manual inspection of this file to ensure it is correct
(refer to the Nios II documentation for the effect of the settings within this file).
For more information about creating a BSP, refer to the following topics in the Nios II Software DevelopersHandbook v11.0:
• Section I. Nios II Software Development• Chapter 2 Getting Started with the Graphical User Interface• Chapter 4 Nios II Software Build Tools
Creating an Application FrameworkIn this step you create a software application framework that links to the BSP that you created in theprevious step. This framework eventually includes your application code and an example makefile thatcontains references to all the sources required to build the software for your target Nios II system.
If you select an application template, do not select a template that includes unwanted or unqualified code(for example an operating system). Select the blank template for the application.
Suggested tools:
• Nios II software build tools GUI• Nios II software build tools build scripts
Verification Steps
• Check the generated makefile:
• Manually inspect that the makefile includes all required sources.• Use the BSP editor GUI to check which sources and libraries are included in the application
For more information, refer to the Nios II Software Developers Handbook v11.0:
• Section I. Nios II Software Development• Chapter 1 Nios II Programs• Chapter 2 Getting Started with the Graphical User Interface
Developing Application SoftwareDuring this step you develop your safety application code. You can implement the code within the Nios IISBT Eclipse environment and use items such as the built in editor.
7-2 Creating an Application FrameworkMNL-1079
2013.11.19
Altera Corporation Software Development with the Nios II Processor
Send Feedback
Suggested tools:
• Nios II Software Build Tools GUI: Integrated editor
For more information, refer to the Nios II Software Developers Handbook v11.0:
• Section I. Nios II Software development• Chapter 1 Overview of Nios II Embedded Development• Chapter 2 Getting Started with the Graphical User Interface
Integrating Software and HardwareYou can use the Nios II software build tools environment to debug your software running on the targethardware, which allows you to set code breakpoints, step into or over functions. Alternatively, you cancreate a programming file that you can load into your hardware that allows you to test the softwarewithout the debugger connected.
Suggested tools:
• Nios II software build tools GUI: GNU Debugger
For more information, refer to the Nios II Software Developers Handbook v11.0:
• Section I. Nios II Software Development• Chapter 2 Getting Started with the Graphical User Interface
Tools and Libraries included in the ISO26262 QualificationTable 7-1: Tools and Libraries Included in ISO26262 Qualification
The table shows the tools and libraries that Altera is evaluating as part of the ISO26262:2011-2012 qualification.Tool Name Description Tool Type Code Base
BSP Wizard GUI-based, creates BSPfrom Qsys .sopcinfo file.
TCL3 Altera
BSP Editor GUI-based, adjusts BSPsettings.
TCL3 Altera
Nios II SW drivers Library of software driversfor Qsys components.
Library Altera
Nios II HAL Hardware abstractionlayer (HAL) for the Nios IIprocessor.
Library Altera
Conversion Utilities Converts the final outputto flash programming files.For example. .hex format.
TCL3 Altera
MNL-10792013.11.19 Integrating Software and Hardware 7-3
Software Development with the Nios II Processor Altera Corporation
Send Feedback
Tool Name Description Tool Type Code Base
Build Scripts Command-line, createsBSP from Qsys .sopcinfofile.
TCL3 Altera
Debug Utilities Assists with system debug.For example, Nios2terminal, gdb server.
TCL2 Altera
The ISO26262:2011-2012 qualification only includes the hardware, software device drivers and HAL APIlayers. Refer to the Nios II Software Developers Handbook v11.0, Figure 7-1, Layered Software Model. TheISO26262:2011-2012 qualification excludes other layers. Refer to Chapter 7 Developing Device Drivers forthe Hardware Abstraction Layer for specific restrictions of use.
Third-party Tools and Libraries Excluded in the ISO26262 QualificationThe Nios II software build tools rely on the following third-party tools, which are not part of the Alteraqualification. You should provide your own evidence of the suitability of these tools (and particularversions) as part of your product certification.
Table 7-2: Tools not Included in ISO26262 Qualification
Tool Name Tool Type Code Base
Eclipse Environment TCL2 / TCL1 Eclipse
GNU Make TCL3 GNU
GNU Compiler TCL3 GNU
GNU Linker TCL3 GNU
GNU Binutils TCL2 GNU
Assembler TCL3 GNU
Debugger TCL2 GNU
Newlib Library GNU
7-4 Third-party Tools and Libraries Excluded in the ISO26262 QualificationMNL-1079
2013.11.19
Altera Corporation Software Development with the Nios II Processor
Send Feedback
Supported (V)HDL versions 82013.11.19
MNL-1079 Subscribe Send Feedback
Altera tools support the following (V)HDL versions:
• VHDL 1987• VHDL 1993• Verilog HDL 1995• Verilog HDL 2001• SystemVerilog HDL 2005 (synthesis subset only)
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts 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 devicespecifications before relying on any published information and before placing orders for products or services.
ISO9001:2008Registered
www.altera.com101 Innovation Drive, San Jose, CA 95134