ליבה שמתוכננת למעבד מרובה-ליבות משובץ

מאת: Haim Cohen, Fresscale Semiconductor Israel

תקציר: תכנון מעבד מרובה-ליבות אינו פשוט. לא מדובר רק בשילוב של מספר ליבות על אותה פיסת סיליקון. בכדי לגרום למעבד כזה להיות “שימושי” ולספק ביעילות את הביצועים המצטברים ליישום הקצה, הארכיטקטורה של מערכת על שבב (SoC) מרובת-ליבות צריכה לקחת בחשבון מספק אתגרים מורשים שנובעים משילוב מספר ליבות, והם באים לידי ביטוי בתחומי החיבור בין הליבות, התמיכה במספר מערכות הפעלה, האבטחה, האמינות, ניפוי הבאגים וצריכת החשמל.
במסמך זה אנו מתמקדים בתכונות של רמת הליבה שנוספה בידי פריסקייל, בהשוואה לדור הקודם של ליבות בארכיטקטורת ה-Power שתוכננו בראשיתן לסביבת ליבה יחידה, בזמן המעבר למשפחות המעבדים מרובי הליבות החדשות ®QorIQ מסדרות, P4 ,P3 ו-P5.

תרשים 1: דיאגרמת בלוקים של QorIQ P4080

הקדמה
הסיבה בגינה תעשיית המיקרו-מעבדים עוברת לשימוש בריבוי-ליבות כבר כוסתה באופן נרחב במאות מאמרים טכניים ושיווקיים. העובדה היא שכיום מתכנני חומרה ותוכנה צריכים לקחת בחשבון את פריצת הדרך החשובה הזו אם הם רוצים להשיג ביצועים גבוהים יותר לכל התקן מעבד, כשכיום הגדלת תדירות השעון כבר אינה יכולה יותר לתמוך בכך.
ברמות היישום והתוכנה המעבר לריבוי-ליבות יכול להוביל לכמה שימושים מאוד שונים: חלק מהיישומים ייהנו מהביצועים המצטברים המתקבלים על ידי מיזוג כל הליבות לסביבת הפעלה אחת, בגישה המכונה “עיבוד מרובב סימטרי” (SMP). לעומת זאת יהיו יישומים אחרים שישתמשו בריבוי-הליבות כדי למזג מספר סביבות הפעלה עצמאיות, וכך להפחית עלויות ואת גודל השבב, בגישה המכונה “עיבוד מרובב אסימטרי” (AMP).
ברמה הגבוהה ניתן להתייחס לריבוי-ליבות בדומה לעיבוד מרובב, להוציא העובדה שהליבות הרבה יותר קרובות זו לזו. עובדה זו ניתנת לתרגום ליתרון ברור אם הליבות צריכות לעבוד באופן משולב ולשתף נתונים. מצד שני, אם הליבות מוקדשות לביצוע מטלות שהינן די עצמאיות, השילוב המוכלל יכול לגרום למספר בעיות פוטנציאליות ביחס להפרדת היישומים וההגנה על המשאבים. בכדי להשיג תועלת ממשית מליבות מקושרות וקרובות, וכן כדי לאזן את הבעיות הפוטנציאליות, יש להביא מספר שיפורים והרחבות מסוימות לארכיטקטורת הליבה עצמה, החל בליבה “מסורתית” שתוכננה עבור מעבד עם ליבה יחידה.
מאמר זה יציג כמה מהשיפורים הללו ומיטובים אחרים המתייחסים לפעולות ברמת הליבה, שמשולבים בליבות ה-e500mc וה-e5500 בארכיטקטורת ה-Power שהן הלב של מעבדי ריבוי הליבות הנוכחיים והבאים במשפחות QorIQ מסדרות P4 ,P3 ו-P5.
מדובר במעבדים שאומצו באופן נרחב במערכות רשת משובצות וביישומי זמן אמת בקצה הגבוה.
בחרנו שלא לכסות נושאי ותכונות ריבוי-ליבות אחרות בארכיטקטורת ה-QoreIQ מרובת הליבות כשתכונות אלו אינן מתייחסות באופן ישיר לליבות.
הארכיטקטורה הכללית של התקן מרובה-ליבות
תרשים 1 מתאר את הארכיטקטורה הכללית של פלטפורמת ה-QorIQ מרובת-הליבות, כשמעבד המערכת על שבב P4080 בעל 8 הליבות משמש כהתקן ההתייחסות.
כל ליבה פועלת במהירות של 1.5 ג’יגה-הרץ לכל היותר, ולכל ליבה יש זיכרון מטמון פרטי ברמה 1 ו-2 באפיק אחורי, בעוד שברוב המעבדים עם ליבה יחידה או שתי ליבות זיכרון המטמון ברמה L2 הוא משותף ובאפיק קדמי. במיוחד בריבוי-ליבות שיפור זה עוזר להקטין מאוד את זמן האחזור של מעבר הנתונים לליבה וכן להגביל את אינטראקציות הליבה/תוכנה עם פעילויות סימולטניות אחרות במערכת על שבב (לדוגמה, ערוצי התקשורת של ציוד היקפי). בנוסף לזיכרון ה-L1 וה-L2 הפרטיים, המערכת על שבב מספקת זיכרון L3 גדול (2 מגה-בייט) באפיק קדמי. זיכרון זה יכול לשמש כמטמון לזיכרון מערכת מסוג DDR או כ-SRAM פנימי בעל כתובת קבועה וזמן אחזור נמוך (או שילוב של השניים).
הקישורים ההדדיים בין שמונה הליבות וכל המודולים האחרים של המערכת על שבב, כולל שיתוף של זיכרון מטמון וזיכרון מערכת, יחידות ציוד היקפי ומאיצי חומרה, מבוצעים ברמה הפיזית באמצעות תבנית עקבית בשם ®CoreNet. מדובר בתבנית מיתוג ברוחב פס גבוה שמאפשרת למספר פעולות שמתרחשות בו זמנית לזרום במקביל בין מגוון גורמי ומטרות חומרה בתוך המערכת על שבב. כל ליבה מחוברת ל-CoreNet באמצעות חיבור נקודה-לנקודה עצמאי, וכך מספר ליבות יכולות להיות מוזנות בנתונים המגיעים מזיכרון המטמון המשותף או מזיכרון חיצוני. בכדי להתאים לארכיטקטורה הזו, הלוגיקה של מערכת הליבות של ה-e500mc ושל ה-e5500 תוכננה מחדש לחלוטין בכדי שניתן יהיה למפות אותה ל-CoreNet.
חלוקה בריבוי-ליבות

