יום בחיי מהנדס וריפיקציה
אז איך נראה יום בחיי מהנדס וריפיקציה?
נתחיל בלענות על שאלה מקדימה - מהו מהנדס וריפיקציה?
תפקיד מהנדס הוריפיקציה לתכן לוגי – הוא וידוי עמידת התכן הלוגי בדרישות (מסמך Spec), ז"א שההתנהגות של התכן הלוגי הנבדק היא כמצופה לפי מסמך הדרישות.
ישנם מספר סוגים של מהנדסי וריפיקציה מתחומים שונים, נפרט על המרכזיים שבהם (שימו לב לשוני לגבי מהנדס ולידציה, המתואר בהמשך):
מהנדס וריפיקציה פונקציונלית לתכן לוגי (נקרא גם Pre Silicon Functional Verification): מתכנן ומממש אוסף תרחישים, אותם הוא מריץ בכלי סימולציה על הדיזיין (logic design), ומוודא שההתנהגות של התכן הלוגי היא כמצופה ממסמך הדרישות של הדיזיין.
מהנדס פורמל וריפיקציה (נקרא גם Formal Verification): משתמש בכלים ובהוכחות מתמטיות על מנת להוכיח שהדיזיין מתנהג כנדרש. הדגש פה הוא על הוכחת נכונות בצורה מתמטית עבור כל קלט אפשרי.
מהנדסי וריפיקציה יכולים לעבוד בהיררכיות שונות – ניתן לעבוד על וריפיקציה לבלוק (UNIT), IP, Cluster, Full Chip.
מהנדס ולידציה (נקרא גם Post Silicon Validation): מתכנן וממש אוסף תרחישים על הצ'יפ (הסיליקון) עצמו.
יכול לבדוק היבטים שונים – התנהגות לוגית, פיזור הספקים, ביצועים, שעונים וריסטים שבצ'יפ ועוד.
התמונה מימין מציגה (בתתי פרקים) תהליך פיתוח של צ'יפ, ובו מודגשים השלבים השונים בהם מעורבים מהנדסי וריפיקציה.
שימו לב איך מהנדס הוריפיקציה נמצא במקביל לצוות הדיזיין, לכל אורך חיי הפיתוח.
נשים לב שתהליך הוריפיקציה מתבצעת במקביל ככל שניתן לקידוד התכן הלוגי (מתוך הבנה שככל שנמצא את הבאג מוקדם יותר, עלות התיקון שלו תהיה נמוכה משמעותית).
שימו לב לגרף מימין, העלות לגילוי באג עולה אספוננציאלית ככל שמתקדם ציר זמן הפרויקט (http://tinyurl.com/yn9kncrz)
לשם דוגמא, נתונה דיאגרמת הבלוקים של התכן הנדרש לבדיקה בצד ימין, מערכת בסיסית לעיבוד תמונה.
לתכן הנדון ישנן הדרישות הבאות:
- תמיכה ברזולוציות וידאו שונות, ניתן על ידי קינפוג לעבור בין מצבים:
SD – 640x480
HD – 1280x720
Full HD – 1920x1080
2. דחיסה על ידי מיצוע של nxn כאשר n יכול להיות מ-1 עד 4, ללא חפיפות.
השלב הראשון בתהליך הוא כתיבת תוכנית בדיקות להתנהגות הלוגית (Test Plan)
- נדרוש להזריק את כל צירופי האפשרויות הקיימים (נעשה קרוס בין כל הרזולוציות לבין כל אפשרויות המיצוע) – סה"כ 3 * 4 = 12 אפשרויות.
- עבור כל אפשרות, נחשב את תמונת המיצוע הרצויה ונשווה אותה לזו המתקבלת מהדיזיין.
אם יש הבדל, נדפיס הודעת שגיאה ונפרט מה הפער.
- נדרוש לוודא נכונות פרוטוקולים (הזרקת פרוטוקול וידאו בכניסה ובדיקת פרוטוקול וידאו במוצא).
- חשיבה על ובדיקת מקרי קצה – נרצה להזריק תמונות בקצבים גבוהים ככל הניתן (30 פריימים בשנייה? 60?).
השלב הבא בתהליך וריפיקציה – בניית סביבת בדיקה (Test Bench)
- נרצה לבנות סביבת עבודה/בדיקה, שבה נוכל להזריק תמונות, לבצע קינפוג, לחשב את תמונת המיצוע הצפויה ולהשוות לזו שחישב הדיזיין.
נוכל (אפילו נעדיף) להשתמש במתודולוגיה נפוצה בשם UVM (Universal Verification Methodology).
- נרצה להשתמש במודולים משותפים שכבר בנויים, ואם אין כאלו נצטרך לבנות אותם בעצמנו.
המודולים הללו יצטרכו לדמות את הפרוטוקולים בצורה מדוייקת מצד אחד, ומצד שני לבדוק את נכונות הפרוטוקולים של הדיזיין.
- נוכל לבחור האם לבצע בדיקת black box – שבה נבדוק end to end – רק את התמונה במוצא,
או שנוכל לבצע בדיקת white box – נוכל לבדוק את התנהגות כל אחד מהמודולים בשרשרת.
המטרה שלנו תהיה לבנות סביבת עבודה נוחה, שתוכל לכסות את כל המקרים שתוארו במסמך הבדיקות (ובפרט את המקרים המעניינים ואת מקרי הקצה).
הסביבה צריכה לדווח על שגיאות בצורה ברורה, כך שתוכל לכוון אותנו ולאפשר לנו דיבאג יעיל ונוח ככל הניתן.
אנחנו רוצים מצד אחד יכולת שליטה גבוהה על המצבים הנבדקים (controllability), ומצד שני היכולת להתבונן
ולאבחן בקלות את הסביבה ואת התכן הנבדק (observability).
תהליך וריפיקציה – שלב קידוד הטסטים והרצתם
בשלב זה נקודד את הטסטים לפי תוכנית הבדיקות שהגדרנו.
נוודא את התנהגות הדיזיין אל מול מסמך הדרישות.
במידה וישנן אי תאימויות – נפעל מול הדיזיינר עד שיתוקנו (תהליך מעגלי).
מתי מסיימים? שאלה טובה וקשה! אפשר להריץ ולבדוק אינספור מקרים, נדרש מאיתנו לכסות את המקרים המעניינים
ביותר שלנו ולוודא שהם הורצו (אותם מקרים שהוגדרו בתוכנית הבדיקות).
התהליך ידרוש מאיתנו לעבוד בתיאום רב עם צוותים שונים – ארכיטקטורה (כדי להבין דרישות מערכת), אל מול הדיזיין,
אל מול צוותי תוכנה (למשל כדי להבין תהליכי קינפוג לתכן) ועוד צוותים שונים בשרשרת.
פה מודגם העיקרון של כתיבת קוד תוכנתי על מנת לבדוק היבטים חומרתיים.
סיכום
תהליך הוריפיקציה הוא תהליך מורכב, הדורש גישה והבנה חומרתית ותוכנתית.
מהנדס הוריפיקציה הוא נדבך חשוב ומרכזי בתהליך יצירת הצ'יפ.
מהנדס הוריפיקציה נדרש מצד אחד לשלוט בקרביים של התכן אותו הוא בודק, להבין מערכתית מה נדרש (כדי לא לבדוק תרחישים לא הגיוניים), ולהבין כיצד נראית הסביבה שבה חי הצ'יפ, מהן גישות התוכנה לצ'יפ, כיצד מקנפגים, מי הממשקים של התכן הנבדק ועוד.
אין סוף לתהליך הוריפיקציה, תמיד ניתן לבדוק עוד ועוד. לכן מהנדס הוריפיקציה צריך לבצע הפרדה בין העיקר לטפל,
להבין איך להגיע לרמת אמינות ווידוי גבוהות מאוד, בזמן הקצר ביותר, על מנת שתהליך ייצור הצ'יפ יוכל לעמוד בזמנים.מהנדס הוריפיקציה צריך להיות סקפטי ו"שובב" במהותו, להביא את התכן למקרי הקצה על מנת "להכשיל" אותו ובכך לאתר את נקודות הכשל של התכן הנבדק.
המטרה ברורה - להוציא צ'יפ בריא ומתפקד כראוי, ומהנדס הוריפיקציה שם בשביל להבטיח זאת!
