This paper proposes an acceptance
This paper proposes an acceptance process and evaluation criteria, specialized for the dedication of indirect COTS SW as well as direct ones. (Step 1) It first recognizes an indirect COTS SW as a target of dedication, unlike EPRI NP-5652/TR-106439. (Step 2) It then determines the safety category of the target SW and identifies detailed evaluation criteria for acceptance. We adopted and modified those from US.NRC NUREG/CR-6421 (1996). (Step 3) Acceptance methods and specific V&V techniques which can satisfy the evaluation criteria successfully are selected. It also can provide an explicit linkage from evaluation criteria identified in Step 2 to acceptance methods and V&V techniques selected in Step 3. The dedication with the acceptance methods then gets started. (Step 4) We can finally accept the target SW on the basis of the judgement whether the target SW satisfies its evaluation criteria or not, thorough various information and evidences which we can gather after getting through with the acceptance methods.
We also performed a case study with a commercial FPGA logic synthesis tool – ‘Synopsys Synplify Pro’ which are being used to develop a prototype (Choi and Lee, 2012) of digital I&C in Korea. We tried to perform the COTS SW dedication according to the proposed evaluation criteria and acceptance process, and received positive response from the experts who have to prepare the COTS SW dedication before long.
The paper is organized as follows: Section 2 introduces the FPGA development and verification processes as background. Section 3 explains and compares the relevant standards and reports. The evaluation criteria and acceptance process for COTS SW is proposed in Section 4. The case study with an indirect COTS software is introduced in Section 5, and Section 6 surveys related work and the state-of-the-art on the field of COTS SW dedication. Section 7 concludes the paper and provides remarks on future research extension and direction.
FPGA development and V&V processes The development life-cycle of FPGA-based digital I&Cs follows IEC 61513 (2011) basically. An FPGA-based system, however, has a specific feature that the part of development life Ro3280 using HDL (Hardware Description Languages) is classified into software, while after downloading to chip is classified into hardware. FPGA, therefore, should be developed to comply with both IEC 60880 (2006) in terms of software and IEC 60987 (2007) in terms of hardware. Fig. 1 depicts the V-shaped life-cycle of FPGA development explained in IEC 62566 (2012), consisting of software and hardware aspects. The software aspect also has a typical development life-cycle (NUREG/CR-7006, 1996) presented on the left-hand side of the figure. The FPGA software development is fully automated by FPGA logic synthesis tools and commercial EDAs of FPGA vendors. After programming an RTL (Register-Transfer Level) design with HDLs, the design is transformed into a gate-level design (i.e., netlist) by synthesis software such as ‘Synopsys Synplify Pro’, ‘Precision RTL’ and ‘Encounter RTL Compiler’. The EDAs of FPGA vendors such as ‘Xilinx ISE Design Suit’, ‘Altera Quartus 2’ and ‘Microsemi Libero SoC’ perform P&R to physically place and map all netlist elements and prepare a downloadable file through configuration. At each step of the FPGA software development life-cycle, designers perform ‘simulation-based verification’ in order to confirm that each artifact satisfies its requirements specification. The first simulation on RTL designs is called ‘behavioral simulation’ and aims to confirm that all requirements are implemented into the RTL design correctly. As most designers develop RTL designs manually, Ochre codon takes much time. After logic synthesis from RTL to Gate-level design, designers perform ‘logic simulation’ in order to confirm that all functionalities were preserved during the synthesis. After P&R, they can validate the layout via ‘post-layout simulation’ to check that the layout meets all timing requirements. Simulators such as ‘ModelSim’ (Mentor Graphics, 2015b) and ‘Questa Simulator’ (Mentor Graphics, 2015c) are widely used for the ‘simulation-based verification’. Every simulation-based verification at each step is performed individually and independently, and it is considered as one of key factors for efficient FPGA development.