Objectives of the new Standard IEC 62566 Draft status

1. Objectives of the new Standard�IEC 62566 Draft status IEC 62566 : �Selection and use of complex electronic components for systems performing category A functions� Motivations Project history Goals of the Standard Status of the draft Conclusion

2. Motivations CEC : Complex Electronic Component (i.e. FPGA, ASIC, Multicore microprocessors..) Safety systems rely more and more on digital equipment (new plants, modernization) Introduction of CECs (types and capabilities) from 74� logic chips and PALs to multi-million gates FPGAs, Systems On Chip from traditional microprocessors to multi-core units from simple CPU boards to units with network interfaces, USB ports, BIOS, automatic configuration� -> Increasing integration and capabilities of CEC raises new technical issues, -> Need for a dedicated standard. This presentation focuses on programmable electronics, although IEC 62566 addresses also other types of CEC

3. Project history Decision in IEC meeting, October 2006, Lyon. French committee to make a proposal for a standard dedicated to complex electronic -> address their selection and use (e.g. �programming� an FPGA),  but not their design (e.g. �FPGA chip�) An ad hoc working group has prepared: NWIP (New Work Item Proposal) Working Draft (IEC meeting in London, 2008) CD1 (Committee Draft), August 2008 (comments due for end of October 2008) Target : Standard to be issued in 2011

4. Experts of the ad hoc working group Manufacturers DS&S : Data Systems & Solutions AREVA MGPI : Merlin G�rin Provence Instruments CEA : Commissariat � l�Energie Atomique Utility EDF : Electricit� de France TSO IRSN : Institut de Radioprotection et de S�ret� Nucl�aire

5. Safety issues Increased capabilities of programmable electronic components -> functions move from software to hardware (e.g.: protocols like HDLC, ARINC 629�). > non trivial �software� issues hardware engineers may not be aware of (complete and correct specification, correct implementation, test coverage, proofs..)? Components are �programmed like software� (VHDL, work stations, simulation..)? > but hardware issues still need focus (clock skew, meta-stability, glitches, power drops,�)? Complex components functionalities cannot be tested for all possible cases: > need for specific actions to reduce the potential for unrevealed design faults > verification must be taken into account since the very beginning of the design Less observability because interconnections between different circuits disappear when they are packed into a single one > testability needs special attention

6. Scope Class 1 (to limit the size of the standard, and to meet IEC schedule) Pre-developed hardware is essential in electronic design >selection and use of different kinds of components development of the component itself is out of scope (e.g., the FPGA chip)? The standard addresses the level where the components are used, e.g: Implementation of functions in a programmable circuit (FPGA, CPLD..) Use of a multi-core microprocessor in a system Use of a complex pre-developed board with built-in-software Applicability to a given component: based on its influence on safety e.g. : FPGA implementing a protection function logic vs. one driving a test function

7. Related standards and documents RTCA DO 254. Design assurance guidance for airborne electronic hardware - confidence mainly based on multiple processes - verification methods for Levels A and B include test criteria (�elemental analysis�)? �A hardware item is identified as simple only if a comprehensive combination of deterministic tests and analyses appropriate to the design assurance level can ensure correct functional performance under all foreseeable operating conditions with no anomalous behavior� DOT/FAA/AR-95/31 Design, Test, and Certification Issues for Complex Integrated Circuits (Federal Aviation Administration)? identifies many certification issues (based on experience)? �new threats from an old technology� European Space Agency : ASIC Design and Manufacturing Requirements applies to all types of programmed electronics, including FPGA requirements on both process and product many requirements coming from experience feedback with FPGAs

9. Life-cycle Approach consistent with other IEC/45A standards Top-down design Verification Technical reviews Lifecycle interfaced to the system lifecycle (IEC 61513)? Starts from the component requirement specification Joins the system lifecycle at integration and validation

10. Specification of requirements Must address: Functions, interfaces, parameters, algorithms, protocols� Accuracy, timings � Modes, transitions (e.g. state after power-on) Deterministic behavior by design, for reproducibility of tests Fault detection and tolerance (internal and/or external), requirements for defensive design