תרשים 2: מודל החלוקה הכללי ב-QorIQ מרובה-ליבות

כפי שכבר צוין לעיל, בתלות במטרת היישום, מעבד מרובה-ליבות יכול לארח מספר יישומים נפרדים לחלוטין או כמה יישומים שמשלימים אחד את השני במידה מסוימת. במקרה הזה, המונח “יישום” מתייחס לסביבת תוכנה שלמה שעוטפת מערכת הפעלה ואת התוכנה המעשית שפועלת מעל מערכת ההפעלה הזו. תכנון מחדש של ציוד מרובה-לוחות במטרה להפכו לציוד חדש המבוסס על לוח יחיד, מבלי לתכנן מחדש באופן מוחלט את כל מודולי התוכנה המורשים, הוא תרחיש שימוש שכיח עבור ריבוי-ליבות. מיזוג נתיבי בקרה ונתיבי נתונים בציוד רשת הוא מקרה אחר של מיזוג סביבות תוכנה נפרדות, כשבמקרה האחרון ייתכן שכמה מהליבות יופעלו במצב של “לוח נקי” (ללא מערכת הפעלה) במטרה לבצע מטלות קריטיות במיטוב גבוה במיוחד – כגון עיבוד חבילות נתונים או אלגוריתם.
הפעלת מספר מערכות הפעלה במודל ליבה מסורתי, עם מודל היררכי של משתמש/משתמש על, יכולה להתגלות כבעייתית במונחים של הגנה, שלמות וניפוי באגים. במקרה כזה תתכנה שתי גישות. באחת כל מערכות ההפעלה פועלות ב-“שיתוף פעולה” ברמת ההרשאה הגבוהה ביותר בה לכל אחת מהן יש יכולת גישה פוטנציאלית לכל משאבי המערכת. הגישה השנייה, ה-“מאובטחת” יותר, היא להפעיל את מערכת ההפעלה ברמת המשתמש עם שכבת תוכנת ניהול (Hypervisor) שפועלת ברמת ההרשאה הגבוהה ביותר ואחראית למיפוי הכללי, להגדרה ולשליטה בכל גישה למשאבי המערכת, בהתאם לצרכים של כל מערכת הפעלה.
כמו שניתן לראות כאן, כל חלוקה מורכבת ממערכת הפעלה בתוספת יישום תוכנה שמעובדים בליבה יחידה או על ידי מספר ליבות, תוך קבלת גישה לכמות מסוימת של זיכרון ומשאבי קלט/פלט פרטיים, עם תוספת של כמה משאבים גלובליים ומשאבים “שחייבים להיות משותפים” אחרים.
ברמת הליבה הורחבה היררכיית ההרשאות למודל בעל שלוש רמות של משתמש/משתמש על/ניהול (Hypervisor). במודל זה רמות המשתמש/משתמש העל עדיין שומרות על המחסום שבין קוד היישום למשאבי המערכת, אבל כעת מסופקת רמת הרשאה שלישית גבוהה יותר להרצת שכבת תוכנת הניהול שאחראית לשלמות של המערכת הכללית וכן מספקת את שירותי הווירטואליזציה הנדרשים.
במודל זה, ההתייחסות לכל מערכת הפעלה היא כאל “מערכת אורחת” שמתארחת בשכבת הניהול. כל מערכת הפעלה אורחת עדיין מוגנת בפני “איומי” מטלות יישום ועדיין יכולה לקיים גישה ישירה לחלק ממשאבי המערכת, אם שכבת ניהול מאפשרת לה זאת. זה, לדוגמה, מקרה בו ניגשים לממשק קלט/פלט שייעודי לאותה מערכת הפעלה. רק במקרה בו מערכת ההפעלה האורחת מבצעת ניסיונות לגשת לחלק ממשאבי המערכת המשותפים ו/או החיוניים, תהיה מניעה, ולכן היא תזדקק לשירות ווירטואליזציה משכבת הניהול (Hypervisor). שירות זה יופעל באופן אוטומטי על ידי הגדרת אירוע לכידה או שיופעל באופן מפורש בקוד של מערכת ההפעלה כ-“קריאה ל-Hypervisor או ביצוע Hypercall”. השימוש במלכודות או בקריאות מפורשות תלוי למעשה באסטרטגיית ההגירה הכללית של מערכות ההפעלה האורחות, שיכול להיות “ווירטואלית במלואה” או “ווירטואלית בחלקה” (או תערובת של השתיים).לכל גישה יש יתרונות וחסרונות ברורים משלה בכל מה שקשור במאמצי ההגירה ובביצועים הכלליים.
יש לציין שחלוקת המשאבים לכל מערכת הפעלה אורחת, שכך מספקים הגנה פנימית לכל מערכת הפעלה, נשלטת בעיקרון בכל יחידת ניהול זיכרון של הליבה: זיכרון פרטי של מערכת ההפעלה או טווח כתובות קלט/פלט ימופו רק ביחידות ניהול זיכרון של אותן ליבות שמרכיבות את החלוקה בה פועלת אותה מערכת הפעלה מסוימת. מצד שני, משאבים גלובליים ימופו דרך כל יחידות ניהול הזיכרון, אבל במקרה כזה, רמת ההרשאה של רשומות יחידות ניהול הזיכרון/חוצצי תרגום הכתובות (TLB) המתייחסות יכולה לגרום לכפיית הגבלת גישה לאותם משאבים גלובליים על ידי שכבת הניהול. בדרך זו הארכיטקטורה מספקת רמת בקרת הגנה דו ממדית: בתוך החלוקה ומעל החלוקה.
ארכיטקטורת הווירטואליזציה של הליבות הללו, מעבר להגבלת זכויות הגישה לזיכרון ולקלט/פלט דרך יחידת ניהול הזיכרון של כל ליבה, יכולה להגביל בנוסף גישה ישירה מצד מערכות ההפעלה האורחות לסוגים אחרים של משאבים או שירותים גלובליים – כשאפשר להזכיר גישה לתוכן של יחידת ניהול הזיכרון עצמה, גישה לשליטה ברמת המערכת וכן לאוגרי ניפוי שגיאות, ליחידת בסיס הזמן של ליבה, וכדומה.
למעשה, ברמת הליבה, החומרה מספקת מערך של מנגנונים גמישים מאוד להגדרה ושליטה בחלוקה. תכונות אלו תומכות באסטרטגיות יישום שונות מאוד שתלויות במשתנים שונים כמו: רמת ההפרדה וההגנה הצפויה, עלות התוכנה, ורמת ביצועים.
בנוסף לשיפורים ברמת הליבה, ומעט מעבר להתמקדות של מאמר זה, אפשר להזכיר כמה תכונות חומרה משלימות עבור חלוקה ששולבו במערכת על שבב מחוץ לליבה, כמו לדוגמה מנגנון שמכונה (Peripheral MMU) שמאפר לשלוט/לסנן ניסיונות גישה לזיכרון ולקלט/פלט שמבוצעים על ידי פעולות גישה ישירה לזיכרון של ציוד היקפי, וכך למעשה מגבילים את הנגישות למנהלי ההתקנים של מערכת ההפעלה האורחת.
עבור תצורות תוכנה שאינו דורשות חלוקה ושכבת ניהול (כמו במקרה של מערכת הפעלה אחת שתופסת את כל הליבות באופן מלא), אפשר לפשט את השימוש במודל החלוקה לחלוקה יחידה כברירת מחדל, ולבצע הרצה בשתי רמות הרשאה בלבד כמו במודל המסורתי.

