ניפוי באגים ב-Microsemi In-Circuit FPGA

מידע על המוצר

מפרטים

• סוג מכשיר: Microsemi SmartFusion2 SoC FPGA
• תאריך יציאה: מאי 2014
• יכולות ניפוי באגים: איתור באגים במעגל FPGA, מנתח לוגי משובץ
• תדירות לכידת נתונים מקסימלית: עד 100MHz

תַקצִיר
FPGAs הם אלמנטים עיצוביים רבי עוצמה במערכות משובצות עם יתרונות עיצוב רביםtages, אבל להתקנים אלה יכולים להיות עיצובים מורכבים עם בעיות עיצוב מורכבות שיש לנפות באגים. מעקב אחר בעיות עיצוב כגון שגיאות הגדרה, בעיות אינטראקציה עם מערכת ושגיאות תזמון מערכת יכול להיות אתגר. הכללת יכולות ניפוי באגים בתוך מעגל ב-FPGA יכולה לשפר באופן דרמטי את ניפוי חומרה, ולהימנע מספור שעות של תסכול. מאמר זה מתאר מספר גישות שונות לניפוי באגים במעגל עבור FPGAs, מזהה פשרות מרכזיות ודרך אקסיתampהעיצוב, המיועד למכשיר Microsemi SmartFusion®2 SoC FPGA, יראה כיצד ניתן להשתמש ביכולות חדשות כדי להאיץ באגים ולבדוק.

מָבוֹא

FPGAs הם אלמנטים עיצוביים נרחבים וחזקים ונמצאים כעת כמעט בכל מערכת משובצת. עם הגדלת הקיבולת, הכללת בלוקים פונקציונליים מורכבים על-שבב וממשקים טוריים מתקדמים, להתקנים אלה עלולות להיות גם בעיות עיצוב מורכבות שיש לנפות באגים. מעקב אחר בעיות כגון שגיאות הגדרה פונקציונלית (ברמת FPGA או מערכת), בעיות אינטראקציה עם מערכת פונקציונלית, בעיות תזמון מערכת ובעיות נאמנות האות בין ICs (כמו רעש, הצלבה או השתקפויות) כולם הופכים למורכבים הרבה יותר בעת שימוש ב-FPGAs מתקדמים. סימולציה היא ללא ספק עזרה גדולה בזיהוי בעיות עיצוב רבות, אך אינטראקציות רבות בעולם האמיתי לא יופיעו עד שהעיצוב מיושם בחומרה. מספר טכניקות שונות לאיתור בעיות עיצוב מורכבות פותחו כדי לפשט את התהליך. הבנה מדוקדקת של כל אחת מהטכניקות המרכזיות הללו, כולל היתרונות השוניםtages and disadvantages, שימושי כאשר שוקלים איזו טכניקה או שילוב של טכניקות מתאים לעיצוב מסוים.
אקסampעיצוב FPGA, המיועד למכשיר Microsemi SmartFusion2 SoC FPGA, יכול לשמש כדי להדגים חלק מהיתרונותtages and disadvantagטכניקות סטנדרטיות אלה כמו גם יכולות ניפוי באגים החדשות ביותר במעגל. האקס הממחיש הזהample יראה כיצד ניתן להשתמש בטכניקות השונות הללו כדי להאיץ את הזיהוי והביטול של בעיות חומרה במהלך ניפוי חומרה.

