מה זה DFT Engineer? הסבר פשוט + כמה משרות פתוחות בישראל

DFT Engineer, ראשי תיבות של Design for Test, הוא מהנדס שמוסיף לתוך הצ'יפ חומרה שכל תפקידה לאפשר לבדוק אותו אחרי הייצור. בלי הלוגיקה הזאת אין דרך לדעת אם שבב שיצא מהוופר תקין או פגום. בלוח HiTakeJob פתוחות כרגע 9 משרות שמזכירות Verilog, ו-14 מהמשרות מסווגות בתחום הנדסת מוליכים למחצה.

למה אי אפשר פשוט להריץ טסטים על שבב מיוצר

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

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

שרשראות סריקה - הרעיון שמחזיק את כל התחום

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

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

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

ATPG וכיסוי תקלות

מי מייצר את הווקטורים האלה? כלי ATPG, ראשי תיבות של Automatic Test Pattern Generation. הכלי מקבל את ה-netlist ואת מודל התקלות ומחפש לכל תקלה אפשרית וקטור שמקיים שני תנאים: הוא גורם לנקודה הפגומה לקבל ערך הפוך מהתקלה, והוא מוליך את ההבדל הזה עד לפליפ-פלופ שאפשר לשאוב ממנו.

מודל תקלה	מה הוא מייצג	למה הוא לא מספיק לבדו
Stuck-at	צומת תקוע ב-0 או ב-1	לא תופס פגמים שתלויים במהירות
Transition	מעבר שמתרחש לאט מדי	דורש שתי פעימות בתדר עבודה מלא
Bridging	קצר בין שני מוליכים שכנים	דורש מידע על הפריסה הפיזית
IDDQ	זרם דליפה חריג במנוחה	נחלש מאוד בתהליכים מתקדמים
Cell-aware	פגמים בתוך התא הסטנדרטי עצמו	מספר הווקטורים גדל משמעותית

המדד שכל הדיון סובב סביבו הוא fault coverage: אחוז התקלות במודל שהווקטורים מצליחים לזהות. יעד של כ-99 אחוז במודל stuck-at נפוץ בשבבים מסחריים, והפער האחרון בין 97 ל-99 הוא בדרך כלל החלק שגוזל את רוב עבודת ה-DFT. תקלה שנשארת מחוץ לכיסוי היא בדרך כלל לוגיקה שאי אפשר לשלוט בה או לצפות בה: מעגל אסינכרוני, לוגיקה סביב אתחול, או חלק שהושתק בכוונה.

JTAG ו-boundary scan - הרמה שמעל הצ'יפ

גם שבב תקין לחלוטין יכול להיות מולחם רע ללוח. boundary scan לפי תקן IEEE 1149.1, המוכר בשם JTAG, מוסיף תא סריקה ליד כל פין חיצוני, כך שאפשר לנעול פין לערך מסוים ולקרוא את הפין של השבב השכן. כך מאתרים הלחמה קרה או גשר בין רגליים בלי מגע מכני של מחט בדיקה.

הממשק בנוי מארבעה אותות בסיסיים: TCK לשעון, TMS לניווט במכונת המצבים, TDI לכניסת נתונים ו-TDO ליציאה, ולעיתים גם TRST לאיפוס. אותה מכונת מצבים משמשת בהמשך גם למטרות אחרות לגמרי: טעינת ווקטורי סריקה, גישה לרגיסטרי דיבאג של המעבד ותכנות זיכרון. זו הסיבה שמפתח Embedded שמחבר מכשיר דיבאג פוגש בדיוק את הממשק שמהנדס DFT תכנן שנים קודם לכן.

MBIST - זיכרונות שבודקים את עצמם

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

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

למה עלות הבדיקה קובעת את כלכלת השבב

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

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

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

מה צריך לדעת בפועל, ומה שואלים בראיון

הבסיס הוא Verilog או SystemVerilog ברמת קריאה והבנה של netlist, היכרות עם זרימת סינתזה, וסקריפטינג ב-Tcl וב-Python. חלק גדול מהיום עובר בהרצת כלים, בפענוח דוחות ובכתיבת סקריפטים שמשווים תוצאות בין ריצה לריצה. מעל זה נדרשת היכרות עם כלי ATPG ועם סביבת הבדיקה עצמה.

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

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

שאלות נפוצות

האם DFT זה תפקיד חומרה או תוכנה?

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

מה ההבדל בין DFT לבין אימות?

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

מה זה כיסוי תקלות של 99 אחוז, ולמה לא 100?

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

אפשר להיכנס ל-DFT בלי ניסיון בשבבים?

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

מה זה scan compression ולמה צריך אותו?

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

איך DFT משפיע על שאר צוותי התכנון?

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

מה זה silicon bring-up ומה חלקו של DFT בו?

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