Automotive Safety Manual - Altera · HPS SD/MMC Controller ... 4-15 Documentation of Synthesis...

Cyclone V SoCsAutomotive Safety Manual

Subscribe

Send Feedback

MNL-10792013.11.19

101 Innovation DriveSan Jose, CA 95134www.altera.com

https://www.altera.com/servlets/subscriptions/alert?id=MNL-1079

mailto:[email protected]?subject=Feedback%20on%20Cyclone%20V%20SoCs%20Automotive%20Safety%20Manual%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

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


mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Introduction%20to%20Cyclone%20V%20SoCs%20and%20Safety&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

http://www.altera.com/support/devices/reliability/certifications/rel-certifications.html



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

mailto:[email protected]?subject=Feedback%20on%20Introduction%20to%20Cyclone%20V%20SoCs%20and%20Safety%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

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

mailto:[email protected]?subject=Feedback%20on%20Introduction%20to%20Cyclone%20V%20SoCs%20and%20Safety%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Systematic Fault Management 22013.11.19


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).





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Systematic%20Fault%20Management&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




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

mailto:[email protected]?subject=Feedback%20on%20Systematic%20Fault%20Management%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

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


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


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


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


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


• None

MNL-10792013.11.19 Creating Design Description for Logical Module Design 2-7


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.


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)


• 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


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


• 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


• 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


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)


• 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


Send Feedback



• 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)


• 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


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


• 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


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


• 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:


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


Send Feedback



• 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


• 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


Send Feedback



• 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


• 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


Send Feedback



• 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


• 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


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:


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


Send Feedback



• 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


• 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


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


• 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


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


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:


MNL-10792013.11.19 Quartus II In-System Memory Editor 2-21


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


Send Feedback


Architecture for Random Hardware FaultManagement 3

2013.11.19


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





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Architecture%20for%20Random%20Hardware%20Fault%20Management&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




(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

mailto:[email protected]?subject=Feedback%20on%20Architecture%20for%20Random%20Hardware%20Fault%20Management%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

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




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.


• Volume 3: Hard Processor System Technical Reference Manual• Chapter 2: Clock Manager


• 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.


• 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


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


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


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


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


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


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


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


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


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


Send Feedback


Table 3-9: ISO26262 Reference: Comparator

Source Reference

ISO26262-5:2011 Annex D Table D.2 Comparator


Related InformationClock Checker Diagnostic IP Core on page 3-7

Clock Assumptions of Use

Table 3-10: Clock Assumptions of Use



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‐


3-8 Clock Assumptions of UseMNL-1079

2013.11.19


Send Feedback




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‐


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


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.


• 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




3-10 FPGA ResetMNL-1079

2013.11.19


Send Feedback



Source Reference



HPS Reset Assumptions of Use

Table 3-12: Reset: Assumptions of Use



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.


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


Send Feedback



• 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.


• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manager


• 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.


• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 22: General-Purpose I/O Interface





Source Reference


3-12 HPS I/OsMNL-1079

2013.11.19


Send Feedback


Source Reference


I/Os Assumptions of Use

Table 3-14: I/Os: Assumptions of Use



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.


• 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


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.


• Volume 1: Device Interfaces and Integration• Chapter 8: SEU Mitigation in Cyclone V Devices

3-14 Sensitivity MapMNL-1079

2013.11.19


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



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.


• 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



FPGA_UM1 ECC for user memory ++ 1. Fault injectiontesting

MNL-10792013.11.19 Implementing Redundant Logic 3-15


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


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


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


Send Feedback


Table 3-20: ISO26262 Reference: Test Pattern

Source Reference

ISO26262-5:2011 Annex D Table D.14 Test pattern






Source Reference



Interconnect Assumptions of Use

Table 3-22: Interconnect Assumptions of Use



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


HPS_BUS3 External Watchdog ++ 1. Internal watchdog2. Software test of


HPS_BUS4 Information redundancy ++ 1. Test of CRC engine

MNL-10792013.11.19 Periodic Reading Back of Configuration Registers 3-17


Send Feedback




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).


• 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


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