מדוע איתור באגים ב-FPGA הוא היבט קריטי של עיצוב ופיתוח מערכת?
ל-FPGA יש שני דגמי שימוש עיקריים המבדילים אותם מאלמנטים עיצוביים אחרים. FPGAs יכולים לשמש במוצר הייצור או יכולים לשמש ככלי פיתוח להוכחה או אבטיפוס של רעיון עיצוב ייצור. כאשר משתמשים בהם ככלי הייצור, FPGAs יכולים להיות יעד גמיש הרבה יותר מאשר רכבי ייצור מבוססי ASIC או CPU. זה חשוב במיוחד עבור עיצוב חדש, כזה שעדיין לא יושם בחומרה. ניתן ליצור ולבדוק בקלות עיצובים עם אפשרויות אדריכליות שונות כך שהעיצוב האופטימלי מזוהה. FPGAs עם מעבדים על שבב (SoC FPGAs) מאפשרים גם להחליף עיבוד מבוסס CPU עם פונקציות האצה מבוססות FPGA בעזרת חומרה. אדוואנים אלהtages יכול לצמצם באופן דרמטי את הזמן הדרוש לתכנון, אימות, בדיקה וניתוח כשלים עבור פיתוחי מוצרים חדשים.
כאשר משתמשים בהם ליצירת אב טיפוס של עיצוב, אולי עבור ASIC ייצור, גמישות FPGA היא יתרון מרכזי. פלטפורמת חומרה בפועל, אפילו כזו שאינה פועלת במלוא המהירות, מקלה בהרבה על השגת מדדי ביצועי מערכת מפורטים, נתוני ניתוח תפוקה ותוצאות הוכחת ארכיטקטורה. תמיכת FPGA עבור יישומים מוקשחים של אפיקים סטנדרטיים בתעשייה (כמו PCIe®, Gigabit Ethernet, XAUI, USB, CAN ואחרים) מפשטת את הבדיקות הקשורות לממשקים אלה. המשפחות החדשות ביותר של FPGAs עם מעבדי ARM על-שבב (SoC FPGAs), מקלות על יישומי אב-טיפוס עם מעבדים משובצים. ניתן להעביר קוד מעבד שפותח בעבר לאב הטיפוס וליצור קוד חדש במקביל למאמץ עיצוב החומרה.

השילוב הזה של מעבד סטנדרטי עם אפיקי ממשק סטנדרטיים מאפשר למנף את המערכת האקולוגית הגדולה של ספריות קוד זמינות, מנהלי התקנים, ממשקי API פונקציונליים, מערכות הפעלה בזמן אמת ואפילו מערכות הפעלה מלאות כדי ליצור אבטיפוס עובד בצורה הרבה יותר מהירה. בנוסף, ברגע שהעיצוב מתגבש, ניתן להשתמש באב-טיפוס ה-FPGA כדי ללכוד מערכי בדיקות סימולציה נרחבים (גם לגירוי וגם לתגובה) המשקפים נתוני מערכת בפועל. מערכי נתונים אלה יכולים להיות בעלי ערך רב ביצירת הסימולציות הסופיות עבור יישום ASIC או ייצור אחר. האדוואןtagשיטות השימוש ב-FPGA כאב-טיפוס לתכנון יכולות לצמצם באופן דרמטי את הזמן לתכנון, אימות, בדיקה וניתוח כשלים ליישום המוצר הסופי.
בשני דגמי השימוש הנפוצים ב-FPGA, הגמישות של ה-FPGA כיעד עיצובי היא יתרון מרכזיtagה. המשמעות היא ששינויי עיצוב ואיטרציות רבים יהיו הנורמה, ולפיכך היכולת לנפות שגיאות תכנון במהירות תהיה קריטית כדי לאפשר אפשרויות עיצוב רבות ככל האפשר. ללא יכולת ניפוי באגים יעילה חלק גדול מה-advantage של גמישות עיצוב FPGA תפחת על ידי זמן איתור הבאגים הנוסף הנדרש. למרבה המזל, FPGAs יכולים לספק גם תכונות חומרה נוספות המפשטות באופן דרמטי את איתור באגים בזמן אמת. לפני שנסתכל על היכולות הללו, בואו נסתכל תחילה על הסוגים הנפוצים ביותר של בעיות שעיצוב FPGA עשוי להיות מתמודד איתן, כך שיהיה לנו את הרקע המתאים להעריך את היעילות והפשרות הנלוות של כלי ניפוי באגים שונים.

בעיות נפוצות בעת איתור באגים בעיצובי FPGA

יחד עם היכולות המורחבות שמביאות רכיבי FPGA מודרניים, המורכבות המוגברת הקשורה מקשה על יצירת עיצובים ללא שגיאות. למעשה, ההערכה היא כי איתור באגים יכול לקחת למעלה מ-50% ממחזור תכנון המערכת המשובצת. עם לחצים מהזמן לשוק שממשיכים לסחוט את מחזור הפיתוח, איתור באגים בחומרה של המערכת הראשונית נדחק למחשבה שלאחר מכן - לעתים קרובות מדי בהנחה שהאימות הזה (כשלעצמו הוא אחוז גדולtage של לוח הזמנים של הפיתוח), יתפוס את כל הבאגים לפני העלאת המערכת הראשונית. הבה נסתכל רק על כמה סוגים נפוצים של בעיות מערכת כדי להבין טוב יותר את האתגרים שעומד בפני עיצוב טיפוסי במהלך העלאת המערכת הראשונית.

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

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

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

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

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

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

