Competition question 1: Function vector sequential circuit fault simulator
Sponsor: Ministry of Industry and Information Technology, Jiangsu Provincial People's Government, Hunan Provincial People's Government
Organizer: Open Atom Open Source Foundation, CCTV Network, Jiangsu Provincial Department of Industry and Information Technology, Wuxi Municipal People's Government, Jiangsu Software Industry Talent Development Foundation, Suzhou Industrial Park, Wuxi High-tech Zone, etc.
Co-organizer: openDACS Working Committee, Institute of Computing Technology, Chinese Academy of Sciences, Institute of Microelectronics, Chinese Academy of Sciences, Peking University, Fudan University, Tsinghua University, Beijing Open Source Chip Research Institute, Shenzhen Micro-Nano Research Institute, Shenzhen Huaqiu Electronics Co., Ltd.
This competition focuses on: The areas of digital design, analog design, chip manufacturing, chip packaging, processor design automation, and generative chip design in the integrated circuit industry are of great significance to promoting high-quality development of the industry.
This competition includes: There are a total of 10 questions in five directions.
Question issuing unit: openDACS Working Committee SIG1 Design Verification & Test Synthesis
Competition title Chair: Li Huawei
1. Competition background
Fault simulation is an important step in chip testing and an important part of the test vector generation system (ATPG) and fault diagnosis. It is mainly used to simulate the behavior of the faulty circuit and evaluate the test vector's ability to detect possible faults within the circuit. Simply put, fault simulation is to determine whether the fault under test can be detected by comparing the logic simulation results of a fault-free circuit and a faulty circuit under a specific test vector.
During the manufacturing process of chips, they are inevitably affected by various uncontrollable factors, resulting in various defects in the manufactured chips. For defects that exist inside the chip, in order to detect defects using automated methods such as fault simulation and to quantify the quality of defect detection, defects are usually abstracted into various fault models, such as stuck-at fault, transition delay fault, path delay fault, etc. Among them, the most commonly used fault model is fixed fault. As shown in Figure 1, assume that the input node b of the AND gate has a stuck-at-1 (abbreviated SA1) fault. When we apply excitations to nodes a and b at the same time (a=1, b=0), the expected output of node c is "0", but due to the existence of this fault, the actual output of node c is "1", which means that the SA1 fault at node b is detected by the test vector (a=1, b=0). This is a simple process of fault simulation.
Function vector is a type of test vector. It is a vector generated under the functional operating conditions of the circuit. It is used to test the internal state of the circuit and detect possible manufacturing defects in the circuit. Different from structural test vectors (also called scan vectors), functional vectors are essentially timing vectors, with different vector input values on different clock cycles of the time axis, and the logic state of the internal nodes of the circuit depends on the simulation results input in previous clock cycles. This also means that for fault simulation of functional vectors, the bit-parallel methods commonly used for structural test vector simulation cannot be used. At the same time, the function vector may cover the circuit operation process of tens of thousands or even millions of clock cycles, which also makes fault simulation for the function vector very time-consuming.
This competition question aims at single fixed faults in gate-level sequential circuits, using functional vectors to simulate faults. The participating teams are required to select appropriate algorithms and use performance optimization methods such as parallel simulation as much as possible to provide high-performance functional safety assessment. Figure 2 shows a simple flow diagram of gate-level fault simulation of function vectors.
2. Description of competition questions
2.1 Description
This competition question requires participating teams to combine their understanding of function vectors and fault simulation to design a C++ program. The program should be able to read the gate-level netlist, ATPG library, fault list, function vector and other files provided by the competition party, and complete the fault simulation of the function vector by correctly parsing and processing the files. The program output is a list of detected faults and a list of undetected faults.
Among them, participating teams need to complete the following points:
(1) Correctly read the netlist file and combine it with ATPG
library information, convert the standard cell netlist into a netlist structure suitable for simulation.
(2) Correctly read the fault list file, combine the fault list information, and insert the corresponding fault at the correct position in the netlist.
(3) Correctly read the function vector file to obtain the excitation of the corresponding input node and the expected response of the output node.
(4) Carry out logic simulation of the fault-free circuit and obtain the fault-free simulation value of the internal node of the circuit at the corresponding clock node.
(5) Carry out fault simulation, measure the actual response of the circuit output node at the corresponding clock node, and determine whether the fault can be detected by the current function vector based on the comparison between the expected response and the actual response.
(6) According to the results of fault simulation, the detected fault list and the undetected fault list are output respectively.
This competition question allows participating teams to use multi-threading for parallel acceleration based on the specific needs of the algorithm. Considering that the development hardware environments of participating teams are inconsistent, for the sake of fairness, the maximum number of threads used in this competition is limited to 4.
2.2 Competition Case
The project co-builder provides the team with the project case to verify and optimize the design. The following is a simple example of the provided file.
(1) Verilog planar netlist
The flat netlist consists of a module, which defines the input nodes, output nodes, instantiated standard cells and other information of the circuit. The co-creator of the competition question provided the open source Verilog netlist parser to the participating teams for reference, and also allowed the participating teams to use their own developed parser.
Figure 3 gives an example.
(2) ATPG library
The ATPG library provided for this competition adopts JSON (JavaScript Object Notation) format. JSON is a simple data exchange format that has proven to be useful and simple enough. For example, an AOI unit is represented in the following way, and other units are also represented using the same structure.
Figure 4 shows an example of the JSON description of ATPG library. Each standard unit contains 3 attributes: name, signals and sim_primitives.
name: array form, containing multiple unit names with the same logical function but different driving capabilities; signals: contains three types of signals, input, output and wire; sim_primitives: One or more custom units. Each custom unit includes two attributes, sim_type and connection, which respectively represent the type and connection relationship of the unit. The first signal in connection is the output, and the rest are inputs.
(3)Fault list
The format of the fault list is very simple, and only contains the fault type (sa0 or sa1), fault detection status (NP, DT, ND or --, where NP means not analyzed, DT means detected, ND means not detected, - means that the current fault is equivalent to the above fault. In the input fault list, all faults are in the NP state) and fault location (the instantiation name of the standard unit and the corresponding pin name).
Figure 5 shows a simple example, which contains three faults, located at the Y pin and A pin of the instantiated standard unit g84, and the circuit input node blif_reset_net, and these three faults are equivalent faults.
(4) Function vector
The function vector of this competition question adopts VCD (Value
Change Dump) file format. The VCD file is a standard waveform file. It is used in digital circuit simulation to record changes in signal values of designated circuit nodes and records the information of the entire simulation. It should be noted that for fault simulation of function vectors, if the clock nodes that measure the signal simulation values are different, the detected faults may be different. In order to ensure the consistency of results, participating teams are required to detect faults in the following ways: When the simulation value of a circuit input node changes, measure and compare the simulation value of the circuit output node once, and use the comparison result to determine whether the fault has been detected.
The example in Figure 6 is an excerpt from a VCD file. It is necessary to measure the simulation values of the circuit output node at 5ns, 10ns, and 15ns respectively and make comparisons. For the format description of VCD files, please refer directly to its standard definition file.
2.3 Output files
This competition question requires the participating team's program to output two files after completing the fault simulation, one to store the list of detected faults, and the other to store the list of undetected faults. The format of the output file should be consistent with the format of the fault list in the problem case provided by the problem co-creator.
2.4 Environment
It is recommended that participating teams use a C++ version compatible with C++20 for their development environment and operating environment, and develop under a Linux system environment. The reference software environment is given below.
• gcc 10.3.0
• g++ 10.3.0
• cmake 3.13.4
3. Scoring criteria
The co-creator of the competition has prepared test cases for this competition, and will select and provide some of the test cases to participating teams to evaluate the quality of the algorithm; the remaining cases are only for scoring purposes and will not be open to participating teams.
Test scoring: Each test case is scored independently and follows the same scoring criteria.
(1) The fault detection results of this competition are based on the results of commercial EDA tools as the golden results. If the results output by the participating teams are different from the golden results, the fault detection with differences will be considered to have failed. For each differentiated fault that occurs (an equivalent fault is calculated as one fault), 0.01 points will be added to the score. When the number of faults with differences exceeds 100 or exceeds 1% of the total fault list, it is considered that the participating team failed to simulate the fault of the current case, and the score in this case is n (n is the number of participating teams).
(2) If the case passes condition (1), assuming there are n participating teams, they will be sorted according to the total running time of the program. The first place will be worth 1 point, the second place will be worth 2 points, and so on, and the last place will be worth n points. In addition, an upper limit of 2 hours is set for the running time of a single test case. If it exceeds 2 hours, the running of the program will be terminated, and the participating team will be considered to have failed the fault simulation of the current case, and the score in this case will be n.
(3) When the case passes condition (1), if there is a case where the running time is the same, the scores will be scored according to the rule of the same score and increasing ranking. For example, if two teams have the same running time and both complete the fault simulation the fastest, then these two teams will be awarded 1 point, and the third team will be awarded 3 points.
After each case in the scored case set is scored, the total score is the weighted sum of the individual case scores, where the weight coefficient of an individual case is positively related to the size of the case. The team with the lower total score will be ranked higher.
Other ratings: design document quality, open source code standardization, etc.
4. Requirements for entries
4.1 Preliminary entries
Participating teams submit the design documents and source code of the competition question.
(1) The design document is required to be a PDF document. The technical implementation details should be written clearly in the document and the test results on the test cases should be provided, including the following points:
• Functional description
• Overall design framework
• Detailed design of functional modules
• Advantages and challenges of the solution
• Test results and data analysis
(2) The source code of the work must contain the following items:
• source code
• Compiled code binaries
• readme (basic description of the final submission algorithm, including operation mode, input format description, etc.)
• Dependent third-party libraries (if any, they need to be provided together to prevent differences in results due to different versions)
4.2 Final works
The participating teams will further improve their works on the basis of the preliminary works, such as improving the performance of key algorithms, optimizing the implementation of the code, enhancing the readability of the code, complying with the standardization of open source code, etc., and submit the final source code and design documents to participate in the finals.
4.3 Work submission channel
Before submitting their work, participating teams must send the team leader’s registered email address, user name, name, mobile phone number and other information on the official website of the competition to the staff of this competition (contact email: Johnhw_2019@qq.com, the subject of the email is named: "Team Name" warehouse application). The staff will create a private warehouse for the team on AtomGit and add the team leader as the warehouse administrator. After the participating teams complete their work, they can submit the relevant documents and source code of the work to the warehouse. The naming method for submitted works is: competition title + team name + title of work. AtomGit URL:https://atomgit.com/
5. Incentive Program
(1) One winner of the preliminary competition will be awarded a bonus of RMB 50,000; two winners of the Open Source EDA Rookie Award will be awarded RMB 5,000; each will be awarded a certificate.
(2) The winner of the preliminary competition will enter the finals of the open source EDA and chip competitions, and will have a finals road show in April 2024, with a chance to win the "openDACS Open Source Star" and an additional bonus of 20,000 yuan.
(3) Provide all Awards teams with internship opportunities at the Institute of Computing Technology of the Chinese Academy of Sciences, the Open Source Chip Research Institute, Pengcheng Laboratory, Zhongke Jianxin (Beijing) Technology Co., Ltd. and other units.
6. References
[1] L.-T. Wang , C.-W. Wu , and X.Wen. 2006. VLSI Test Principles and Architectures: Design for Testability (Systems on Silicon). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.
[2] H. Lee and D. Ha, "HOPE: an efficient parallel fault simulator for synchronous sequential circuits," in IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 15, no. 9, pp. 1048-1058, Sept. 1996.
[3] M. B. Amin and B. Vinnakota, "Data parallel fault simulation," in IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 7, no. 2, pp. 183-190, June 1999.
[4] S. Hadjitheophanous, S. N. Neophytou and M. K. Michael, "Scalable parallel fault simulation for shared-memory multiprocessor systems," 2016 IEEE 34th VLSI Test Symposium (VTS), Las Vegas, NV, USA, 2016, pp. 1-6.
[5] A. Bosio and G. D. Natale, "LIFTING: A Flexible Open-Source Fault Simulator," 2008 17th Asian Test Symposium (ATS), Hokkaido, Japan, 2008, pp. 35-40.
[6] W. K. Lam, Hardware Design Verification: Simulation and Formal Method-Based Approaches. Englewood Cliffs, NJ, USA: Prentice-Hall, 2008.
[7] L. Lai , Y. Yang , H. Li , X. Lin, Parallel Logic Simulation for Functional Test, Journal of Computer-Aided Design & Computer Graphics, 2023, 35(5): 803-810.
[8] TestMAX ATPG and TestMAX Diagnosis User Guide, Synopsys, Inc., Sunnyvale, California, USA, 2021.
[9] IEEE Standard Verilog Hardware Description Language, in IEEE Std 1364-2001, vol., no., pp.1-792, 28 Sept. 2001.
Appendix 1: General introduction to the 10 competition questions
This competition includes a total of 10 questions in five directions, as follows:
Digital chip EDA direction:
Competition question 1: Function vector sequential circuit fault simulator
Competition question 2: Incremental timing optimization algorithm
Competition question 3: FPGA process mapping algorithm and optimization
Analog chip EDA direction:
Competition question 4: Analog circuit optimization algorithm
Question 5: Automated design of operational amplifier
Chip manufacturing EDA direction:
Competition question 6: Device model reference based on BSIM-CMG model
Processor design automation EDA direction:
Question 7: ASIP’s hardened IP design based on OpenHarmony soft bus characteristics
Competition question 8: Silicon substrate interconnection design based on open source PDK
Generative chip design direction:
Competition question 9: Pipeline CPU design based on the automatic chip generation framework AutoChip (ChipGPT 2.0)
Competition question 10: AutoChip (ChipGPT 2.0) chip creative design
Appendix 2: Competition format/schedule
1. Competition process
- 2023.09 -2023.11 Publish each competition question on the official website of the competition, openDACS official account, and CCF Integrated Circuit Design Committee official account
- 2023.09.30 - 2024.2.28 Participating teams register for the competition, submit their works, and will be coached and improved by the question maker
- 2023.10.15 Q&A on the competition questions at the open source EDA special forum of CCFDAC2023 conference
- 2023.10.15 - 2023.12.30 Arrange lectures at designated units (Chinese Academy of Sciences, Peking University, Fudan, Tsinghua, Wuhan University of Technology, Shenzhen University of Technology, etc.); arrange 1-2 online lectures on electronic enthusiast websites
- 2024.03.31 The preliminary round review will select the champions and rookie awards of each topic, and the question maker will guide the champion team to improve.
- 2024.04.01 - 2024.04.15 Final works submission
- 2024.04 Final review, the ten competition champions were collected and selected to select 3 openDACS Open Source Star Awards
- 2024.06 (tentative) Open Atom Developer Conference, announces Awards list and offline awards
2. Competition consultation
Please join the participating teams in this competition's WeChat exchange group "openDACS Open Source EDA and Chip Competition", the WeChat group QR code:
If the WeChat group QR code expires, you can directly contact the person in charge of this competition on WeChat: WinPolestar to apply to join the communication group.
After the participating teams register and submit their works, they can send their registration information and entries to
Johnhw_2019@qq.com.
3. Instructions for participating teams
The requirements for the official start of this competition are: the number of registered teams reaches at least 10, and the number of submitted works reaches at least 5. If the number of registered teams or submitted works is not met, this competition may be postponed or suspended. At that time, the co-organizers of this competition (Institute of Computing Technology, Chinese Academy of Sciences, Institute of Microelectronics, Chinese Academy of Sciences, Peking University, Fudan University, Tsinghua University, Beijing Open Source Chip Research Institute, Shenzhen Micro-Nano Research Institute, Shenzhen Huaqiu Electronics Co., Ltd.) will send you a written notice.
Appendix 3: Work submission requirements
1. Content requirements for entries
For details on the specific work content requirements for each competition topic, please refer to the description of each competition topic in the "Competition Questions" column.
2. Specification requirements for entries
(1) Entries must meet the requirements and themes of this competition, and the title of the work should reflect the main features of the work.
(2) Entries must be original works and must not infringe on anyone else’s Patents rights, Books rights, trademark rights and other intellectual property rights, and must not violate relevant national laws and regulations.
(3) The work must be separable from the original development environment, have a demonstrable running environment, and be able to compile/run on the test account provided by the organizing committee or provide a compilation/run environment by yourself.
(4) The work is allowed to use other people's open source code, but the source and dependencies on other open source codes must be noted on the basis of maintaining the original copyright. When submitting a work, the role and proportion of other open source codes in the work must be clearly stated in the analysis and design document.
(5) The work should operate correctly and achieve expected results. The work should be consistent with the functions described in the design document. If it fails to achieve all the functions described in the design document, the unimplemented functions and their proportion and importance should be noted.
3. Submission requirements for entries
(1) Before submitting the work, the participating team must send the team leader’s registered email address, user name, name, mobile phone number and other information on the official website of the competition to the staff of this competition (contact email: Johnhw_2019@qq.com, the email subject is named: "Team Name" Warehouse Application), the staff will create a private warehouse for the team on AtomGit, and add the team leader as the warehouse administrator. After the participating teams complete their work, they can submit the relevant documents and source code of the work to the warehouse. The naming method for submitted works is: competition title + team name + title of work. AtomGit URL:https://atomgit.com/
(2) Participating teams can continue to promote iterative upgrades of their works without changing the name and main functions of the work. The last work submitted in the corresponding competition schedule will be the entry.
(3) During the review period, participating teams must submit additional materials related to their works in accordance with the requirements of the organizing committee.
(4) In principle, all submitted entries and related materials will not be returned.
Appendix 4: Review rules and review expert panel
1. Evaluation rules
(1) For detailed evaluation rules for each competition question, please refer to the "Competition Questions" column and the acceptance criteria for each competition question.
(2) Complete the document description of the entry, the technical path of the document is feasible, and it will be approved after being reviewed by the direction experts.
(3) The code function completes the indicator requirements, and submits standardized code and detailed documentation. Finally, the code is reviewed and merged into the corresponding warehouse.
(4) Obtain corresponding awards according to the acceptance criteria stated in each competition question.
2. Review Expert Group
Li Huawei (team leader, director of the openDACS Working Committee and head of SIG1, researcher at the Institute of Computing Technology, Chinese Academy of Sciences, deputy director of the National Key Laboratory of Processor Chips, responsible for competition question 1)
He Junhong (co-leader, co-director and executive director of the openDACS Working Committee, responsible for the organization and operation of this competition, and participating in the selection of questions 7-10)
Li Xingquan (Associate Researcher at Pengcheng Laboratory. Responsible for question 2)
Luo Guojie (Head of SIG2 of the openDACS Working Committee, Permanent Associate Professor of the School of Information Science and Technology, Peking University, and Executive Director of the Center for Energy-Efficient Computing and Applications. Responsible for question 3)
Yang Fan (Head of SIG3 of the openDACS Working Committee, professor and doctoral supervisor at the School of Microelectronics, Fudan University. Participated in the selection of competition question 2)
Xie Biwei (Head of SIG4 of the openDACS Working Committee, Assistant Researcher at the Institute of Computing Technology of the Chinese Academy of Sciences and Pengcheng Laboratory, participated in and was responsible for projects such as "One Core for Life" and open source EDA. Participated in the selection of competition questions 2\3)
Ye Zuochang (Head of SIG7 of the openDACS Working Committee, associate researcher at the School of Integrated Circuits, Tsinghua University, responsible for questions 4 and 5)
Li Zhiqiang (Head of SIG5 of the openDACS Working Committee, researcher at the Institute of Microelectronics, Chinese Academy of Sciences, head of the EDA Center, responsible for competition question 6)
Liu Yongxin (Assistant Dean of Shenzhen Institute of Micro-Nano Integrated Circuits and System Applications, responsible for question 7)
Wang Yujie (Zhijiang Laboratory, research expert, responsible for computing core design, interconnection system design, EDA design, etc. of chiplet and other discrete design methods, responsible for competition question 8)
Fan Jiaqi (Huajin Semiconductor, packaging design manager, responsible for 2.5D/3D integrated packaging, wafer-level fan-out packaging, three-dimensional heterogeneous integration and other packaging design and simulation technology research. Responsible for competition question 8)
Wang Ying (head of SIG8 of the openDACS Working Committee, researcher at the Institute of Computing Technology, Chinese Academy of Sciences, responsible for questions 9-10)
Huang Yu (Huawei semiconductor scientist, chief architect of Shenzhen HiSilicon EDA and director of the EDA laboratory. Participated in the selection of competition topics on 1/4/8)
Yang Fan (Vice President of R&D of Shenzhen Guowicin Technology Co., Ltd., participated in the selection of question 2)
Liu Yong (Head of Community Operations of the Electronic Enthusiast Platform under Shenzhen Huaqiu Electronics Co., Ltd., responsible for online lectures and participating in the selection of questions 7-10)