Send Feedback


Table 3-24: Source Reference

Source Reference



Using a Watchdog



Source Reference


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.


Source Reference







Source Reference


MNL-10792013.11.19 Using a Watchdog 3-19


Send Feedback


Source Reference


Interconnect Assumptions of Use

Table 3-28: Interconnect Assumptions of Use



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


HPS_ FPGA_BUS3 External watchdog ++ 1. Internal watchdog2. Software test


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.


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


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.


• 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


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


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


Send Feedback


Source Reference


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


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


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


Send Feedback


Source Reference

ISO26262-6:2011 Table 3 Restricted use of interrupts

Using a Watchdog



Source Reference


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


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.


Source Reference



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


Send Feedback



Source Reference



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)



• 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


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


3-24 Generic Interrupt ControllerMNL-1079

2013.11.19


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


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


• 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


Send Feedback

http://infocenter.arm.com


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.


Source Reference



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.


• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 23: Timer





3-26 Snoop Control UnitMNL-1079

2013.11.19


Send Feedback




Source Reference



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.



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



CA9_MPU1 Processor selftest bysoftware

++ 1. Watchdog

MNL-10792013.11.19 Internal and External Watchdog 3-27


Send Feedback





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


Send Feedback




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


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.


• Volume 3: Hard Processor System Technical Reference Manual• Section IV: Debug and Trace





Source Reference



Debug and Trace Assumptions of Use

Table 3-50: Debug and Trace Assumptions of Use



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


Send Feedback




DBG3 Periodic configurationregister test


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.


Source Reference



MNL-10792013.11.19 HPS SDRAM Controller 3-31


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


• 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






Source Reference


3-32 Using Memory ProtectionMNL-1079

2013.11.19


Send Feedback


Source Reference


SDRAM Assumptions of Use

Table 3-55: SDRAM Assumptions of Use



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


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.


Source Reference

ISO26262-5:2011 Annex D Table D.6 Memory monitoring using EDC

MNL-10792013.11.19 SDRAM Assumptions of Use 3-33


Send Feedback


Source Reference



• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 14: System Manger

Performing CRC



Source Reference







Source Reference


3-34 Performing CRCMNL-1079

2013.11.19


Send Feedback


Source Reference


On-Chip RAM Assumptions of Use

Table 3-59: On-Chip RAM Assumptions of Use



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


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



Source Reference


MNL-10792013.11.19 On-Chip RAM Assumptions of Use 3-35


Send Feedback


Source Reference


On-Chip Boot ROM Assumptions of Use

Table 3-61: On-Chip Boot ROM: Assumptions of Use



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.


• 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


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


Send Feedback




Performing CRC



Source Reference







Source Reference



NAND Controller Assumptions of Use

Table 3-65: NAND Controller Assumptions of Use



NAND1 ECC ++ 1. Fault injectiontesting

NAND2 CRC checksum ++ 1. Test pattern forCRC engine

MNL-10792013.11.19 Performing CRC 3-37


Send Feedback




NAND3 Periodic configurationregister test


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.


• 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


Injecting Faults




Performing CRC


3-38 HPS SD/MMC ControllerMNL-1079

2013.11.19


Send Feedback



Source Reference







Source Reference



SD/MMC Controller Assumptions of Use

Table 3-69: SD/MMC Controller Assumptions of Use



SDMMC1 ECC ++ 1. Fault injectiontesting

SDMMC2 CRC checksum ++ 1. Test pattern forCRC engine

SDMMC3 Periodic configurationregister test


HPS Quad SPI Flash ControllerThe HPS provides a quad serial peripheral interface (SPI) flash controller for access to serial NOR flashdevices.



Send Feedback



• 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.


Source Reference



Injecting Faults




Performing CRC



Source Reference





3-40 SECDEDMNL-1079

2013.11.19


Send Feedback




Source Reference



Quad SPI Flash Controller Assumptions of Use

Table 3-73: Quad SPI Flash Controller: Assumptions of Use



QSPI1 ECC ++ 1. Fault injectiontesting