גישות נפוצות לניפוי באגים בתוך מעגל עבור FPGAs
הטכניקות הנפוצות ביותר להטמעת יכולות ניפוי באגים במעגל ב-FPGA משתמשות בנתח לוגי משובץ, בציוד בדיקה חיצוני או בחומרה ייעודית של בדיקת אות המוטמעת בתוך מארג ה-FPGA. מנתח ההיגיון המוטבע מיושם בדרך כלל באמצעות מארג FPGA ומוכנס לעיצוב. ה-JTAG היציאה משמשת לגישה לנתח וניתן להציג את הנתונים שנלכדו במחשב. כאשר נעשה שימוש בציוד בדיקה חיצוני, עיצוב ה-FPGA הנבדק משתנה כך שאותות FPGA פנימיים נבחרים מנותבים לפיני פלט. לאחר מכן ניתן לצפות בסיכות אלו דרך ציוד הבדיקה החיצוני. כאשר נעשה שימוש בחומרה ייעודית לבדיקת אותות, ניתן לקרוא מבחר רחב של אותות פנימיים בזמן אמת. מיישומי בדיקה מסוימים יכולים לשמש אפילו לכתיבה לרישום או למיקומי זיכרון, מה שמשפר עוד יותר את יכולות ניפוי הבאגים. בואו נסתכל ביתר פירוט על ה-advantages and disadvantages של כל אחת מהטכניקות הללו ואז תסתכל על אקסampעצבו כדי לראות כיצד הגישות השונות הללו יכולות להשפיע על זמן ניפוי הבאגים הכולל.

In-Circuit FPGA Debug-Embedded Logic Analyzer
הרעיון של מנתח ההיגיון המוטבע היה תוצאה ישירה של יכולות ניפוי באגים אד-הוק במעגל שהטמיעו מעצבים כאשר נעשה שימוש לראשונה ב-FPGA. מנתחי לוגיקה משובצים הוסיפו יכולות חדשות וביטלו את הדרישה מהמעצב לפתח מנתח משלו. רוב ה-FPGAs מציעים את היכולות הללו וצדדים שלישיים מציעים מנתחים סטנדרטיים (Identify®, מ-Synopsys, הוא אחד האקסים הפופולרייםample) שיכול להתממשק בקלות עם כלים ברמה גבוהה יותר כדי לשפר עוד יותר את הפרודוקטיביות.

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

האדוואןtagהיסודות של גישה זו הם שלא נעשה שימוש בפינים נוספים של FPGA I/O, אלא רק ב-J הסטנדרטיTAG אותות. ליבות ה-IP של מנתח ההיגיון המשובץ הן בדרך כלל זולות יחסית ובמקרים מסוימים יכולות להוות אופציה לסינתזת FPGA קיימים, או לכלי סימולציה. במקרים מסוימים, מנתח הלוגי המשובץ יכול לספק פלטים נוספים גם ב-I/O לא בשימוש, אם זה נוח יותר. אחד החסרונותtagהגישה הזו היא שנדרשת כמות גדולה של משאבי FPGA. בפרט, אם נעשה שימוש במאגרי מעקב זה יקטין את מספר זיכרונות הבלוק הזמינים. אם יש צורך במאגר רחב, זה יהיה גם פשרות מול עומק הזיכרון (מאחר שהשימוש בזיכרון רחב יותר מביא לעומק זיכרון רדוד יותר) - חיסרון גדולtagה בעת שימוש במכשירים קטנים יותר. אולי החיסרון הגדול ביותר בטכניקה זו הוא שבכל פעם שמתבצעת התאמה למיקום הבדיקה, יש צורך להדר מחדש ולתכנת מחדש את התכנון. בעת שימוש במכשיר גדול תהליך זה יכול לקחת פרק זמן משמעותי. בשל האופן שבו ממוקמים בדיקות האותות בתכנון, יכול להיות קשה לתאם את יחסי תזמון האות. בנוסף, העיכובים בין בדיקות האות אינם עקביים ולכן קשה להשוות יחסי תזמון. זהו קושי מיוחד כאשר משווים אותות אסינכרוניים או אותות מתחומי זמן שונים.