11. Design with HDL � Principles Design involving complex programmable circuits such as FPGA, Complex PLD, ASIC, SoC, is typically performed using Hardware Description Languages (HDL) and design tools on workstations Preliminary design Organization in sub-parts, identification of libraries to be used, of IP cores, � Design -> produces an RTL description Languages such as VHDL, Verilog Parallel description of the intended behaviour (signals, clocks, arithmetic and logical operators, state machines..) Handling of different electronic types Handling of large projects, libraries, modularity�

12. Design with HDL The draft provides requirements to favor: Determinism, testability.. The completeness of the design: management of all modes including reset, power-on, test pins.. The coverage of the verification: functional coverage of the test cases, integration of the timing information after implementation..

13. Design with HDL Implementation (1) : synthesis Translates the RTL description into a scheme of interconnected gates (Netlist) The set of available gates depends on the target technology basic gates OR,AND / counters / ALU / complex blocs / etc� Synthesis is very different from software compilation. Needs actions from a skilled engineer. E.g. : some synthesizers may recognize/accept constructions rejected by others -> need for programming rules E.g. : any time constraint between I/O signals must be explicitly specified Typically hundreds or more constraints must be specified If one misses, the circuit may fail in some cases (combination of inputs and process variations..) -> the �constraints file� must be carefully verified

14. Design with HDL Different synthesizers may interpret differently some RTL constructs (�don�t care� value, incomplete �case list�, �) Need to know the synthesizer behaviour and to enforce adequate RTL coding rules Synthesis may modify the logic scheme Optimizer may remove intentional redundancies or random fault detectors.. It may duplicate gates to accommodate electrical loads or to reduce propagation times -> introduces new failure modes (inconsistencies between replications) Gate level analysis is necessary to track these issues. Equivalence with RTL description must be confirmed.

15. Design with HDL Implementation (2) : Place and route assigns to each gate a location on the physical circuit determines the paths of the interconnections between gates. This may be extremely difficult (huge interconnection number but density limited by technology rules + distance between cells impacts loads and propagation delays) may need to modify the Netlist (e.g. replicate cells to reduce interconnection density or delays) implementation is not deterministic extremely complicated process (millions of antagonist constraints : each cell needs to be close to many others..) optimal solution not reachable, search for near-optimal ones, based on multiple algorithms and heuristics using random numbers.. -> verifications must be performed again after any re-implementation

16. Design with HDL � Test-bench 1 Test-bench: developed with the same HDL than the RTL design, in order to test it by simulation This HDL program encapsulates the RTL description, provides it with input sequences and observes its outputs It may use any HDL construct, including non synthesizable ones such as access to files, prints, explicit time management� The test-bench must include the test-cases and the comparison of the behaviour to the expected one (animation ? test) Manual interpretation of the behaviour is extremely difficult (observing hundreds or thousands signals cycle by cycle..)

17. Design with HDL � Test-bench 2 The test-bench is used to test by simulation the RTL description, and can be associated to various tools for test generation and coverage measurement After synthesis, place and route, the RTL description is replaced by the synthesized Netlist (expressed in HDL) within the test bench, to confirm the functional equivalence After synthesis, place and route, the timing and load information computed by the tools must be added to the description (�back-annotation�), to confirm the correctness of the timing

18. Verification - Reviews Depending on the CEC type, specific requirements apply (e.g. test bench for HDL design, gate-level analysis for ASIC based on standard cells, Static Timing Analysis..) Reviews must be technically oriented (not only checking that someone has checked..) This implies providing the documentation to the reviewers before the review with enough time to study it The review team must include experts in electronics, as well as process et I&C engineers as necessary

19. Software tools Requirements for: Language standardization (VHDL, Verilog..) Semantics consistent across tools/phases (ESL, RTL, Synthesis, Place & Route). Not obvious for requirement capture tools (e.g. SystemC) Synthesized circuit as close as possible to the RTL description Engineers should be able to predict the tools behaviour -> consistency and stability over tool versions

20. Conclusion The proposed draft: targets similar reliability for CEC than for software components details IEC61513 system requirements regarding CEC complements IEC60987 when CEC are involved, contributes to CCF avoidance. Requires clear and complete documentation thus IEC62340 requirements at system level can be applied effectively covers Pre-Developed Hardware selection covers Built-In-Software of three different types covers Multicore microprocessors specificities covers HDL design (FPGA, PLD, ASIC...) Target : Standard in 2011