חשיבה מחדש על זיכרון

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

[LR]: פרנק פרו, קיידנס; סטיבן וו, רמבוס; ג'ונגסין יון, סימנס EDA; רנדי ווייט, Keysight; ופרנק שירמייסטר, ארטריס

SE: בזמן שאנו נאבקים עם AI/ML ודרישות כוח, אילו תצורות צריך לחשוב מחדש? האם נראה שינוי הרחק מארכיטקטורת פון נוימן?

לְחַזֵר אַחֲרֵי: במונחים של ארכיטקטורות מערכת, יש התפצלות בתעשייה. היישומים המסורתיים שהם סוסי העבודה הדומיננטיים, שאנו מריצים בענן על שרתים מבוססי x86, לא נעלמים. יש עשרות שנים של תוכנות שנבנו והתפתחו, ואשר יסתמכו על הארכיטקטורה הזו כדי לבצע ביצועים טובים. לעומת זאת, AI/ML הוא מחלקה חדשה. אנשים חשבו מחדש על הארכיטקטורות ובנו מעבדים מאוד ספציפיים לתחום. אנו רואים שכשני שליש מהאנרגיה מושקעת רק בהעברת הנתונים בין מעבד למכשיר HBM, בעוד שרק כשליש מושקע בגישה למעשה לביטים בליבות ה-DRAM. תנועת הנתונים כעת הרבה יותר מאתגרת ויקרה. אנחנו לא הולכים להיפטר מהזיכרון. אנחנו צריכים את זה כי מערכי הנתונים הולכים וגדלים. אז השאלה היא 'מהי הדרך הנכונה קדימה?' היו הרבה דיונים על ערימה. אם היינו לוקחים את הזיכרון הזה ומניחים אותו ישירות על גבי המעבד, הוא עושה שני דברים עבורך. ראשית, רוחב הפס כיום מוגבל על ידי חזית החוף או היקף השבב. לשם הולכים ה-I/Os. אבל אם הייתם עורמים אותו ישירות על גבי המעבד, כעת תוכלו לעשות שימוש בכל שטח השבב לחיבורים מבוזרים, ותוכלו לקבל יותר מרוחב הפס בזיכרון עצמו, והוא יכול להזין ישירות לתוך המעבד. הקישורים מתקצרים בהרבה, ויעילות החשמל כנראה עולה בסדר גודל של פי 5 עד פי 6. שנית, כמות רוחב הפס שאתה יכול לקבל בגלל החיבור הזה של מערך שטח גדול יותר לזיכרון עולה, גם כן, בגורם של מספר שלמים. ביצוע שני הדברים הללו יחד יכול לספק יותר רוחב פס ולהפוך אותו לחסכוני יותר בצריכת החשמל. התעשייה מתפתחת לצרכים אשר יהיו, וזו בהחלט אחת הדרכים שבהן נראה מערכות זיכרון מתחילות להתפתח בעתיד כדי להפוך לחסכוניות יותר בצריכת החשמל ולספק יותר רוחב פס.