In-Circuit FPGA Debug - ציוד בדיקה חיצוני
השימוש בקוד ניפוי באגים במעגל בשילוב עם ציוד בדיקה חיצוני היה התפתחות טבעית כאשר מנתח לוגי חיצוני כבר היה זמין לבדיקת מערכת. על ידי יצירת קוד איתור באגים פשוט כדי לזהות ולבחור אותות בדיקה פנימיים ולהחיל אותם על I/O FPGA, כפי שמוצג באיור 3, ניתן היה למנף את היכולות המתקדמות של הנתח (כגון מאגרי מעקב גדולים, רצפי הפעלה מורכבים וריבוי viewאפשרויות) כדי ליצור סביבות ניפוי באגים פשוטות אך חזקות. יכולות מורכבות יותר במעגל עבור אפשרויות הפעלה מתקדמות יכולות למזער את מספר הפלטים הדרושים. למשלample, בחירת כתובות ספציפיות באפיק רחב עשויה להיות אוסרת אם נדרשו פינים חיצוניים.
שימוש בלוגיקה פנימית של FPGA מפחית באופן דרמטי את דרישות ה-I/O ואף יכול לחפש דפוסי כתובת ספציפיים (אולי רצף שיחה והחזרה) לאיתור בעיות מורכבות יותר. אם ממשק משתמש משותף זמין, זה יכול לפשט את עקומת הלמידה ולשפר את הפרודוקטיביות.

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

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

Debug FPGA בתוך המעגל - בדיקות חומרה
השימוש בבדיקות חומרה מפשט באופן דרמטי את טכניקות ניפוי באגים במעגל עבור FPGAs. טכניקה זו המיושמת כמאפיין Live Probe בהתקני SmartFusion2®SoC FPGA ו-IGLOO®2 FPGA, מוסיפה קווי בדיקה ייעודיים למארג ה-FPGA כדי לצפות בפלט של כל סיבי רגיסטר אלמנט לוגי. כפי שמוצג בתרשים הבלוק באיור 4, בדיקות חומרה זמינות בשני ערוצי בדיקה A ו-B.

יציאות אוגר נבחרות (נקודות בדיקה), כמו זו שמקורה בתחתית האיור, מנותבת מעל שני ערוצי הבדיקה ואם נבחרה ניתן להחיל אותן על ערוץ A או B. לאחר מכן ניתן לשלוח אותות ערוץ בזמן אמת לפינים ייעודיים של Probe A ו-Probe B במכשיר. ניתן גם לנתב את האותות Probe A ו-Probe B באופן פנימי לנתח לוגי משובץ.

שימו לב שמאפייני התזמון של פיני הבדיקה הם סדירים ויש להם סטייה זניחה מנקודת בדיקה אחת לאחרת, מה שמקל בהרבה על השוואת מאפייני התזמון של האותות בזמן אמת. ניתן ללכוד נתונים במהירות של עד 100 מגה-הרץ, מה שמתאים לרוב עיצובי היעד.
אולי הכי חשוב את מיקומי נקודות הבדיקה, מכיוון שהם לא נבחרים כחלק מהתכנון המיושם (הם נבחרים באמצעות חומרה ייעודית בזמן שהעיצוב פועל על ה-FPGA), ניתן לשנות במהירות על ידי שליחת נתוני הבחירה למכשיר. אין הידור מחדש של העיצוב ויש צורך בתכנות מחדש.
כדי לפשט עוד יותר את השימוש ביכולת ה-Live Probe, לכלי תוכנת ניפוי הבאגים המשויך יש גישה לכל מיקומי אותות הבדיקה באמצעות ניפוי באגים שנוצר אוטומטית file. כפי שמוצג באיור 5, ניתן לבחור את שם האות מרשימת האותות ולהחיל אותו על הערוץ הרצוי. ניתן לעשות זאת גם בזמן שהעיצוב פועל כך שפעילות הגישוש בתוך העיצוב תהיה חלקה ויעילה מאוד.

במקרים רבים, ניתן להשתמש ביכולת בדיקת החומרה, כמו Live Probe, בשילוב עם מנתח ההיגיון המשובץ שתואר קודם לכן וטכניקות הבדיקה החיצוניות.

