คุณรู้หรือไม่ว่า RTL RISC-V ของคุณไม่มีเรื่องน่าประหลาดใจ?

ด้วยความแปลกใหม่และความซับซ้อนของการออกแบบ RISC-V RTL ไม่ว่าคุณจะซื้อคอร์ที่ได้รับการสนับสนุนในเชิงพาณิชย์หรือดาวน์โหลดข้อเสนอโอเพ่นซอร์สยอดนิยม มีความเสี่ยงเพียงเล็กน้อยแต่ไม่เท่ากับศูนย์ที่ความประหลาดใจที่ไม่ต้องการจะหลบหนีไปยังผลิตภัณฑ์ปลายทางของคุณ เรียงความน่าจะเป็นมากไปน้อย ให้พิจารณา:

• การปรากฏตัวของข้อผิดพลาดกรณีมุมที่แปลกประหลาด แต่เป็นไปได้ทั้งหมด
• ข้อบกพร่อง "ภายใน" คำแนะนำแบบกำหนดเองที่คุณหรือผู้ขายของคุณกำลังสร้างสำหรับแอปพลิเคชันของคุณ
• ข้อบกพร่อง "ที่ขอบ" ของคำสั่งแบบกำหนดเอง — เช่น คำสั่งดำเนินการอย่างถูกต้อง แต่อย่างใดทำให้เครื่องอยู่ในสถานะเสียหาย
• ที่เกี่ยวข้อง: คุณสมบัติใหม่ที่ไม่มีเอกสารและ/หรือระบุอย่างไม่ดีซึ่งเปิดช่องโหว่ในการออกแบบ
• ตรรกะของโทรจันที่เป็นอันตรายที่แอบแฝงผ่านการโจมตีของห่วงโซ่อุปทาน

แนวทางการบรรเทาผลกระทบทั่วไป

โดยธรรมชาติ แนวป้องกันแรกคือการตรวจสอบโดยผู้เชี่ยวชาญเกี่ยวกับรหัส RTL ขาเข้าหรือการพัฒนา เห็นได้ชัดว่าควรทำสิ่งนี้ แต่ควรมีความชัดเจนพอๆ กันว่าเทคนิคนี้ — ตามที่พวกเขาพูดในโลกคณิตศาสตร์ — “จำเป็นแต่ไม่เพียงพอ” (แม้ว่าคุณจะให้ศาสตราจารย์แพตเตอร์สันทบทวนโค้ดของคุณก็ตาม)

แนวป้องกันถัดไปคือการใช้แนวทางการจำลอง: Instruction Set Simulation (ISS), การเปรียบเทียบอัตโนมัติของ DUT ของคุณกับโมเดลสีทองที่โตเต็มที่, แท่นทดสอบ UVM แบบสุ่มที่มีข้อจำกัดสำหรับการจำลอง DUT RTL และแม้แต่การวางสิ่งเร้าในโลกแห่งความเป็นจริงลงในการจำลองโดยใช้ฮาร์ดแวร์ช่วย ของ อปท. อีกครั้ง แนวทางเหล่านี้ล้วนมีค่าและควรทำ แต่พวกเขาทั้งหมดประสบกับข้อบกพร่องเดียวกัน: พวกเขาไม่สมบูรณ์โดยเนื้อแท้เพราะพวกเขาพึ่งพาการสร้างสิ่งเร้า ตัวอย่างเช่น ในกรณีที่ร้ายแรงแต่เป็นไปได้ของการโจมตีซัพพลายเชน ผู้พัฒนาลอจิกโทรจันได้จงใจสร้างลำดับการส่งสัญญาณและข้อมูลซึ่งมีแนวโน้มที่จะหลบหนีการตรวจจับโดยแฮ็กเกอร์หมวกขาวที่สร้างสรรค์ที่สุด และแน่นอนว่าข้อบกพร่องที่ใช้งานได้มีวิธีการใช้เอนโทรปีที่เกิดขึ้นตามธรรมชาติเพื่อซ่อนไว้

สิ่งสำคัญที่สุดคือวิธีเดียวที่จะแน่ใจได้อย่างสมบูรณ์ว่า RTL RISC-V ของคุณปราศจากความประหลาดใจที่เป็นธรรมชาติหรือเป็นอันตรายใดๆ คือการใช้วิธีการที่ละเอียดถี่ถ้วนและเป็นทางการในการตรวจสอบการออกแบบ

