ประสบการณ์ช็อกวงการฮาร์ดแวร์ เมื่อบั๊กซิลิคอนหลบอยู่ในสเปกไม่ใช่ใน RTL
วิศวกรแชร์อุทาหรณ์โปรเจกต์ AXI interconnect ที่ผ่านการทดสอบกว่า 5 แสนไซเคิล แต่เกือบพลาดมหันต์ก่อนวันเทปเอาต์เพียง 2 สัปดาห์
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- โปรเจกต์ AXI interconnect ผ่านการจำลองกว่า 500,000 ไซเคิลและโค้ดคอเวอรจ์เกิน 98% ก่อนทีม DV จะเซ็นอนุมัติ
- สถาปนิกอาวุโสตั้งคำถามสำคัญเรื่องพฤติกรรม AWLEN ที่วนรอบ 256 ขณะใช้ AWBURST แบบ INCR
- สเปกระบุไว้ว่าเป็นพฤติกรรมที่ไม่ได้กำหนดไว้ แต่มุมอับนี้ซ่อนบั๊กที่ทำให้สเตทแมชชีนค้างใน RTL ไว้
- บทเรียนชี้ชัดว่าการตรวจสอบฮาร์ดแวร์ไม่ใช่แค่การพิสูจน์ว่า RTL ตรงตามสเปก แต่คือการพิสูจน์ว่าสเปกนั้นถูกต้องก่อนนำไปใช้งาน
เรื่องราวนี้เกิดขึ้นจริงในโปรเจกต์พัฒนา AXI interconnect โดยระบบทาสหรือ slave ของเราผ่านกระบวนการตรวจสอบอย่างเข้มงวดมาแล้ว ตัวเลขการจำลองพุ่งสูงกว่า 500,000 ไซเคิล และมีค่าโค้ดคอเวอรจ์ทะลุ 98% จนกระทั่งทีมออกแบบและตรวจสอบ (DV team) มั่นใจและลงชื่ออนุมัติผ่าน โดยเหลือเวลาอีกเพียง 2 สัปดาห์ก็จะถึงกำหนดการเทปเอาต์ (Tapeout)
ทว่าก่อนหน้าวันสำคัญนั้นไม่นาน สถาปนิกอาวุโสท่านหนึ่งได้ตั้งคำถามง่ายๆ ขึ้นมาว่า จะเกิดอะไรขึ้นหากค่า AWLEN วนกลับมาที่ 256 ในขณะที่โหมด AWBURST ถูกตั้งค่าไว้เป็น INCR
เมื่อย้อนกลับไปตรวจสอบเอกสารข้อกำหนด พบว่าสถานการณ์ดังกล่าวถูกระบุไว้ว่าเป็นพฤติกรรมที่ไม่ได้กำหนดไว้ชัดเจน (undefined behavior) ส่งผลให้เทสต์เบนช์ของทีมงานข้ามชุดคำสั่งนั้นไปอย่างน่าเสียดาย แต่ความจริงคือในส่วนของ RTL กลับซ่อนจุดบกพร่องที่ทำให้สเตทแมชชีนเกิดอาการค้างอยู่ในมุมอับนี้อย่างแนบเนียน
"What happens if AWLEN wraps around 256 when AWBURST is INCR?"
สถาปนิกอาวุโส
เหตุการณ์ดังกล่าวทำให้เรียนรู้บทบาทที่แท้จริงของการตรวจสอบระบบฮาร์ดแวร์ ว่างานนี้ไม่ได้ทำขึ้นเพื่อพิสูจน์ว่ารหัส RTL ตรงตามเอกสารข้อกำหนดเท่านั้น แต่เป้าหมายที่แท้จริงคือการพิสูจน์ว่าเอกสารข้อกำหนดนั้นมีความถูกต้องตั้งแต่ก่อนที่โค้ด RTL จะถูกพัฒนาขึ้นมาเสียอีก ซึ่งทั้งสองอย่างนี้เป็นปัญหาที่แตกต่างกันอย่างสิ้นเชิง
ในทางวิศวกรรมฮาร์ดแวร์ การทำ Tapeout หรือการส่งแบบแปลนวงจรไปผลิตจริงถือเป็นขั้นตอนที่มีต้นทุนสูงและแก้ไขยากมาก การที่สถาปนิกตั้งคำถามเชิงตรรกะในกรณีขอบเขต (Corner cases) จึงมีความสำคัญอย่างยิ่ง เพราะมักเป็นจุดที่เครื่องมืออัตโนมัติหรือ Testbench แบบดั้งเดิมมองข้ามไปเนื่องจากถูกละไว้ในฐานที่เข้าใจว่าเป็น undefined behavior ตามสเปกดั้งเดิม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ข้อผิดพลาดที่มักทำให้ชิปต้องถูกนำกลับมาผลิตซ้ำหรือ respin ส่วนใหญ่มักไม่ได้ซ่อนอยู่ในตัวโค้ดโปรแกรม แต่ฝังรากลึกอยู่ในข้อสมมติฐานที่ไม่มีใครตั้งคำถามถึงตั้งแต่วันแรก หากคุณเป็นวิศวกรตรวจสอบระบบ ทักษะที่มีค่าที่สุดไม่ใช่แค่การเชี่ยวชาญภาษา UVM แต่คือความสามารถในการตั้งคำถามที่ผู้เขียนสเปกลืมหาคำตอบให้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น