כפי שמוצג באיור 6, יכולת ה- Live Probe לבחירת אותות 'בתנועה' מאפשרת לשנות במהירות ובקלות את האותות המצויים בתצפית מבלי צורך להדר מחדש את העיצוב. מנתח לוגי חיצוני או היקף יכול לצפות בקלות באותות הנבדקים, כפי שמוצג בחלק הימני העליון של האיור על פיני מוצא הבדיקה הייעודיים. לחלופין (או אולי אפילו בנוסף) ניתן להשתמש בנתח הלוגיקה הפנימי (גוש ILA Identify, המוצג באיור) כדי לצפות בפיני הבדיקה. את אותות הבדיקה ניתן ללכוד על ידי ILA ולצפות בחלון צורת הגל. ניתן לשנות את מיקומי הבדיקה ללא צורך להדר מחדש את עיצוב היעד.
שימו לב שניתן להשתמש ביכולות הנוספות להפעלה ומעקב כדי לשפר את פונקציונליות הבדיקה, מה שמקל על זיהוי אפילו בעיות עיצוב מורכבות.

יכולות ניפוי חומרה נוספות זמינות גם בהתקני SmartFusion2 SoC FPGA ו-IGLOO2 FPGA. אחת מהיכולות הללו, הנקראת Active Probe, יכולה לקרוא או לכתוב באופן דינמי וא-סינכרוני לכל סיבי רגיסטר אלמנט לוגי. ערך כתוב נמשך במשך מחזור שעון בודד, כך שהפעולה הרגילה יכולה להמשיך, מה שהופך אותו לכלי איתור באגים בעל ערך רב. בדיקה פעילה מעניינת במיוחד אם יש צורך בתצפית מהירה של אות פנימי (אולי פשוט לבדוק שהוא פעיל או במצב הרצוי, כמו אות איפוס), או אם יש צורך לבדוק במהירות פונקציה לוגית על ידי כתיבה לנקודת בדיקה
(אולי ליזום מעבר של מכונת מצב על ידי הגדרה מהירה של ערך קלט כדי לבודד בעיית זרימת בקרה).

יכולת ניפוי באגים נוספת שמספקת Microsemi היא Memory Debug. תכונה זו מאפשרת למעצב לקרוא או לכתוב באופן דינמי וא-סינכרוני לבלוק SRAM נבחר של בד FPGA. כפי שמודגם בצילום המסך של כלי ניפוי הבאגים (איור 7), כאשר הכרטיסייה Memory Blocks נבחרה המשתמש יכול לבחור את הזיכרון הרצוי לקריאה, לבצע לכידת תמונת מצב של הזיכרון, לשנות ערכי זיכרון, ולאחר מכן לכתוב את הערכים בחזרה למכשיר. זה יכול להיות שימושי במיוחד עבור בדיקה או הגדרת מאגרי נתונים המשמשים ביציאות תקשורת עבור משטח גירוד מונחה חישוב או אפילו עבור קוד המופעל על ידי מעבד מוטבע. איתור באגים של שגיאות מורכבות תלויות נתונים הוא מהיר וקל יותר באופן משמעותי כאשר ניתן לצפות בזיכרונות ולשלוט בהם כל כך מהר.

לאחר ניפוי באגים בעיצוב, ייתכן שרצוי לבטל את יכולות ניפוי הבאגים בחומרה כדי להגן על מידע רגיש. תוקף יכול להשתמש באותם מתקנים כדי לקרוא מידע קריטי או לשנות הגדרות מערכת שיכולות לאפשר גישה נוחה לחלקים רגישים של המערכת. Microsemi הוסיפה תכונות כדי לאפשר למעצב לאבטח את המכשיר לאחר השלמת ניפוי הבאגים. למשלample, ניתן לנעול גישה ל-Live Probe ול-Active Probe כדי להשבית לחלוטין את הפונקציה כאמצעי תקיפה אפשרי (זה אפילו מבטל את האפשרות של פעילות בדיקה ליצור כל דפוס בזרם האספקה ​​שיכול לשמש כדי לנסות ולצפות בנתוני בדיקה בעקיפין). לחלופין, ניתן לנעול גישה לחלקים נבחרים בעיצוב כדי למנוע גישה רק לחלקים אלו. זה יכול להיות נוח אם רק חלק מהתכנון צריך להיות מאובטח, מה שהופך את שאר העיצוב עדיין נגיש לבדיקות בשטח או לניתוח שגיאות.