ניהול פסיקות
השליטה בפסיקות בסביבה מרובת ליבות דורשת תשומת לב מיוחד. לכל ליבה יש לוגיקת ניהול פסיקות פנימי משלה, שצריכה לסנן ולתווך בין אירועים המתרחשים בתוך הליבה ובין אירועים חריגים המתרחשים ברמת המערכת על שבב (אלו שמגיעים מהבלוקים של הציוד ההיקפי שמחובר למערכת על שבב).
לפני שהם מגיעים לליבה, אירועים חריגים ברמת המערכת על שבב מסוננים/מתווכים באמצעות בקר פסיקות גלובלי במערכת על שבב שנקרא (Multicore Programmable Interrupt Controller – בקר פסיקות ניתן לתכנות בסביבה מרובת ליבות, בתרגום חופשי). אחד ההיבטים הראשונים שנלקחו בחשבון במעבדי ה-QorIQ מרובי הליבות הוא היכולת לנתב אירועים חיצוניים לכל אחת מהליבות, ועבור חלק מוגבל מהאירועים הללו, לכל הליבות.
אחד מהיבטי המפתח, בהתייחס לניהול הפסיקות ברמת הליבה בסביבת ארכיטקטורת החלוקה שהוסברה בחלק הקודם של המאמר, הוא: באירוע נתון, באיזו רמת תוכנה הליבה מסתעפת ומטפלת בפסיקה? במודל המשתמש/משתמש על הקלאסי, הכלל הוא שכל הפסיקות מעובדות במערכת ההפעלה, כלומר ברמת משתמש העל. במקרה של ריבוי ליבות, עם יישום של חלוקה ושכבת ניהול (Hypervisor), הגיוני, מנקודת המבט של הביצועים ושל התאמת הקוד, לתת לכמה יוצאים מן הכלל “רגילים” לעבור את העיבוד במנהלי ההתקנים של מערכת הפעלה אורחת, בניגוד למצב בו באופן שיטתי הכל מבוצע בשכבת הניהול. ה-e500mc וה-e5500 מאפשרים זאת, והם מחליטים לאיזו רמה יש לנתב יוצאי דופן “רגילים”, לרמת שכבת הניהול או לרמת משתמש העל. ויותר מכך, מדובר ביכולת ניתוב ניתנת להגדרה. עבור כל יוצאי הדופן שמוגדרים “קריטיים למערכת”, כגון שגיאות גלובליות, בדיקות מכונה וכדומה, הפסיקות מטופלות באופן שיטתי ברמת שכבת הניהול.
מבלי להיכנס לפרטים נוספים, הרבה תשומת לב ושיפורים הושקעו ב-QorIQ מרובה-הליבות בכל מה שקשור לניהול הפסיקות באופן מבוזר ברמת הליבה והמערכת על שבב. המטרה הייתה להביא גמישות ומיטוב ביצועים כנדרש בעולם המשובץ.