พูดง่ายกว่าทำใช่ไหม

ใช่และไม่ใช่: 14 ปีที่แล้ว การวิเคราะห์แบบนี้ทำได้โดยนักวิจัยระดับปริญญาเอกเท่านั้นโดยใช้โปรแกรมที่ทำด้วยมือของพวกเขาเอง แต่ตั้งแต่ปี 2008 เครื่องมือและเทคนิคต่างๆ ได้ถูกสร้างขึ้นเพื่อให้ทุกคนที่คุ้นเคยกับพื้นฐานของการตรวจสอบอย่างเป็นทางการและการเขียนมาตรฐาน System Verilog Assertions (SVA) ของ IEEE สามารถนำไปใช้และประสบความสำเร็จได้อย่างรวดเร็ว

กระบวนการที่เป็นทางการสามขั้นตอน

โฟลว์ที่เป็นทางการที่แนะนำมีดังต่อไปนี้:

1. สร้างม้านั่งทดสอบอย่างเป็นทางการที่ "จำลอง" ข้อมูลจำเพาะของ DUT
2. กำหนดข้อ จำกัด อินพุตและตรวจสอบว่าจะดำเนินการกับDUT
3. ดำเนินการวิเคราะห์

ขั้นตอนที่ 1 – สร้าง testbench อย่างเป็นทางการที่ "จำลอง" ข้อกำหนด DUT

พื้นฐานของวิธีการนี้คือการเขียนชุดคุณสมบัติที่แสดงถึงพฤติกรรมของแต่ละคำสั่งในการออกแบบ RISC-V ของคุณ ภารกิจคือการจับผลของคำสั่งที่ให้มากับเอาต์พุตของ IP และสถานะสถาปัตยกรรมภายใน (ในโลก RISC-V นี่คือตัวนับโปรแกรม (PC) และไฟล์ลงทะเบียน (RF)) สำหรับลำดับอินพุตที่มีความยาวตามอำเภอใจใดๆ ทำได้โดยใช้ส่วนขยายที่สร้างขึ้นตามวัตถุประสงค์ของ IEEE SVA ที่เรียกว่า Operational SVA โดยสรุป นี่คือไลบรารีที่มาพร้อมกับเครื่องมือตรวจสอบตัวประมวลผลแบบเป็นทางการ และจากมุมมองของวิศวกรตรวจสอบ ดูเหมือนว่าโค้ด SVA ที่คุ้นเคยเป็นส่วนย่อยที่ใช้งานง่าย รูปที่ 1 แสดงโครงสร้างทั่วไป:

คำแนะนำคุณสมบัติ_A; // สถานะแนวคิด t ##0 ready_to_issue() และ // ทริกเกอร์ t ##0 opcode==instr_A_opc หมายถึง // สถานะแนวคิด t ##0 ready_to_issue() และ // เอาต์พุตอินเทอร์เฟซหน่วยความจำ // อ่านคำสั่งถัดไป t ##0 imem_access(instr_A_opc) และ // โหลดข้อมูล/จัดเก็บ t ##1 dmem_access(instr_A_opc) และ // รีจิสเตอร์สถาปัตยกรรม t ##1 RF_update(instr_A_opc) และ t ##1 PC_update(instr_A_opc) endproperty 

รูปที่ 1: โครงสร้างของโค้ด Operational SVA ที่จับข้อกำหนดของคำสั่งโปรเซสเซอร์ [1]

อ้างอิงจากรูปที่ 1 ด้านซ้ายมือของ การมีส่วนร่วม (ส่วนของรหัส ข้างบน คีย์เวิร์ด หมายถึง) ระบุว่าเมื่อใดที่เครื่องพร้อมที่จะออกคำสั่งใหม่และคำสั่งที่ออก การยืนยันจะรวบรวมค่าปัจจุบันของรัฐทางสถาปัตยกรรมและทางด้านขวามือของความหมาย (ส่วนของรหัส ด้านล่าง คีย์เวิร์ด หมายถึง) พิสูจน์คุณค่าต่อไปของพวกเขา

