אימות שבבים

אימות שבבים (באנגלית: Chip Verification) הוא תהליך שנועד לבצע אימות לתכן של רכיב אלקטרוני על מנת לבחון את ההתנהגות של הרכיב. אם לאורך הבדיקות נמצא שהרכיב המתוכנן אינו פועל כפי שמצופה ממנו – הרי שהתגלתה תקלה או שגיאה בתכן. במצב זה, יש לתקן את התכן ולחזור שנית על תהליך האימות, עד לקבלת רכיב נקי מתקלות ובעיות.

רקע

התהליך מתכנון ועד ייצור שבב (צ'יפ) הוא תהליך ארוך-זמן ועלותו עלולה להגיע למליוני דולרים. ההתקדמות הטכנולוגית האדירה בייצור שבבים ובמורכבות שלהם הן מבחינת הלוגיקה שלהם והן מבחינת השילוב שלהם עם זיכרון פנימי וארכיטקטורות אחרות יצרה תחום מורכב מאד של בדיקת השבבים על ידי שיטות מתוחכמות המצריכות ידע רב בתכנות ובהבנת הלוגיקה העומדת מאחורי השבב. בשונה מהנדסת תוכנה ואימות תוכנה (QA), קשה מאד ולעיתים בלתי אפשרי לגלות ולתקן טעות שלא נתגלתה בשלב התכנון, לכן תהליך האימות חשוב כל כך בייצור שבבים. הווריפיקציה העיקרית בפרויקט מתבצעת על ה-design הכתוב בשפת RTL כגון Verilog או VHDL. בדרך כלל, מקובל שהאדם המבצע את הווריפיקציה אינו אותו אדם הכותב את ה-design, מאחר שאחד הגורמים לבאגים הוא תפישה מוטעית של ההגדרה של הפונקציונליות, וכאשר אותו אדם מבצע את שני התפקידים, הוא נשאר "כלוא" בקונספציה המוטעית שלו.

אופן הביצוע

כיום, ישנם שבבים מאד מורכבים, ולכן מחלקים את השבב הנבדק ל"בלוקים" - קטעי קוד, כאשר כל בלוק מבצע פונקציונליות מסוימת של השבב. עבור כל בלוק נבנית סביבת בדיקה נפרדת. לאחר שכל בלוק נמצא תקין, מבצעים בדיקות אינטגרציה של כל הבלוקים ביחד, על-מנת לוודא שכל המכלולים עובדים כמו שצריך.

תהליך הוריפיקציה הוא תהליך איטרטיבי המורכב ממספר שלבים:

1. הבנת תכן הרכיב על כל תכונותיו ויכולותיו (לא נכנסים למימוש).
2. הגדרת המקרים שאותם צריך למדל (coverage).
3. כתיבת תוכנית עבודה שמגדירה מה ייבדק, ואיך (Verification Plan)
4. קידוד סביבת הווריפיקציה.
5. הרצת הבדיקות.
6. ניתוח "נפילות" של טסטים וניתוח חורים שלא כוסו
7. עדכון קוד הדזיין וסביבת הווריפיקציה בהתאם

לאחר מכן, נמשך התהליך של הרצה-ניתוח-תיקון עד שכל המקרים שאמורים להתמדל נוצרו.

שפות וריפיקציה

כיום השפות הנפוצות בקידוד לוריפיקציה הן:

• systemVerilog - הרחבה של שפת Verilog שנועדה לאפשר תיאור גם של הדזיין וגם של הוריפיקציה באותה שפה (IEEE 1800TM)
• VERA של חברת synopsys
• Specman שנוצרה במקור בחברת Verisity ונרכשה על ידי חברת cadence. הכלי המתאים למעגלים דיגיטליים. את סביבות הווריפיקציה של ספקמן כותבים בשפת התכנות e.
• SystemC, המבוססת על שפת ++C, ומיועדת בעיקר עבור דיזיין שנוצר ב SystemC
• כמו כן, ישנן חברות רבות המשתמשות בכלים פנימיים, אשר עושים שימוש בשפות סטנדרטיות, כגון Verilog או C

סביבת העבודה

לכל רכיב חשמלי ישנם אותות כניסה אותם הוא מקבל מרכיבים אלקטרוניים אחרים במעגל, ואותות מוצא, אותם הוא מפיק לאור תפקידו במעגל החשמלי. על מנת לבדוק שאותות המוצא עונים על הדרוש, יש לספק לרכיב המתוכנן את אותות הכניסה המתאימים, ולוודא שהוא אכן מגיב בצורה הרצויה והמתוכננת. לשם כך בונים סביבה המכילה את הרכיבים הבאים:

• reference model - מחשב את המוצא הצפוי עבור קלט נתון.
• scoreboard - מבצע השוואה של המוצא בפועל עם הערך הצפוי (שהתקבל מה- reference model)
• agent - מנהל את הממשק עם הרכיב החשמלי, וכולל בתוכו :
  • driver - אחראי על ייצור של אותות כניסה, ברמה גבוהה ונוחה לניהול.
  • bfm - אחראי על תרגום הקלט שייצר ה driver לרמה של אותות הכניסה הפיזיים.
  • monitor - אחראי לדגום את אותות הכניסה והיציאה הפיזיים, והעברתם לעיבוד:
    • אותות הכניסה עוברים לעיבוד של ה- reference model
    • אותות היציאה עוברים לבדיקה של ה- scoreboard.

במתודולוגיות עבודה שונות ייתכנו שמות שונים לחלקים השונים של סביבת הווריפיקציה

שיטות וריפיקציה

ישנן שתי שיטות עיקריות לוריפיקציה:

1. וריפיקציה רנדומלית (Coverage Driven Verification)
2. וריפיקציה ישירה (Test Driven Verification)

בווריפיקציה רנדומלית (Coverage Driven) מנסים להתגבר על העובדה שמספר המצבים שבהם יכול להמצא הרכיב הנבדק הוא אדיר ולא ניתן להגיע לכל המצבים (בהינתן יכולת מחשוב מוגבלת וזמן מוגבל). הרעיון הוא להביא את הרכיב למקרי הקצה שבהם עלולים להיות באגים מבלי שהמהנדס יצטרך לחשוב בעצמו על כל מקרה באופן פרטני. המהנדס צריך להגדיר בסביבת הוריפיקציה את כל המקרים האפשריים וכאשר הסביבה רצה אז היא תגיע למקרים הבעייתיים. כדי להגדיר את השלב בו ניתן לומר שהבדיקה הסתיימה, מגדיר המהנדס את רשימת המקרים אותה הוא מגדיר כחשובה. כלי הווריפיקציה אוסף את מכלול הצירופים שנבדקו, ובהתאם ניתן לראות את יעילות הרנדומיזציה (בהגעה למקרי קיצון), ואת מידת בשלות הקוד לייצור (כמות ואיכות ה"חורים" - אותם צירופים שלא נבדקו עדיין). בשיטת הוריפקציה ישירה (Test Driven) כותבים test עבור כל אירוע שרוצים לבדוק. סביבת הבדיקה בנויה ממספר טסטים אשר כל אחד מהם נועד לבדוק מקרה אחר. במרבית הפרויקטים ייעשה שילוב של שתי השיטות, השיטה הישירה היא יותר פשוטה ומתאימה במיוחד למקרים מאד ספציפיים אשר אינם קורים במהלך עבודה רגיל של הרכיב, כמו כן בשלב הראשוני של הפרויקט הרבה יותר מהיר וקל לכתוב טסטים בודדים. לעומת זאת הוריפיקציה הרנדומלית עשויה למצוא באגים יותר מורכבים אשר קשה למצוא אותם בטסטים הפשוטים, מאחר שמתוך מכלול המקרים האפשריים, ישנם מקרים שלא אופיינו כחשובים לבדיקה, אך התבררו כגורמים בעייתיים.