QSPI2 CRC checksum ++ 1. Test pattern forCRC engine

QSPI3 Periodic configurationregister test


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


Send Feedback



• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 13: FPGA Manager





Source Reference



FPGA Manager Assumptions

Table 3-75: FPGA Manager Assumptions



FMGR1 Monitor block + 1. Monitor signalsduring FPGAconfiguration

FMGR2 Periodic configurationregister test


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


Send Feedback








Source Reference



System Manager Assumptions of Use

Table 3-77: System Manager Assumptions of Use



SYSMGR1 Periodic configurationregister test


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



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.


• 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





Source Reference


3-44 Tying off JTAG SignalsMNL-1079

2013.11.19


Send Feedback


Source Reference


Scan Manager Assumptions of Use

Table 3-79: Scan Manager Assumptions of Use



SCMGR1 Tie-off JTAG signals ++ 1. Set dbg bit inmiscmodrst registerof reset manager

SCMGR2 Periodic configurationregister test


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.


• 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.


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


Send Feedback


Source Reference




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



• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 16: DMA Controller





Source Reference


3-46 Abort HandlingMNL-1079

2013.11.19


Send Feedback


Source Reference


DMA Controller Assumptions of Use

Table 3-83: DMA Controller Assumptions of Use



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


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).


• 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


Send Feedback



Source Reference




• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 17: Ethernet Media Access Controller



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.


Source Reference



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.


Source Reference


3-48 Testing I/O InterfaceMNL-1079

2013.11.19


Send Feedback


Source Reference






Source Reference



Ethernet MAC Assumptions of Use

Table 3-88: Ethernet MAC Assumptions of Use



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




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.


• 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.


Source Reference




• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 18: USB 2.0 OTG Controller




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


Source Reference


3-50 HPS USB 2.0 OTG ControllerMNL-1079

2013.11.19


Send Feedback


Source Reference





Source Reference







Source Reference



USB 2.0 OTG Controller Assumptions of Use

Table 3-93: USB 2.0 OTG Controller Assumptions of Use



USB1 SECDED (ECC) ++ 1. Running of testpattern to testdetection andcorrection function‐ality

MNL-10792013.11.19 Implementing Information Redundancy 3-51


Send Feedback




USB2 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results

USB3 Information redundancy ++ 1. Test pattern

USB4 Periodic configurationregister test


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).


• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 19: SPI Controller


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





3-52 HPS SPI ControllerMNL-1079

2013.11.19


Send Feedback



Source Reference







Source Reference



SPI Controller Assumptions of Use

Table 3-97: SPI Controller Assumptions of Use



SPI1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results

SPI2 Information redundancy ++ 1. Test pattern

SPI3 Periodic configurationregister test




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.


• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 20: I2C Controller


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






Source Reference


3-54 HPS I2C ControllerMNL-1079

2013.11.19


Send Feedback


Source Reference






Source Reference



I2C Controller Assumptions of Use

Table 3-101: I2C Controller Assumptions of Use



I2C1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results

I2C2 Information redundancy ++ 1. Test pattern

I2C3 Periodic configurationregister test


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.



Send Feedback



• Volume 3: Hard Processor System Technical Reference Manual• Section VI: Peripherals• Chapter 21: UART Controller


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.


Source Reference






Source Reference






3-56 Testing I/O InterfaceMNL-1079

2013.11.19


Send Feedback



Source Reference



UART Controller Assumptions of Use

Table 3-105: UART Controller Assumptions of Use



UART1 I/O Interface test ++ 1. Read back statuswith the secondCortex-A9processor andcompare results

UART2 Information redundancy ++ 1. Test pattern

UART3 Periodic configurationregister test


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.


• 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


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.






Source Reference



HPS Timer Assumptions of Use

Table 3-107: HPS Timer Assumptions of Use



HTIM1 Timer cross-check + 1. Test pattern

HTIM2 Periodic configurationregister test


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


Send Feedback





Testing Watchdog

Test the watchdog at application startup. Configure the watchdog and allow it to time out to ensure itgenerates a reset.


Source Reference






Source Reference



HPS Watchdog Timer Assumptions of Use

