תכנוני ESL - רמת ההתנהגות
מאת גרי סמית שלישי, 26 אפריל 2011 00:18

בימים אלה כשאנו רואים  את התנועה המאסיבית של התעשייה לכיוון מתודולגיית תכנון ה-  ( Electronic System  ESL  Level)  אנו נזכרים איך הכל החל.  המאמצים הראשונים ( Early Adopters)  סללו את הדרך לשאר השוק ולמרות שכיום אין כבר סימני שאלה לגבי רמת הכישורים המתקדמת של הדור הבא של מתכנני  SOC עדיין קיים בלבול בקהיליית התכנון בנוגע למי עושה מה? מכתב זה יתמקד במתודולוגיה ובכמה כללי "עשה" ו"אל תעשה" של המתודולוגיה.

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

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

בשנת 1997, עשינו מחקר ומצאנו כ-400 אדריכלים (Architects). צפינו שיהיו 1,970 עד שנת 2000. זה כמובן אומר שמדובר בשוק קטן מאד. מה שלא הבנו אז היה שהארכיטקטים לא מייצגים כלל את שוק ה ESL.

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

מה שעושות חברות כמו יבמ הוא הקמת צוות של מתכנני ESL  קרוב ככל האפשר למהנדסי המערכת ואפילו דואגים לקירבה פיזית בינהם. התפקיד שלהם הוא לעשות את הדיגום (modeling) של המערכת המוצעת ואז לבצע ניתוח מעמיק של "מה אם" כדי להגיע לתכנון האופטימלי. כיום חלוקת מערכת (System Partitioning ) נעשית ע"י צוות רב תחומי תחת ניהולו של האדריכל. זו הסיבה מדוע ג'ון זקוק בצורה נואשת למערכת התנהגותית מסוג SystemC. באחד מנאומיו הוא הצהיר שלא מזמן ליבמ היו 44 מודלים של זכרון מטמון cache)), אך אף אחד מהם לא היה תואם את האחר ואף לא תואם את המערכת התנהגותית ממודל    C.

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

זו בד"כ הטעות הראשונה שמתכננים עושים כאשר נכנסים לעולם תכנון ה-ESL. זה קל לטעות מכיוון שהרבה מתכנני ESL  משתמשים ב-  C/C++  . שפת התכנות האחרת השלטת היא  MathWorks’ “M” אשר הינה שפה תבניתית. זה בדיוק מה שמתכנני ה -ESL עושים עם ה- C/C++ ומשתמשים בזה לבנות מודלים.

מה שאתם רואים הוא שמתכנני ה-  ESL משתמשים בשולחן העבודה האדריכלי  (Architect’s (Workbench לעצב את המערכת. בדרך זו הם יכולים לעשות את אנליזת ה-"מה אם" הדרושה להוכיח ולמצות בצורה הטובה ביותר את תכנון המערכת. שולחן העבודה  האדריכלי הוא הראשון מתוך שלושה אבי טיפוס וירטואלים הדרושים לתחום ה-ESL (ראה שרטוט 1)

שרטוט 1 –שלושת אבי הטיפוס הוירטואלים

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