Objectives of the new StandardIEC 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
• -gt Increasing integration and capabilities of CEC
  raises new technical issues,
• -gt 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
• -gt 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
• DSS Data Systems Solutions
• AREVA
• MGPI Merlin Gérin Provence Instruments
• CEA Commissariat à lEnergie 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 -gt functions move from software to
  hardware (e.g. protocols like HDLC, ARINC 629).
  
• gt 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..)?
• gt but hardware issues still need focus (clock
  skew, meta-stability, glitches, power drops,)?
• Complex components functionalities cannot be
  tested for all possible cases
• gt need for specific actions to reduce the
  potential for unrevealed design faults
• gt 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
• gt 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
• gtselection 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

8
Status of the draft
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 -gt 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
• -gt 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..)
• -gt the constraints file must be carefully
  verified

14
Design with HDL

• Different synthesizers may interpret differently
  some RTL constructs (dont 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 -gt
  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..
• -gt 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 IC 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 -gt 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