תרשים השוואת ניפוי באגים בתוך המעגל
כעת, כאשר מפורט מחדשview מתוך שלוש טכניקות ניפוי חומרה במעגל העיקריות תוארו טבלת סיכום, כפי שמוצג באיור 8, המפרטת את היתרונות השוניםtages and disadvantages של כל שיטה. לזכור שניתן להשתמש בטכניקות מסוימות ביחד (בדיקה חיה ומנתח לוגיקה פנימית (ILA), כמו Synopsys Identify, למשלample), נוכל לראות את החוזקות והחולשות העיקריות של כל טכניקה. האוסף של יכולות ניפוי חומרה במעגל (Live Probe, Active Probe ו-Memory Debug - הנקראים ביחד SmartDebug), הם החלשים ביותר בהשוואה לטכניקות האחרות בכל הנוגע למספר הבדיקות הכוללות הזמינות (עיגול אדום) והן חלשות מהטובות ביותר (עיגול צהוב) כאשר מהירות הלכידה נחשבת מהירה יותר (ציוד בדיקה חיצוני יותר).
טכניקות מבוססות ILA, כמו Synopsys Identify, הן החלשות ביותר בהשוואה לטכניקות אחרות וכאשר נלקחות בחשבון דרישות משאבי FPGA. טכניקות המבוססות על ציוד בדיקה חיצוני הן החלשות ביותר על פני מספר שיקולים, כאשר העלות, השפעת תזמון התכנון ותקורה של תנועת בדיקה (בשל הצורך להדר מחדש את התכנון) הם המכבידים ביותר. אולי הפתרון האופטימלי הוא שילוב של SmartDebug ואחת הטכניקות האחרות, כך שניתן יהיה למתן את חולשת מספר הערוצים של SmartDebug ולחסרון תנועת נקודת הבדיקה.tagגם הטכניקות האחרות הצטמצמו.

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

מקרה שימוש פשוט של ניפוי באגים

כעת, לאחר שיש לנו הבנה טובה יותר של אפשרויות ניפוי הבאגים השונות במעגל, בואו נסתכל על דוגמה עיצובית פשוטהampכדי לראות כיצד טכניקות אלו מתפקדות. איור 9, מציג עיצוב FPGA פשוט בהתקן SmartFusion2 SoC FPGA. תת-מערכת המיקרו-בקר (MSS) מאופסת על ידי בלוק CoreSF2Reset Soft IP. הכניסות לבלוק זה הן איפוס ההפעלה, איפוס בד משתמש ואיפוס חיצוני. היציאות הן איפוס ל-User Fabric, איפוס MSS ואיפוס M3. תסמיני השגיאה הם שאין פעילות ב-I/Os למרות שהמכשיר יוצא ממצב POR בהצלחה. שלוש האפשרויות השונות לאיתור שגיאה זו מוצגות גם באיור: הקופסה הכחולה (מסומנת ETE) מיועדת לשיטת ציוד בדיקה חיצוני; הקופסה הירוקה (שכותרתה ILA) מיועדת לשיטת ה-Internal Logic Analyzer; והתיבה הכתומה (מסומנת AP) מיועדת לשיטת Active Probe. אנו נניח שגורמי השורש הפוטנציאליים של השגיאה הם כניסות איפוס לא תקין לבלוק CoreSF2Reset Soft IP.

הבה נסתכל כעת על תהליך ניפוי הבאגים עבור שלוש מהשיטות המתוארות בעבר במעגל.

