מה זה Verification (VLSI)? הסבר פשוט + כמה משרות פתוחות בישראל

Verification בעולם ה-VLSI הוא התחום שמוודא שתכנון הצ'יפ עושה בדיוק את מה שהמפרט דורש, לפני שהוא נשלח לייצור. זו עבודה של בניית סביבת בדיקה בתוכנה שמפעילה את החומרה ומשווה תוצאות. בלוח HiTakeJob פתוחות כרגע 9 משרות שמזכירות Verilog, ו-6 משרות נושאות verification engineer בכותרת.

מה בדיוק מאמתים: כוונה מול מימוש

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

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

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

שלוש רמות של אימות

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

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

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

Directed מול Constrained-Random

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

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

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

UVM - למה מתודולוגיה ולא סתם טסטבנץ'

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

רכיב	התפקיד שלו
Sequence	מתאר רצף טרנזקציות ברמה מופשטת, בלי אותות
Sequencer	מזרים טרנזקציות מהרצף אל הדרייבר
Driver	מתרגם טרנזקציה לאותות ממשיים על הפינים
Monitor	מאזין לפינים ומשחזר מהם טרנזקציות
Agent	אורז יחד sequencer, driver ו-monitor לממשק אחד
Scoreboard	משווה בין מה שיצא לבין מה שמודל הייחוס צפה
Environment	מחבר את כל הסוכנים והבודקים לסביבה אחת

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

כיסוי פונקציונלי וסגירת כיסוי

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

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

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

אסרשנים - SVA

אסרשן הוא כלל שנכתב בשפת SystemVerilog Assertions ונבדק בכל מחזור שעון, במקביל לבדיקה עצמה. במקום לבדוק את התוצאה בסוף, הוא צועק ברגע שהופר חוזה פנימי.

• אימות פרוטוקול: אחרי שהעליתי request, חובה שיגיע ack בתוך עד שישה מחזורים.
• בטיחות מבנית: אסור שיהיו write ו-read לאותה כתובת באותו מחזור.
• שלמות נתונים: אסור שה-FIFO ידווח על עצמו כמלא וכריק בו זמנית.
• חד-חמיות: בדיוק אות אחד מתוך קבוצת הבחירה פעיל בכל רגע.

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

אימות פורמלי - מתי הוא מנצח סימולציה

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

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

אמולציה ופרוטוטייפינג - כשסימולציה איטית מדי

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

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

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

למה באג שנמצא מאוחר עולה respin

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

זו הסיבה שתעשיית השבבים משקיעה באימות באופן שנראה מוגזם למי שמגיע מתוכנה. בתוכנה באג מתוקן בגרסה הבאה ומופץ באותו יום. בסיליקון אין גרסה הבאה זולה. ההבדל הזה הוא גם מה שמסביר את הפער בתרבות הבדיקה בין התחומים, כפי שתיארנו במאמר על בדיקות ידניות.

שאלות נפוצות

האם מהנדס אימות כותב קוד?

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

מה ההבדל בין אימות לבין QA בתוכנה?

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

מה זה functional coverage לעומת code coverage?

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

למה מריצים אלפי זרעים ולא אחד?

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

מה נדרש כדי להיכנס לתחום?

הנדסת חשמל או מחשבים, שליטה ב-SystemVerilog, הבנה של עיצוב דיגיטלי ברמה שמאפשרת לקרוא RTL, ונוחות עם Linux וסקריפטים. היכרות עם UVM היא יתרון משמעותי, ורוב החברות מלמדות אותה בפנים למי שהבסיס אצלו חזק. נקודת פתיחה טובה לחיפוש היא 12 המשרות שמזכירות Verilog בלוח, ולצידן 14 המשרות המסווגות בהנדסת מוליכים למחצה. טווחי שכר שמצוטטים בקהילות הם הערכת שוק בלבד ולא נתון שקיים אצלנו.

האם אימות פורמלי מחליף סימולציה?

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

איפה יושב האימות ביחס לשאר צוותי השבב?

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