תקשורת בין ליבות
ביישומים הבנויים על ריבוי ליבות, התקשורת הפנימית והסנכרון בין הליבות מהווים תחום מפתח להשגת ביצועים, במיוחד שהפעילויות בליבות קשורות זו לזו באופן צמוד. האמצעים הסטנדרטיים, כמו זיכרון משותף, פסיקות רגילות או העברת הודעות ביישום תוכנה, הינם יקרים במונחים של תקורת תוכנה וזמני אחזור לצורך השגת עקביות וגרעיניות.
מסיבה זו הארכיטקטורה מרובת הליבות של ה-QorIQ כוללת מערך תכונות משופרות. ברמת הליבה, מתכנתים יכולים להשתמש במערך הוראות חדש (Doorbell Instructions כחלק מ-Power ISA 2.06) בכדי לבצע סנכרון ישיר בין הליבות. הוראות אלו מספקות אמצעי איתות מליבה-לליבה בסיסי מאוד ועם זמן אחזור נמוך.
מערך הוראות חדש אחר, המכונה Decorated Load and Store, מסופק כאמצעי שמאפשר לליבות השונות לבצע פעולות קריאה-שינוי-כתיבה מקבילות, בזמן אחזור נמוך, עם כמה משתנים גלובליים שממוקמים בזיכרון המשותף. קטגוריית הוראות זו שימושית במיוחד ביישומי רשת המנהלים אלפי תזרימים ודורשים באופן רגיל עדכונים תדירים של מונים סטטיסטיים עבור כל זרימה.
למרות שזה קצת חורג מגבולות המאמר הזה, חשוב להזכיר שני מאיצי חומרה מסוימים המשולבים במעבדי מערכת על שבב המבוססים על QorIQ מרובי-ליבות. מאיצים אלו, המכונים QMan ו-BMan, מנהלים תורים ומקצים חוצצים.
בלוק החומרה QMan מהווה תכונה חשובה עבור תקשורת בין ליבות עם זמן אחזור נמוך. הוא יכול לנהל מספר כמעט בלתי מוגבל של תורים. תור הוא למעשה רשימת מתארים עם החוצצים הקשורים אליהם שמאורגנים בשיטת FIFO (ראשון נכנס ראשון יוצא). המטרה המעשית שלהם מוגדרת באופן מלא ביישום. מבלי להיכנס לפרטי היישום, הרשו לנו להדגיש שתור שכזה, המנוהל בידי QMan, הוא מבנה תקשורתי מרובה יצרנים/מרובה צרכנים. לדוגמה, מספר ליבות יכולות להוסיף או להחסיר מאותו תור מבלי כל אמצעי זהירות מיוחד ובלי כל תקורת תוכנה. כל הסנכרון ויכולת ההפרדה מנוהלים בידי מנגנון חומרה שמונח מלמטה ומיושם בידי בלוק ה-QMan. המטרה של QMan אינה רק תקשורת בין ליבות, אלא באופן כללי יותר לאפשר יצירת קשר בין כל משאבי היצרנים והצרכנים בפלטפורמת המערכת על שבב, כולל ממשקי הרשת, מאיצי האלגוריתם, וכמובן, הליבות.

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