ציוד בדיקה חיצוני
בשיטה זו, ההנחה היא שציוד הבדיקה זמין ואינו נמצא בשימוש פרויקט בעדיפות גבוהה יותר. בנוסף, חשוב לתכנן מראש כך שחלק מ-I/O FPGA יהיו זמינים וניתן לחבר אותם בקלות לציוד הבדיקה. עם כותרת על ה-PCB למשלample, יהיה מאוד מועיל ולמזער את הזמן המושקע בניסיון לזהות ולהתחבר ל'חשוד סביר' או לקצר פוטנציאלי של פינים במהלך גישוש. יהיה צורך לבצע קומפילציה מחדש של העיצוב כדי לבחור את האותות שאנו רוצים לחקור. אנו מקווים שלא 'נקלף את הבצל' ונצטרך לבחור סימנים נוספים לחקירה נוספת, מכיוון שלעתים קרובות החקירה הראשונית שלנו רק מביאה לשאלות נוספות. בכל מקרה, תהליך הקומפילציה והתכנות מחדש יכול לקחת פרק זמן משמעותי, ואם הוא גורם להפרות תזמון נדרש עיצוב מחדש (כולנו מכירים כמה מתסכל ניסיון לפתור בעיות סגירה בתזמון יכול להיות, במיוחד כאשר אתה מבצע את השינויים בעיצוב כדי למצוא באג עיצובי - התהליך כולו יכול לקחת בין דקות לשעות)! חשוב גם לזכור שאם לעיצוב אין I/O משתמש חינמי, לא ניתן ליישם שיטה זו. יתרה מכך, שיטה זו חודרת מבחינה מבנית לעיצוב - ובאגים הקשורים לתזמון עשויים להיעלם או להופיע שוב בין איטרציות.

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

בדיקה פעילה
באמצעות שיטה זו ניתן להצביע על ה-Active Probe אל המקור של אותות האיפוס השונים, שמקורם כולם על ידי יציאות אוגר (כפי שמקובל בכל שיטות תכנון דיגיטליות טובות). האותות נבחרים אחד בכל פעם, מתפריט Active Probe המוצג באיור 10 למטה. ניתן לקרוא את ערכי האות שנבחרו והם מוצגים בחלון נתוני הבדיקה הפעילה. כל הצהרות מוטעות מזוהות בקלות. בדיקה זו יכולה להיעשות באופן מיידי ללא צורך להדר מחדש ולתכנת מחדש את המכשיר ואינה חודרנית מבחינה מבנית או פרוצדורלית. כל התהליך לוקח שניות בודדות. שיטה זו יכולה גם ליצור שליטה (שינוי ערכים באופן אסינכרוני) ששתי השיטות האחרות לא יאפשרו. באקס המסוים הזהample, ניתן לבחון בקלות את אות האיפוס שמקורו בפנקס ולגלות שהוא מוחזק במצב פעיל.

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

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

אם הוא אינו פועל בתדירות הנכונה, יגרמו השגיאות המתוארות.

במצב זה כנראה אסטרטגיה טובה יותר להחליף את גישת ה-Active Probe ב-Live Probe. זה מומחש באיור לעיל על ידי קופסת ה-LP בצבע כתום, באמצעות ה-JTAG אות עבור בחירת מקור הבדיקה.

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

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

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

תכונות ניפוי באגים אחרות עבור ממשקים טוריים
חשוב גם לציין שישנן יכולות ניפוי באגים רבות נוספות בהתקני SmartFusion2 SoC FPGA ו-IGLOO2 FPGA שניתן להשתמש בהם בממשקים טוריים, כמו זה בקוד הקודם.ampהעיצוב שבו השגיאות מסובכות אפילו יותר. SERDES Debug, למשלample, מספק יכולות ניפוי באגים ספציפיות עבור הממשקים הטוריים המהירים הייעודיים. חלק מהתכונות של SERDES Debug כוללות תמיכת בדיקת PMA (כמו יצירת דפוסי PRBS ובדיקת לולאה חוזרת) תמיכה עבור תצורות בדיקה מרובות של SERDES עם קונפיגורציה מחדש ברמת הרישום כדי להימנע משימוש בזרימת העיצוב המלאה לביצוע שינויים בתצורה, ודוחות טקסט המציגים פרוטוקולים מוגדרים, אוגרי תצורה של SERDES ואוגרי תצורת נתיב. תכונות אלו הופכות את ניפוי הבאגים של SERDES להרבה יותר קל וניתן להשתמש בהם בשילוב עם Live Probe ו-Active Probe כדי להאיץ עוד יותר איתור באגים של מעגלים מורכבים.
ניתן להשתמש בכלי ניפוי באגים בזיכרון שתואר קודם לכן גם יחד עם בדיקת SERDES Debug to speed. מכיוון שניתן לבדוק ולשנות מאגרי זיכרון במהירות ובקלות באמצעות Memory Debug, ניתן ליצור במהירות 'מנות בדיקה' ולצפות בתוצאות של לולאה חוזרת או תקשורת בין-מערכתית. המעצב יכול למנף את היכולות הללו ובכך למזער את הצורך ב'רתמות בדיקה' מיוחדות שצורכות בד FPGA נוסף ושעשויות להשפיע על תזמון השבבים.