นอกจากนี้ เอาต์พุตของโปรเซสเซอร์จะต้องได้รับการพิสูจน์ว่าถูกต้อง ในกรณีนี้เพื่อให้แน่ใจว่าคำสั่งเข้าถึงข้อมูลที่คาดหวังและตำแหน่งหน่วยความจำคำสั่ง การยืนยันยังพิสูจน์ว่าเครื่องพร้อมที่จะออกคำสั่งใหม่ในรอบถัดไป นี่เป็นสิ่งสำคัญในการแยกการตรวจสอบคำสั่งออกจากลำดับของคำสั่งที่อาจเป็นส่วนหนึ่ง ตัวอย่างเช่น คำสั่ง A สามารถดำเนินการได้อย่างถูกต้อง แต่ปล่อยให้เครื่องอยู่ในสถานะเสียหาย สถานะที่ผิดพลาดนี้อาจทำให้คำสั่งถัดไป B ให้ผลลัพธ์ที่ไม่ถูกต้องโดยไม่ใช่ข้อผิดพลาดของตัวเอง ดังนั้น ด้วยวิธี Operational SVA คำสั่งยืนยันการยืนยัน B จะผ่าน ขณะที่คำสั่งตรวจสอบการยืนยัน A จะล้มเหลว (โดยที่การดำเนินการอ่านและเขียนหน่วยความจำอาจใช้เวลานานหลายรอบ)

บรรทัดล่าง: ฟังก์ชันที่แสดงถึงสถานะทางสถาปัตยกรรมในโค้ด Operational SVA จะต้องถูกแมปกับสัญญาณการใช้งานและต้องสะท้อนถึงสถาปัตยกรรมไมโครของโปรเซสเซอร์ ตัวอย่างเช่น สถานะของ RF อาจขึ้นอยู่กับการเปิดใช้งานเส้นทางการส่งต่อ [1]

[หมายเหตุ: สำหรับผู้ที่คุ้นเคยกับการจำลองหรือการครอบคลุมการทำงานอย่างเป็นทางการ แนวคิดเรื่องความสมบูรณ์นี้ไม่ได้อาศัยเมตริกความครอบคลุมโครงสร้าง หรือการสร้างและการรวบรวมเมตริกสำหรับแบบจำลองความครอบคลุมฟังก์ชัน แทนที่จะ (และก้าวไปข้างหน้าเล็กน้อยของขั้นตอนและผลลัพธ์ที่เหลือ) ผลลัพธ์การวิเคราะห์ที่นี่เป็นข้อมูลเกี่ยวกับการพิสูจน์คุณสมบัติทั้งหมดอย่างครบถ้วน หลักฐานฉบับสมบูรณ์ยังแสดงให้เห็นโดยปริยายว่าไม่มีฟังก์ชันอื่นใดที่ไม่ได้ระบุหรือไม่คาดคิด (ข้อมูลจำเพาะหรือข้อบกพร่องในการเข้ารหัส) หรือถูกแทรกโดยประสงค์ร้าย ซึ่งไม่ได้บันทึกโดยคุณสมบัติชุดนี้ การใช้ถ้อยคำใหม่ วิธีการนี้เป็นทั้งหมดเกี่ยวกับการบรรลุ "ความครอบคลุมของแผนการทดสอบ" 100% ตามที่ตรวจสอบโดยผลการวิเคราะห์อย่างเป็นทางการอย่างละเอียดถี่ถ้วน - โดยที่ไม่มีอะไร "สมบูรณ์" มากไปกว่าการพิสูจน์ทางคณิตศาสตร์!]

ขั้นตอนที่ 2 – กำหนดข้อ จำกัด อินพุตและตรวจสอบว่าจะดำเนินการกับDUT

เพื่อเสริมคุณสมบัติข้อมูลจำเพาะสำหรับแต่ละคำสั่ง ขั้นตอนต่อไปคือการกำหนดข้อจำกัดอินพุตและการตรวจสอบเอาต์พุตเพิ่มเติม อีกครั้ง มีการใช้ Operational SVA ซึ่งขณะนี้ผู้ใช้ระบุ "แผนความสมบูรณ์" เพื่อกำหนดทั้งข้อมูลนำเข้าทางกฎหมายและการส่งสัญญาณที่ผิดกฎหมายว่า DUT ควรละเว้น ตามตัวอย่างที่แสดงในรูปที่ 2 มีสามส่วน: สมมติฐานการกำหนด ข้อกำหนดในการกำหนด และกราฟคุณสมบัติ

