אימות הפונקציונליות והביצועים בחיבורים הפנימיים של ה-SoC

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

באימות הפונקציונלי רוצים המהנדסים להבטיח שהשבב מרובה-הליבות מיישם את הפונקציות הנדרשות ובמקביל מתמודד עם שגיאות בצורה החלקה ביותר שאפשר. מנקודת מבט מעשית, המהנדסים רוצים לאמת את בלוקי ה-SoC IP ביחד עם החיבורים הפנימיים של השבב. במשימה הזו מעורבים שני שלבים. השלב הראשון הוא הצורך לאמת שבלוקי ה-IP מיישמים את פרוטוקול הממשק הנתון בצורה נכונה באמצעות IP אימות, צעד שיכול להתריע על כל הפרת פרוטוקול אפשרית.
הצעד השני הוא לאמת שהפקודות והנתונים יגיעו ליעדם הנכון ובפורמט הנכון. המתכננים ירצו לעקוב אחר סוגיות כמו פיצול, הגדלה או הקטנה של נתונים. שלב זה חשוב ביותר שכן ממשקים שונים על תת-המערכת של החיבורים הפנימיים משתמשים בפרוטוקולים שונים. יש לבצע אימות של פעולות כמו שיחות “ריגול”, הפצת ריגול, מסנן תוכנות ריגול ושורה “חוצת-מטמונים” (cross-cache). במילים אחרות, על המתכננים לוודא שהחיבור הפנימי המותאם לזכרון המטמון (cache coherent) מבצע בצורה טובה את תפקידו כרכיב האחראי על עקביות ולכידות. כדי לחסוך את הזמן שגוזלת גישה מרחוק לזיכרון, החיבור הפנימי העקבי “מרגל” אחרי המטמונים של המאסטרים הרלוונטיים ועל סמך התגובות שלהם קובע האם להחזיר את הנתונים המבוקשים מהמטמון או מהזיכרון המרוחק, ומעדכן את סטטוס שורת המטמון של המאסטרים הרלוונטיים בהתאם לממצאיו. התנהגות זו מוגדרת על-ידי פרוטוקול הקוהרנטיות (עקביות). אם החיבור הפנימי איננו תואם לפרוטוקול, מהר מאוד תיכנס המערכת למצב של חוסר עקביות וסביר להניח שתקרוס.
אימות ביצועים הוא המקום שבו חייבים המתכננים לוודא שהתכנון יעמוד ביעדים של רמות ההשהייה ורוחב הפס. ניקח לדוגמה תכנון SoC עם ריבוי חיבורים פנימיים שמיועד למנוע השפעות של התנועה המקומית על שאר תת-המערכות של ההתקן. ה-interconnect IP ממלא כאן תפקיד חשוב, שכן הוא יכול לכוונן כל כניסה (פורט) ולהתאימה לרוחבי אפיק ייחודיים, למפות כתובות ולמהירויות שעון. בדרך כלל קיימים גם מנגנונים להתאמה של רוחב הפס וההשהיה לכוונון ה-interconnect IP בכל תחום.
עם זאת, עדיין יהיו מקרים שבהם יתעוררו התנגשויות וקונפליקטים בתנועת הנתונים, כפי שניתן לראות בתרשים 1. כיצד ניתן לאזן את התנועה במצבים הללו? למרבית המערכות אין די רוחב פס של זיכרון ראשי כדי להתמודד עם מצב שבו כל בלוקי ה-IP פעילים באותה עת. מה שחשוב הוא למנוע מצב שבו בלוק IP אחד משתלט ומשבש את פעולתם של האחרים שכן מצב כזה יפגע בביצועי המערכת. ניתוח ביצועים יכול להועיל במצב כזה ולצמצם את הפגיעה בביצועי המערכת.
בתרשים זה, שלוש יחידות העובדות במקביל מהזיכרון. בעזרת ניתוח הביצועים ניתן לדעת האם צריך לאתחל מחדש את הפרמטרים של המערכת.
כדי לערוך ניתוח ביצועים על המתכננים להשוות מדדים של רוחב פס והשהיות מארכיטקטורות SoC שונות או ממקרי שימוש שונים ב-SoC. השוואה זו כרוכה במידול, בהרצת סימולציות ובמדידת ביצועים של שתי ארכיטקטורות SoC או יותר (בדרך כלל כמה), או של יישומים שונים של ארכיטקטורה ספציפית – משימה שלא מעשי לבצע באופן ידני. אחרי הכול, מאמצים ידניים יהיו כרוכים בבניית מערכי בדיקות סביב מגוון ארכיטקטורות ה-SoC שביניהם רוצים להשוות. במקרה של SoCs מורכבות – שבהן ניתוח וכוונון ביצועים יהיו חשובים במיוחד – יצירת מערכי הבדיקות הנדרשים עלולה בקלות לגזול כמה ימים ממהנדס מנוסה ואף הרבה יותר מכך כשמדובר במהנדס פחות מיומן.
כדי להפוך את ניתוח הביצועים לאפקטיבי ככל הניתן יש לשאוף לשלב בתוך התהליך את האלמנטים הבאים:

1. מידול מדויק למחזור
עם דיוק מחזור תוכל סימולציית הלוגיקה להפיק את אותו סדר אירועים עם אותו תזמון כפי שהם מופיעים בשבב האמיתי. מודלים של סימולציה מדויקים למחזור כוללים את ה-RTL-level, Verilog או HVDL שנוצרים במהלך תהליך תכנון ה-SoC

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

3. IP אימות
כפי שהוזכר קודם, IP אימות עוזר לאתר הפרות פרוטוקול

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

5. ניתוח מעמיק
היכולת לאסוף את כל נתוני הסימולציה – הערכות תכנון, מערך הבדיקות והתנועה – הכרחית כדי לנפות שגיאות ובעיות בביצועים ולקבוע כיצד עשויים שינויים בתכנון להשפיע על רוחב הפס וההשהיות.
קיידנס פיתחה כלי המספק דרך גרפית להשוות הרצות של סימולציית חיבורים פנימיים לצורך הערכה מהירה ומדויקת של ביצועי החיבורים הפנימיים. ה-Cadence Interconnect Workbench עוזר לאתר ולתקן בעיות בחיבורים הפנימיים בשלב מוקדם במחזור התכנון על מנת להשיג את רמות ההשהיות ורוחב הפס הנחוצות ל-SoC. השימוש בכלי – שזרימתו מוצגת בתרשים 2 – יאפשר למהנדסים להיפטר מגיליונות נתונים מסורבלים וליהנות מ-GUI עם מסננים מובנים כדי לבחור חיבורי מאסטר ו/או סלייב ואת הנתיב(ים) להערכה וביצוע של ניתוחי “מה אם”. ה-Interconnect Workbench משתלב עם ה-Cadence Interconnect Validator, רכיב IP אימות שאוסף את כל הטרנזאקציות ומאמת את מידת הדיוק וההשלמות של הנתונים כאשר הם עוברים דרך מארג החיבורים הפנימיים של ה-SoC. ה-Interconnect Validator מתחבר לכל אירועי ה-IP אימות ברמת הממשק (שעוקבים אחרי ההתנהגות הנכונה של הפרוטוקול של בלוקי ה-IP) ולפיכך יש לו הבנה מעמיקה של הנתונים והפקודות שיוצאים מהחיבורים הפנימיים ונכנסים אליהם. באמצעות התאמה של נתונים אלה יכול הכלי לאמת האם הנתונים נשלחים ליעד הנכון. במקרה שחיבור פנימי אינו פועל בהתאם לפרוטוקול הוא מנפיק הודעת שגיאה.