מַסְקָנָה
מאמר זה תיאר בפירוט מספר גישות שונות להטמעת ניפוי באגים במעגל עבור FPGAs ו-SoC FPGAs - השימוש ב-Integrated Logic Analyzer, השימוש בציוד בדיקה חיצוני ושימוש במעגלי בדיקה ייעודיים המשולבים במארג FPGA. תוספת של מעגלי בדיקה מיוחדים וייעודיים, כמו Active Probe ו-Live Probe המוצעים על ידי Microsemi במכשירי SmartFusion2 SoC FPGA ו-IGLOO2 FPGA, הוכחו כמזרזת ומפשטת משמעותית את תהליך ניפוי הבאגים. היכולת לשנות במהירות את בחירת האותות הפנימיים (ללא צורך לבצע מחזור הידור מחדש ותכנות מחדש שגוזל זמן רב), והיכולת לחקור אותות פנימיים (ללא צורך להשתמש במארג FPGA ואפשרות להציג הפרות תזמון) הוכחו כיתרונות משמעותייםtages בעת איתור באגים בעיצובי FPGA. בנוסף, תואר השימוש במתודולוגיות מרובות, שיכולות לעבוד יחד כדי לספק יכולת ניפוי באגים מקיפה עוד יותר. לבסוף, שניים לשעברampמקרי שימוש ב-le debug ניתנו כדי להמחיש את ההחלפות בין השיטות המתוארות.

למידע נוסף

1. IGLOO2 FPGAs
2. SmartFusion2 SoC FPGAs

Microsemi Corporation (Nasdaq: MSCC) מציעה סל מקיף של פתרונות מוליכים למחצה ומערכות לשווקי תקשורת, הגנה ואבטחה, תעופה וחלל ותעשייתיים. המוצרים כוללים מעגלים משולבים של אותות מעורבים אנלוגיים בעלי ביצועים גבוהים ומוקשים בקרינה, FPGAs, SoCs ו-ASICs; מוצרי ניהול חשמל; מכשירי תזמון וסנכרון ופתרונות זמן מדויקים, מציבים את הסטנדרט העולמי לזמן; מכשירים לעיבוד קול; פתרונות RF; רכיבים בדידים; טכנולוגיות אבטחה ואנטי-ט ניתן להרחבהampER מוצרים; Power-over-Ethernet ICs ו-midspans; כמו גם יכולות ושירותי עיצוב מותאמים אישית. מטה מיקרוסמי נמצא ב-Aliso Viejo, קליפורניה, ויש לו כ-3,400 עובדים ברחבי העולם. למידע נוסף ב www.microsemi.com.

© 2014 Microsemi Corporation. כל הזכויות שמורות. Microsemi והלוגו של Microsemi הם סימנים מסחריים של Microsemi Corporation. כל שאר הסימנים המסחריים וסימני השירות הם רכושם של בעליהם בהתאמה.

מטה התאגידים של Microsemi

• אֶחָד Enterprise, Aliso Viejo CA 92656 ארה"ב
• בְּתוֹך ארה"ב: +1 800-713-4113
• בָּחוּץ ארה"ב: +1 949-380-6100
• מכירות: +1 949-380-6136
• פַקס: +1 949-215-4996
• אֶלֶקטרוֹנִי: sales.support@microsemi.com

שאלות נפוצות

• ש: מהי תדירות לכידת הנתונים המקסימלית של המכשיר?
  ת: המכשיר תומך בלכידת נתונים במהירות של עד 100MHz, מתאים לרוב עיצובי היעד.
• ש: האם אני צריך להדר מחדש את התכנון בעת ​​שימוש במעגלי בדיקה לצורך איתור באגים?
  ת: לא, ניתן לשנות במהירות את מיקומי נקודות הבדיקה מבלי להידרש להידור מחדש של התכנון או לתכנות מחדש.

מסמכים / משאבים

ניפוי באגים ב-Microsemi In-Circuit FPGA [pdfהוראות Debug FPGA בתוך המעגל, Debug FPGA, Debug

הפניות

• מדריך למשתמש