Table 3-110: HPS Watchdog Timer Assumptions of Use



HWD1 Test pattern + 1. External Watchdog2. Watchdog in FPGA

fabric

MNL-10792013.11.19 Testing Watchdog 3-59


Send Feedback




HWD2 Periodic configurationregister test


HPS CAN ControllerThe HPS provides two CAN controllers. The CAN controllers are instances of the Bosch® D_CANcontroller and compliant with ISO 11898-1.


• 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.


Source Reference





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


Send Feedback



Source Reference






Source Reference







Source Reference


MNL-10792013.11.19 Implementing Information Redundancy 3-61


Send Feedback


Source Reference


CAN Controller Assumptions of Use

Table 3-115: CAN Controller Assumptions of Use



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


3-62 CAN Controller Assumptions of UseMNL-1079

2013.11.19


Send Feedback


ISO26262 Specific Techniques and Measuresfor FPGA Design 4

2013.11.19


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





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20ISO26262%20Specific%20Techniques%20and%20Measures%20for%20FPGA%20Design&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




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


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

mailto:[email protected]?subject=Feedback%20on%20ISO26262%20Specific%20Techniques%20and%20Measures%20for%20FPGA%20Design%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

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


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:


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


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


Send Feedback

http://gcc.gnu.org/


Source Reference

ISO26262-5:2011 Section 7.4.4


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


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


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


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


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


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


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


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


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


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


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


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


Send Feedback

http://gcc.gnu.org/gcc-4.1/changes.html

http://www.gnu.org/software/make/

http://www.eclipse.org/platform/


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


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.


• Volume 1: Design and Synthesis• Section 4: Synthesis

4-12 Documentation of Simulation ResultsMNL-1079

2013.11.19


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


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


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


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


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


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


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


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


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:


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


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


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


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



MNL-10792013.11.19 Script -based Procedures 4-19


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


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


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:


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


Send Feedback


Source Reference

ISO26262-5:2011 Section 7.4.1.6


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.


• 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


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


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



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


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:


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


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


Send Feedback


Source Reference


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


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


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


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


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


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


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


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


Source Reference

ISO26262-10:2012: Table A.8 NA

ISO26262-5:2011 NA


Suggested Tool NA

MNL-10792013.11.19 Final Verification and Validation of the FPGA Prototype in the System 4-29


Send Feedback

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


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


Send Feedback


Known Problems in the Altera Tools andSoftware 5

2013.11.19


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





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Known%20Problems%20in%20the%20Altera%20Tools%20and%20Software&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

http://www.altera.com/literature/lit-rn-q2_archive.jsp

http://www.altera.com/literature/lit-es.jsp




Development Interface Agreement 62013.11.19


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.





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Development%20Interface%20Agreement&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




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

mailto:[email protected]?subject=Feedback%20on%20Development%20Interface%20Agreement%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Safety Lifecycle Activity Altera Customer

Verification of FPGA hardwaredesign

No Yes

Evaluation of HPS architecturalmetrics

Support provided Yes

Evaluation of FPGA architec‐tural metrics


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


Confidence in the use of SWtools


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


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.





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Software%20Development%20with%20the%20Nios%20II%20Processor&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




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

mailto:[email protected]?subject=Feedback%20on%20Software%20Development%20with%20the%20Nios%20II%20Processor%20(MNL-1079%202013.11.19)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Suggested tools:

• Nios II Software Build Tools GUI: Integrated editor


• 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


• 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


Altera tools support the following (V)HDL versions:

• VHDL 1987• VHDL 1993• Verilog HDL 1995• Verilog HDL 2001• SystemVerilog HDL 2005 (synthesis subset only)





mailto:[email protected]?subject=Feedback%20on%20(MNL-1079%202013.11.19)%20Supported%20(V)HDL%20versions&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




Automotive Safety Manual - Altera · HPS SD/MMC Controller ... 4-15 Documentation of Synthesis...

Documents

Transcript of Automotive Safety Manual - Altera · HPS SD/MMC Controller ... 4-15 Documentation of Synthesis...