בַּרזֶל: כשהתחלתי לעבוד על HBM בסביבות 2016, כמה מהלקוחות היותר מתקדמים שאלו אם ניתן לערום את זה. הם בחנו איך לערום את ה-DRAM למעלה כבר די הרבה זמן כי יש יתרונות ברורים. מהשכבה הפיזית, ה-PHY הופך לזניח בעצם, מה שחוסך הרבה כוח ויעילות. אבל עכשיו יש לך מעבד של כמה 100W שיש עליו זיכרון. הזיכרון לא יכול לסבול את החום. זו כנראה החוליה החלשה בשרשרת החום, מה שיוצר אתגר נוסף. יש יתרונות, אבל הם עדיין צריכים להבין איך להתמודד עם התרמיקה. יש יותר תמריץ כעת להעביר את סוג הארכיטקטורה הזה קדימה, כי זה באמת חוסך לך באופן כללי מבחינת ביצועים וכוח, וזה ישפר את יעילות המחשוב שלך. אבל יש כמה אתגרי עיצוב פיזיים שצריך להתמודד איתם. כמו שסטיב אמר, אנחנו רואים כל מיני ארכיטקטורות שיוצאות. אני מסכים לחלוטין שארכיטקטורות ה-GPU/CPU לא הולכות לשום מקום, הן עדיין יהיו דומיננטיות. במקביל, כל חברה על פני כדור הארץ מנסה להמציא מלכודת עכברים טובה יותר לביצוע הבינה המלאכותית שלה. אנו רואים SRAM על-שבב ושילובים של זיכרון ברוחב פס גבוה. LPDDR הרים לא מעט את הראש בימים אלה מבחינת איך לנצל את ה-LPDDR במרכז הנתונים בגלל הכוח. אפילו ראינו GDDR בשימוש בכמה יישומי הסקת AI, כמו גם בכל מערכות הזיכרון הישנות. כעת הם מנסים לסחוט כמה שיותר DDR5 על טביעת הרגל. ראיתי כל ארכיטקטורה שאתה יכול לחשוב עליה, בין אם זה DDR, HBM, GDDR או אחרות. זה תלוי בליבת המעבד שלך מבחינת הערך המוסף הכולל שלך, ואז איך אתה יכול לפרוץ את הארכיטקטורה הספציפית שלך. מערכת הזיכרון שמתלווה אליו, כך שתוכל לפסל את המעבד שלך ואת ארכיטקטורת הזיכרון שלך, בהתאם למה שזמין.

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

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

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

SE: כיצד התפתחו כלי עיצוב זיכרון?

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

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

לְחַזֵר אַחֲרֵי: חלק מהסיבה שאתה רואה את עלייתם של כלי הדמיית מערכת מלאים היא ש-DRAM הפכו הרבה יותר מסובכים. זה מאוד קשה עכשיו להיות אפילו בסרגל עבור חלק מעומסי העבודה המורכבים הללו באמצעות כלים פשוטים כמו Excel. אם אתה מסתכל על גיליון הנתונים של DRAM בשנות ה-90, גיליונות הנתונים האלה היו כמו 40 עמודים. עכשיו הם מאות עמודים. זה רק מדבר על המורכבות של המכשיר כדי להוציא את רוחבי הפס הגבוהים החוצה. אתה מצמיד את זה לעובדה שהזיכרון הוא דרייבר כזה בעלות המערכת, כמו גם ברוחב הפס והשהייה הקשורים לביצועי המעבד. זה גם נהג גדול בכוח, כך שאתה צריך לדמות ברמה הרבה יותר מפורטת עכשיו. במונחים של זרימת כלים, אדריכלי מערכת מבינים שזיכרון הוא מניע ענק. אז הכלים צריכים להיות מתוחכמים יותר, והם צריכים להתממשק לכלים אחרים בצורה טובה מאוד כדי שאדריכל המערכת יקבל את התצוגה הגלובלית הטובה ביותר של המתרחש - במיוחד עם האופן שבו הזיכרון משפיע על המערכת.

יון: כשאנחנו עוברים לעידן הבינה המלאכותית, נעשה שימוש בהרבה מערכות מרובות ליבות, אבל אנחנו לא יודעים אילו נתונים הולכים לאן. זה גם הולך יותר במקביל לשבב. גודל הזיכרון הרבה יותר גדול. אם אנו משתמשים ב-AI מסוג ChatGPT, אז הטיפול בנתונים עבור הדגמים דורש כ-350MB של נתונים, שהם כמות עצומה של נתונים רק עבור משקל, והקלט/פלט בפועל הרבה יותר גדול. הגידול הזה בכמות הנתונים הנדרשת פירושה שיש הרבה השפעות הסתברותיות שלא ראינו בעבר. זה מבחן מאוד מאתגר לראות את כל השגיאות הקשורות לכמות גדולה זו של זיכרון. ו-ECC משמש בכל מקום, אפילו ב-SRAM, שבאופן מסורתי לא השתמש ב-ECC, אבל עכשיו זה נפוץ מאוד עבור המערכות הגדולות ביותר. הבדיקה של כל זה היא מאוד מאתגרת וצריכה להיתמך בפתרונות EDA כדי לבדוק את כל התנאים השונים האלה.

