<div class="key-takeaways"><ul><li>โปรเจกต์ AXI interconnect ผ่านการจำลองกว่า 500,000 ไซเคิลและโค้ดคอเวอรจ์เกิน 98% ก่อนทีม DV จะเซ็นอนุมัติ</li><li>สถาปนิกอาวุโสตั้งคำถามสำคัญเรื่องพฤติกรรม AWLEN ที่วนรอบ 256 ขณะใช้ AWBURST แบบ INCR</li><li>สเปกระบุไว้ว่าเป็นพฤติกรรมที่ไม่ได้กำหนดไว้ แต่มุมอับนี้ซ่อนบั๊กที่ทำให้สเตทแมชชีนค้างใน RTL ไว้</li><li>บทเรียนชี้ชัดว่าการตรวจสอบฮาร์ดแวร์ไม่ใช่แค่การพิสูจน์ว่า RTL ตรงตามสเปก แต่คือการพิสูจน์ว่าสเปกนั้นถูกต้องก่อนนำไปใช้งาน</li></ul></div><p>เรื่องราวนี้เกิดขึ้นจริงในโปรเจกต์พัฒนา AXI interconnect โดยระบบทาสหรือ slave ของเราผ่านกระบวนการตรวจสอบอย่างเข้มงวดมาแล้ว ตัวเลขการจำลองพุ่งสูงกว่า 500,000 ไซเคิล และมีค่าโค้ดคอเวอรจ์ทะลุ 98% จนกระทั่งทีมออกแบบและตรวจสอบ (DV team) มั่นใจและลงชื่ออนุมัติผ่าน โดยเหลือเวลาอีกเพียง 2 สัปดาห์ก็จะถึงกำหนดการเทปเอาต์ (Tapeout)</p><p>ทว่าก่อนหน้าวันสำคัญนั้นไม่นาน สถาปนิกอาวุโสท่านหนึ่งได้ตั้งคำถามง่ายๆ ขึ้นมาว่า จะเกิดอะไรขึ้นหากค่า AWLEN วนกลับมาที่ 256 ในขณะที่โหมด AWBURST ถูกตั้งค่าไว้เป็น INCR</p><div class="stat-row"><div class="stat-item"><span class="stat-number">500k+</span><span class="stat-label">รอบจำลองสถานการณ์</span></div><div class="stat-item"><span class="stat-number">98%</span><span class="stat-label">ค่าโค้ดคอเวอรจ์</span></div><div class="stat-item"><span class="stat-number">2</span><span class="stat-label">สัปดาห์ก่อนเทปเอาต์</span></div></div><p>เมื่อย้อนกลับไปตรวจสอบเอกสารข้อกำหนด พบว่าสถานการณ์ดังกล่าวถูกระบุไว้ว่าเป็นพฤติกรรมที่ไม่ได้กำหนดไว้ชัดเจน (undefined behavior) ส่งผลให้เทสต์เบนช์ของทีมงานข้ามชุดคำสั่งนั้นไปอย่างน่าเสียดาย แต่ความจริงคือในส่วนของ RTL กลับซ่อนจุดบกพร่องที่ทำให้สเตทแมชชีนเกิดอาการค้างอยู่ในมุมอับนี้อย่างแนบเนียน</p><blockquote class="pull-quote"><p>"What happens if AWLEN wraps around 256 when AWBURST is INCR?"</p><cite>สถาปนิกอาวุโส</cite></blockquote><p>เหตุการณ์ดังกล่าวทำให้เรียนรู้บทบาทที่แท้จริงของการตรวจสอบระบบฮาร์ดแวร์ ว่างานนี้ไม่ได้ทำขึ้นเพื่อพิสูจน์ว่ารหัส RTL ตรงตามเอกสารข้อกำหนดเท่านั้น แต่เป้าหมายที่แท้จริงคือการพิสูจน์ว่าเอกสารข้อกำหนดนั้นมีความถูกต้องตั้งแต่ก่อนที่โค้ด RTL จะถูกพัฒนาขึ้นมาเสียอีก ซึ่งทั้งสองอย่างนี้เป็นปัญหาที่แตกต่างกันอย่างสิ้นเชิง</p><div class="ai-insight"><p>ในทางวิศวกรรมฮาร์ดแวร์ การทำ Tapeout หรือการส่งแบบแปลนวงจรไปผลิตจริงถือเป็นขั้นตอนที่มีต้นทุนสูงและแก้ไขยากมาก การที่สถาปนิกตั้งคำถามเชิงตรรกะในกรณีขอบเขต (Corner cases) จึงมีความสำคัญอย่างยิ่ง เพราะมักเป็นจุดที่เครื่องมืออัตโนมัติหรือ Testbench แบบดั้งเดิมมองข้ามไปเนื่องจากถูกละไว้ในฐานที่เข้าใจว่าเป็น undefined behavior ตามสเปกดั้งเดิม</p></div><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/rtl_ms3u317n_inline_1_a06410da8d.jpg" alt="circuit board chip engineering" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>ข้อผิดพลาดที่มักทำให้ชิปต้องถูกนำกลับมาผลิตซ้ำหรือ respin ส่วนใหญ่มักไม่ได้ซ่อนอยู่ในตัวโค้ดโปรแกรม แต่ฝังรากลึกอยู่ในข้อสมมติฐานที่ไม่มีใครตั้งคำถามถึงตั้งแต่วันแรก หากคุณเป็นวิศวกรตรวจสอบระบบ ทักษะที่มีค่าที่สุดไม่ใช่แค่การเชี่ยวชาญภาษา UVM แต่คือความสามารถในการตั้งคำถามที่ผู้เขียนสเปกลืมหาคำตอบให้</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mritunjay_biharisingh/i-once-found-a-silicon-bug-in-a-protocol-spec-not-in-the-rtl-1aid" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>An AXI interconnect project passed over 500k simulation cycles with code coverage exceeding 98% before DV sign-off.</li><li>A senior architect raised a crucial question about AWLEN wrapping around 256 when AWBURST is INCR.</li><li>The spec classified it as undefined behavior, causing the testbench to skip it while a latent state machine hang hid in the RTL.</li><li>Hardware verification is not about proving the RTL matches the spec, but proving the spec is correct beforehand.</li></ul></div><p>This true story stems from an AXI interconnect project where our slave component was thoroughly verified. We achieved over 500,000 simulation cycles and pushed code coverage past 98%, leading the verification team to sign off just two weeks prior to tapeout.</p><p>However, right before the target milestone, a senior architect posed a straightforward question: What happens if AWLEN wraps around 256 when AWBURST is INCR?</p><div class="stat-row"><div class="stat-item"><span class="stat-number">500k+</span><span class="stat-label">Simulation Cycles</span></div><div class="stat-item"><span class="stat-number">98%</span><span class="stat-label">Code Coverage</span></div><div class="stat-item"><span class="stat-number">2</span><span class="stat-label">Weeks to Tapeout</span></div></div><p>Upon reviewing the documentation, that specific scenario was labeled as undefined behavior. Consequently, our testbench entirely skipped those undefined sequences, leaving a latent state machine hang lurking silently within a corner of the RTL code.</p><blockquote class="pull-quote"><p>"What happens if AWLEN wraps around 256 when AWBURST is INCR?"</p><cite>Senior Architect</cite></blockquote><p>The ordeal provided a profound lesson regarding hardware verification. It is not merely about confirming whether the RTL aligns with the specification, but ensuring the specification itself is entirely sound before any RTL implementation takes place. These two represent completely different engineering challenges.</p><div class="ai-insight"><p>In hardware engineering, reaching tapeout and sending a design to fabrication carries immense financial stakes and long turnaround times. Catching corner-case logic flaws through critical inquiries prevents costly respins, as standard automated verification tools often miss scenarios dismissed as undefined behavior in early protocol drafts.</p></div><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/rtl_ms3u317n_inline_1_a06410da8d.jpg" alt="circuit board chip engineering" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>Bugs necessitating costly respins typically do not reside within the written code itself. Instead, they hide inside underlying assumptions that nobody ever bothered to challenge. If you work as a verification engineer, your ultimate asset is not mastering UVM frameworks, but knowing which vital questions to ask when spec authors leave blanks.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mritunjay_biharisingh/i-once-found-a-silicon-bug-in-a-protocol-spec-not-in-the-rtl-1aid" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_rtl-ms3u317n.jpg

small_rtl-ms3u317n.jpg

thumbnail_rtl-ms3u317n.jpg

Inewgen

Inewgen

#Tapeout

I once found a silicon bug in a protocol spec — not in the RTL

Inewgen