ตัวประมวลผลความสมบูรณ์; การกำหนดสมมติฐาน: // กำหนดอินพุต (imem_data_i); กำหนด (dmem_valid_i); ถ้า (dmem_valid_i) กำหนด (dmem_data_i) endif; Define_requirements: // ผลลัพธ์ที่กำหนด (imem_read_o) ถ้า (imem_read_o) กำหนด (imem_addr_o) endif; กำหนด (dmem_enable_o); ถ้า (dmem_enable_o) กำหนด (dmem_rd_wr_o) กำหนด (dmem_addr_o) endif; // รัฐทางสถาปัตยกรรมกำหนด(PC); กำหนด (RF); property_graph: all_instructions := instruction_not_a, instruction_add_a, instruction_sub_a, [...] all_instructions -> all_instructions; สิ้นสุดความสมบูรณ์; 

รูปที่ 2: ตัวอย่างแผนความสมบูรณ์พร้อมสมมติฐานและข้อกำหนดในการกำหนดแบบมีเงื่อนไข

ทำอย่างละเอียด:

• “determination_assumptions” เป็นเพียงชื่อแฟนซีสำหรับข้อจำกัดของค่าอินพุต
• “determination_requirements” คือคำจำกัดความของสัญญาณที่ต้องตรวจสอบ (ทั้งสัญญาณเอาท์พุตของโปรเซสเซอร์และสถานะทางสถาปัตยกรรม)
• ส่วน "property_graph" เป็นเพียงการเชื่อมโยงไฟล์นี้กับคุณสมบัติทั้งหมดที่สร้างขึ้นในขั้นตอนที่ 1

ทบทวนจุดที่เราอยู่ ณ จุดนี้: ในขั้นตอนที่ 1 คุณได้สร้างแบบจำลอง DUT ที่มีความแม่นยำในวงจรอย่างมีประสิทธิภาพ ซึ่งต้องได้รับการพิสูจน์ว่าเป็นจริงตลอดเวลาและอินพุตทั้งหมด ในขั้นตอนที่ 2 คุณตั้งค่าข้อจำกัดและพฤติกรรมพิเศษใดๆ ที่ควรระวัง เพิ่มสิ่งเหล่านี้เข้าด้วยกัน และมีผลให้คุณมีชุดทดสอบอย่างเป็นทางการที่พร้อมใช้งาน!

ขั้นตอนที่ 3 – ดำเนินการวิเคราะห์

เป้าหมายของเครื่องมือที่เป็นทางการทั้งหมดคือการพิสูจน์อย่างละเอียดถี่ถ้วนว่าคุณสมบัติทั้งหมดเป็นจริงตลอดเวลาและอินพุตทั้งหมด ในกรณีของการตรวจสอบตัวประมวลผล RISC-V เครื่องมือจะทำงานเพื่อพิสูจน์ว่าลำดับอินพุตที่ยาวตามอำเภอใจสามารถจับคู่กับลำดับเฉพาะของ Operational SVA ที่ระบุซึ่งคาดการณ์ค่าของเอาต์พุตและสถานะทางสถาปัตยกรรม

และนี่คือสิ่งที่เกิดขึ้น หากพบว่ามีพฤติกรรมที่แตกต่างกันระหว่างข้อกำหนดและ DUT เครื่องมือที่เป็นทางการจะส่งรูปคลื่น "ตัวอย่างที่เคาน์เตอร์" ที่แสดงชุดของสัญญาณอินพุตและข้อมูลที่สามารถสร้างการละเมิดข้อกำหนดได้ ดังที่กล่าวไว้ข้างต้น ความล้มเหลวดังกล่าวสามารถพบได้ในตรรกะ RTL ของคำสั่ง หรือใน "ตรรกะแฮนด์ออฟ" ที่จะนำเสนอสาขา/คำสั่งทางกฎหมายถัดไป

ไม่ว่าจะด้วยวิธีใด เมื่อปัญหาเหล่านี้ได้รับการแก้ไขและเครื่องมือพิสูจน์คุณสมบัติทั้งหมด ผลลัพธ์จะ "สมบูรณ์" อย่างแท้จริง กล่าวคือ คุณสามารถแน่ใจทางคณิตศาสตร์ได้ว่าไม่มีข้อผิดพลาดในการเข้ารหัส RTL การวิเคราะห์อย่างเป็นทางการได้พิสูจน์แล้วว่าไม่มีข้อบกพร่อง !

ผลสอบ