SE: אילו אתגרים מתמודדים צוותי הנדסה ביום יום?

לבן: בכל יום נתון, תמצא אותי במעבדה. אני מפשיל שרוולים וליכלכתי את הידיים, חוטטים חוטים, הלחמה, ומה לא. אני חושב הרבה על אימות שלאחר סיליקון. דיברנו על סימולציה מוקדמת וכלי על-die - BiST ודברים כאלה. בסופו של יום, לפני שאנו שולחים, אנו רוצים לבצע צורה כלשהי של אימות מערכת או בדיקות ברמת המכשיר. דיברנו על איך להתגבר על חומת הזיכרון. אנחנו מאתרים יחד זיכרון, HBM, דברים כאלה. אם נסתכל על האבולוציה של טכנולוגיית האריזה, התחלנו עם אריזות עופרת. הם לא היו טובים במיוחד עבור שלמות האותות. עשרות שנים מאוחר יותר, עברנו לשלמות אותות אופטימלית, כמו מערכי רשת כדוריים (BGAs). לא יכולנו לגשת לזה, מה שאומר שלא יכולת לבדוק את זה. אז המצאנו את הקונספט הזה שנקרא מתקן בין התקן - מחליף BGA - וזה איפשר לנו לסנדביץ' מתקן מיוחד שניתב אותות החוצה. אז נוכל לחבר אותו לציוד הבדיקה. מהר קדימה להיום, ועכשיו יש לנו HBM ו-chiplets. כיצד אוכל לסנדב את המתקן שלי בין לבין על מתקן הסיליקון? אנחנו לא יכולים, וזה המאבק. זה אתגר שמחזיק אותי ער בלילה. כיצד אנו מבצעים ניתוח כשלים בשטח עם לקוח OEM או מערכת, כאשר הם לא מקבלים את היעילות של 90%. יש עוד שגיאות בקישור, הם לא יכולים לאתחל כראוי, וההדרכה לא עובדת. האם זו בעיה של תקינות המערכת?

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

בַּרזֶל: במיוחד עם זיכרון ברוחב פס גבוה, אתה לא יכול להיכנס לשם פיזית. כשאנחנו מעניקים רישיון ל-PHY יש לנו גם מוצר שמתאים לזה, כך שתוכל לשים עין על כל אחד מ-1,024 הביטים האלה. אתה יכול להתחיל לקרוא ולכתוב DRAM מהכלי כך שלא תצטרך להיכנס לשם פיזית. אני אוהב את הרעיון של המתערב. אנחנו מוציאים כמה סיכות מהמשבץ במהלך הבדיקה, מה שלא ניתן לעשות במערכת. זה באמת אתגר להיכנס למערכות התלת מימד האלה. אפילו מנקודת מבט של זרימת כלי עיצוב, נראה שרוב החברות עושות זרימה אישית משלהן על הרבה מכלי 3D אלה. אנחנו מתחילים להרכיב דרך סטנדרטית יותר לבנות מערכת 2.5D, משלמות האות, הספק, כל הזרימה כולה.

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

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

מאמרים נוספים
עתיד הזיכרון (Part 1 of above roundable)
מניסיונות לפתור בעיות תרמיות וחשמל ועד לתפקידים של CXL ו-UCIe, העתיד טומן בחובו מספר הזדמנויות לזיכרון.

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://semiengineering.com/rethinking-memory/