ประการแรก ดังที่กล่าวไว้ข้างต้น ในช่วงหลายปีที่ผ่านมา นักพัฒนาโปรเซสเซอร์จำนวนมากได้รับประโยชน์จากโฟลว์นี้ [2], [3], [4]

นำวิธีการนี้ไปทดสอบกับ RISC-V เพื่อนร่วมงานของฉันได้ทำกรณีศึกษาโดยใช้โอเพ่นซอร์สคอร์ยอดนิยมของ Rocket Chip โดยเฉพาะอย่างยิ่ง การกำหนดค่า RV64IMAFDC – sv39 vm ได้รับการตรวจสอบแล้ว นี่คือคอร์โปรเซสเซอร์ 64 บิตพร้อมระบบหน่วยความจำเสมือน 39 บิต [5] และส่วนขยาย เช่น คำสั่งบีบอัดและอะตอมมิก [6] การใช้งาน RISC-V ISA แบบโอเพนซอร์สนี้ใช้ไปป์ไลน์แบบเรียงตามลำดับปัญหาเดียวแบบห้าขั้นตอนที่มีการเสร็จสิ้นที่ไม่อยู่ในลำดับสำหรับคำสั่งที่มีเวลาแฝงนาน เช่น การแบ่งหรือแคชที่ขาดหายไป คอร์ยังสนับสนุนการทำนายสาขาและการปรับเปลี่ยนรันไทม์ของการลงทะเบียน "misa" ซึ่งช่วยให้สามารถปิดส่วนขยายชุดคำสั่งบางตัวได้

แม้ว่าสแนปชอตของ Rocket Chip นี้ได้รับการตรวจสอบและบันทึกเทปไว้หลายครั้ง แต่ก็มีการระบุและรายงานพฤติกรรมที่น่าสงสัยทั้งสี่ตัวที่ไม่ทราบสาเหตุก่อนหน้านี้และรายงานไปยังนักพัฒนา Rocket Core RTL ปัญหาเหล่านี้ ([7], [8], [9] และ [10]) ถูกค้นพบโดยการใช้วิธีการตรวจสอบอย่างเป็นทางการที่สมบูรณ์ซึ่งระบุไว้ในบทความนี้เท่านั้น

อธิบายอย่างละเอียดเกี่ยวกับ [10] โดยเฉพาะ — การค้นพบคำสั่งที่ไม่เป็นมาตรฐาน CEASE (Opcode 0x30500073) ใน RTL: เห็นได้ชัดว่าทีม Rocket Chip ล้มเหลวในเอกสารของพวกเขา (และพวกเขาแก้ไขปัญหานี้เกือบจะในทันทีเมื่อยื่นคำขอดึง GitHub) ประเด็นที่ใหญ่กว่าคือสิ่งนี้แสดงให้เห็นว่าตรรกะที่จำเป็นในการใช้งานคำสั่งทั้งหมด — โค้ดหลายสิบบรรทัดและเกทหลาย ๆ ของตรรกะที่สังเคราะห์ วาง และกำหนดเส้นทาง — สามารถหลบหนีการตรวจจับโดยการตรวจสอบด้วยภาพ การจำลอง RTL การจำลองระดับเกต ทั้งหมด กระบวนการใช้งานแบ็คเอนด์และต้นแบบฮาร์ดแวร์ในห้องปฏิบัติการ!

แต่ประสิทธิภาพของโฟลว์นี้เป็นอย่างไร?

อันดับแรก มาพูดถึงความหมายที่ใหญ่กว่าของ "ประสิทธิภาพ" เนื่องจากลักษณะที่แปลกใหม่ของการออกแบบ Rocket Chip สำหรับกรณีศึกษานี้ จึงต้องใช้เวลาทางวิศวกรรมประมาณ 20 สัปดาห์สำหรับผู้ปฏิบัติงานตรวจสอบอย่างเป็นทางการของเราเพื่อพัฒนาชุดทดสอบและข้อจำกัดทั้งหมด อย่างไรก็ตาม การใช้งานก่อนหน้าของโฟลว์นี้กับ IP เชิงพาณิชย์ที่มีโครงสร้างมากกว่าปกติจะใช้เวลาเพียงเศษเสี้ยวของเวลานี้ โดยธรรมชาติแล้ว กระบวนการนำเสนอทั้งหมดจะดำเนินไปเร็วขึ้นมาก ยิ่งข้อกำหนดมีความเสถียรและครบถ้วนมากขึ้น โค้ด DUT RTL นั้นได้รับการจัดทำเป็นเอกสารและอ่านได้ดีเพียงใด และคุณสามารถเข้าถึงวิศวกรออกแบบสำหรับ Q&A ได้มากน้อยเพียงใด

เมื่อตั้งค่าสภาพแวดล้อมแล้ว รันไทม์นาฬิกาแขวนทั้งหมดจะอยู่ที่ 2 ชั่วโมง — กล่าวคือ น้อยกว่าที่คุณจะคาดหวังได้จากการจำลอง RTL แบบสุ่มที่มีข้อจำกัดและแม้แต่การตรวจสอบด้วยฮาร์ดแวร์ช่วย นอกจากนี้ โปรดจำไว้ว่าผลลัพธ์ของการวิเคราะห์นี้ใช้ได้กับอินพุตทั้งหมดและตลอดเวลา กล่าวได้คำเดียวว่ามีความครบถ้วนสมบูรณ์ [11]

สรุป

วิธีการตรวจสอบตัวประมวลผลแบบเป็นทางการแบบสมบูรณ์ที่นำเสนอในบทความนี้ใช้ส่วนขยายของ IEEE SVA หรือ Operational SVA เพื่อตรวจสอบว่า RISC-V ISA ปราศจากช่องว่างและความไม่สอดคล้องกัน ต่างจากชุดทดสอบการจำลองแบบสุ่มที่มีข้อจำกัด การจำลอง หรือการสร้างต้นแบบทางกายภาพ ชุดคุณสมบัติและข้อจำกัดที่สมบูรณ์จะตรวจจับข้อผิดพลาด RTL หลายประเภทอย่างละเอียดถี่ถ้วน รวมถึงการปรากฏตัวของรหัสที่ไม่มีเอกสารหรือระบุไว้ไม่ดีและโทรจันที่เป็นอันตราย

อ้างอิง

1 – 2019 GOMACTech Conference, Albuquerque, NM, 28 มีนาคม 2019: การยืนยันอย่างเป็นทางการของ IP โปรเซสเซอร์ RISC-V สำหรับ IC ที่เชื่อถือได้โดยปราศจากโทรจัน, David Landoll, et.al.

2 – DVCon 2007: ทำการตรวจสอบ TriCore2 และโปรเซสเซอร์อื่นๆ อย่างเป็นทางการ Infineon Gmbh

3 - 51^st Design Automation Conference (DAC): การตรวจสอบอย่างเป็นทางการที่ใช้กับแพลตฟอร์มการออกแบบ Renesas MCU โดยใช้เครื่องมือ OneSpin

4 – DVCon Europe 2019: การยืนยันอย่างเป็นทางการของตระกูล DSP ยานยนต์ Bosch Gmbh

5 – คู่มือการใช้งาน RISC-V Instruction Set เล่มที่ II: Privileged Architecture, Document Version 1.10

6 - https://github.com/freechipsproject/rocket-chip [เข้าถึง 20 ธันวาคม 2018]

7 – ผลการสอน DIV ไม่ได้เขียนเพื่อลงทะเบียนไฟล์
https://github.com/freechipsproject/rocket-chip/issues/1752

8 – คำแนะนำของ JAL และ JALR จัดเก็บ PC ส่งคืนที่แตกต่างกัน
https://github.com/freechipsproject/rocket-chip/issues/1757

9 – เล่นซ้ำ Opcodes ที่ผิดกฎหมายและก่อให้เกิดผลข้างเคียงที่ไม่คาดคิด
https://github.com/freechipsproject/rocket-chip/issues/1861

10 – คำสั่งที่ไม่ได้มาตรฐานหยุด (Opcode 0x30500073) ค้นพบใน RTL https://github.com/freechipsproject/rocket-chip/issues/1868

11 – บล็อก Verification Horizons คุณจะพูดได้อย่างไรว่าการตรวจสอบอย่างเป็นทางการนั้นครบถ้วนสมบูรณ์แล้ว Joe Hupcey III
https://blogs.sw.siemens.com/verificationhorizons/2021/09/16/how-can-you-say-that-formal-verification-is-exhaustive/

ที่มา: https://semiengineering.com/do-you-know-for-sure-your-risc-v-rtl-doesnt-contain-any-surprises/