מאת, אריק ויינשטיין.הקלת העומס של אימות RTL
אימות התכנון הוא אחד האתגרים הגדולים ביותר עמו מתמודדים צוותי פיתוח ASIC היום. ככל שמורכבות הפיתוח ממשיכה לגדול, כך גם מנסות שיטות האימות לשמור תחת שליטה את משימת אימות הפיתוח המורכבת.
למרות כל ההתקדמות בשיטות אימות המודרניות, רובן, עדיין קצרה ידם מלטפל בגורם היסודי שהוא המשפיע ביותר על האימות : יצירת תהליך התכנון עצמו.
בעוד שהאימות ממנף עכשיו שפות אימות ברמה גבוהה המאיצות את הפרודוקטיביות, התיכנונים עצמם נעשים ב-Flows, שפות פיתוח ורמת אבסטרקציה שבמקור נכנסו לשימוש כמעט לפני 20 שנה.אנחנו עדיין כותבים קוד RTL בצורה ידנית , כדי להתאים לשפת C עבור תכנונים מורכבים אלו. תארו לעצמכם מערכות טלפון מודרניות הנשענות על מפעילי מרכזייה ידניים כדי למתג מיליוני שיחות מדי שעה.
התוצאה היא עלייה ביחס ישר של מספר השגיאות ביחד עם תכנון ה- RTL והארכת הזמן הנדרש כדי לסגור את האימות, בעוד שמה שמהנדסים זקוקים לו בצורה נואשת הוא זמן לאופטימיזציות להספק, שטח וביצועים .
במקום להאריך את התהליך המייגע של מציאת שגיאות בקוד RTL, ה-flow של פיתוח קוד RTL צריך להיות מכוון לעבר פיתוח קוד ללא שגיאות.
זה יכול להתגשם היום באמצעות ייצור אוטומטי של קוד RTL ממודלים של C++ שעברו אימות מלא. אם נעשתה כהלכה,סינתזה ברמה גבוהה (HLS) יכולה לייצר RTL התואם את מפרט הקוד ברמה הגבוהה וגם נקי משגיאות הנוצרות בד”כ בקידוד ידני.
ברור, שמשימת אימות קוד ה- RTL תהיה קלה יותר ובהכרח גם הזמן הנדרש לכך יתקצר. כך שלפתע יוקל מאד העומס העצום של אימות הפיתוח ממפתחי RTL .
שני תנאים חייבים להתקיים כדי ש- HLS באמת תקל את עומס האימות.קבצי קוד ה- high level עברו אימות מלא ויסודי וקוד ה- RTL המסונתז חייב להיות Correct-by-Construction. אימות ברמה של שפת C הוא פשוט ומהיר יותר בגלל היותו יותר אבסטרקטי מ- RTL. יש פחות דברים לאמת, פחות שורות קוד לנפות, יכולות וביצועי סימולציה טובים יותר ויותר קל לתקן שגיאות. קוד RTL שהוא Corrected-by-Construction לא מצריך ניפוי שגיאות ובכך מבטל את הצורך במשימה מורכבת שצורכת 30% עד 40% מזמן אימות ה-RTL . אולם תנאים אלו יכולים להתממש אם נמנעים ממלכודות ביצירת קוד ה- RTL ואימות ברמת שפת C נעשה בצורה היעילה ביותר.
המכשולים ביצירת קוד RTL
יש שתי מכשלות נפוצות שמונעות מרוב כלי ומתודולוגיות ה- HLS את יכולת השגת קוד RTL שהוא Correct-By-Construction: קוד מקור תלוי-תזמון וסינתזה של קיצורים (shortcuts) שמסלפים את דרישות המפרט.
תלות בתזמון היא תכונה בסיסית בתכנון שטבועה בצורה טבעית בשפה הגבוהה עצמה. אם התנהגות התכנון תלויה באספקטים מסוימים של תזמון, קוד המקור הוא תלוי תזמון (רגיש להשהיות), וקוד ה- RTL המסונתז עלול שלא להיות תואם למפרט המקורי.
חוסר ההתאמה מופיע בגלל שאחת התפקידים הבסיסיים של HLS הוא להוסיף זמן לתכנון. ה- HLS מתחיל מתיאור שלא כולל זמן , ומייצר RTL שמכיל גם שעון. כיוון שכלי ה- HLS יוסיף וגם ישנה את הזמן בתכנון, התנהגות מודל ה- high level לא צריכה להיות תלויה בתזמון אם הנכונות צריכה להישמר. תיאור ה high-level צריך להיות בלתי תלוי בתזמון.
לצערנו, הרבה כלי HLS לא יכולים להבטיח חוסר תלות בתזמון. למשל, מעצם התכנון, SystemC מספק מודל של זמן ומודל של מקביליות. בעוד זה אפשרי ליצור תכנון שלא תלוי בתזמון ב- SystemC, זה גם קל לפתח מודלים שהם תלויי תזמון מבלי להבין את הנכונות של התכנון המבוסס על תסריט תזמון נתון. כתוצאה מכך, כאשר הדור הנוכחי של כלי HLS- SystemC משנים או מוסיפים זמן לתיאור ה- high level ,לא בטוח שה-RTL הנוצר יהיה תואם. למרות שעבר אימות לפני הסינתזה,אימות מסיבי נוסף יידרש ל- RTL .
אפילו כאשר שפת המקור אוכפת אי תלות בתזמון, כמה כלי HLS מפירים כמה מכללי השפה עצמה. כלים אלו מתעלמים מהתלות הסדרתית שמוגדרת ע”י קוד המקור ובעצם פוגעות בתזמון או בסנכרון של התכנון או חלקים ממנו. בגלל שכלים אלו מתעלמים מההתנהגות האמיתית של קוד ה- C, תכן ה-RTL יכול להתנהג לא כמו הקוד מקור, מחייב לאימות נוסף רב של ה- RTL. קיצורים אלה נלקחים או על מנת להשיג יעדי תכנון או בגלל אי התאמות או חולשות של הכלי – אך בכל מקרה הם לא מוצדקים , במיוחד עקב השפעתם הגדולה על אימות ה – RTL.
חשוב מאד להבטיח שלא שפת ה- high level ולא כלי ה- HLS יפגעו בייצור קוד RTL שהוא Correct-by-Construction. כאשר בונים מודל, מאמתים ומסנתזים מקוד C++, המקור הוא ללא זמן ולכן אי תלות בתזמון נכפית או אינהרנטית. כאשר כלי HLS מאפשר תלות סדרתית בין משתנים ופעולות, הנכונות של התכנון נשמרת. רק כאשר שני תנאים אלו נשמרים ה- RTL יהיה Correct-by-Construction ויהיה תואם למפרט ה- high-level ולכן מונע את הצורך באימות חוזר.
ייעול האימות ברמת ה-C
האילוץ לעשות אימות לאחר ה- HLS וב-timed netlist מעט בצורה משמעותית את זמן הפיתוח ומסבך את אימות ה- RTL. קוד RTL שהוא Corrected-by-Construction פותר בעיה זו. עדיין , כדי לשלב או להכניס את הזמן לקוד RTL מאומת,חשוב להבטיח שקוד ה- high level עבר אימות מקיף במאמץ מינימאלי האפשרי. פחות פרטים בקוד המקור, סימולציה ברמת C ובדיקות Coverage של התכנון לא רק שמייצרות תכנון ברמה גבוהה לסינתזה, אלא גם מייצרות מודלים ב-C שישמשו כבסיס למודלים נוספים ויאשרו שימוש חוזר ב- RTL .
הוספת פרטים בקוד יותר מן הדרוש פועלת כנגד מטרה זו. לדוגמא, למרות שסינתזה עושה אוטומטית את התהליך של הכנסת מקביליות ביישומי חומרה, שפה כמו SystemC שבמפורש מגדירה מקביליות בקוד ברמה הגבוהה, דורשת שינוי לקוד המקור בכל פעם שפרטים אלו בארכיטקטורה משתנים בזמן המימוש .מאמץ אימות ה- high level במקרה זה לא יכול להיות Reuse והקוד צריך אימות מחדש.
מצד שני, כמו עם C++, אם קוד המקור הוא בהחלט ללא זמן והשפה שבה משתמשים לא מאפשרת מקביליות, כלי הסינתזה יכול לבנות תסריטי תכנון שונים, עם יישום סכמות מקביליות שונות מאותו קוד מקור מבלי לשנות אותו. דבר זה מהווה יתרון גדול בחוסר הצורך לעשות אימות חוזר בכל שינוי. בצורה זו, המידע לגבי המקביליות צריך להיות מפוקח בשלב הסינתזה , כמו שה- HLS מתוכנן לעשות. התוצאה היא יצירת בעיקר של high kevel IP, שהוא רב תכליתי ויכול לשמש לתכנונים רבים משום שבתכנון מקודדים פרטים מעטים .
כללית, בגלל הכללת פחות פרטי התכנון, HLS מקטין את זמן האימות הכללי. יש שיפור של ביצועי סימולציה כי המודלים של C++ המבוצעים ישירות על תחנת העבודה והם לא דורשים סימולאטור שהוא event base. סימולציה מהירה מאפשרת לבחון יותר ווקטורים לבדיקות coverage . זה נותן יתרון למתכנן ה- RTL בגלל שה-RTL המסונתז מאומת ביותר יסודיות ויותר תסריטים נבחנו. כך שאתה לא רק מקבל RTL שהוא Corrected-by-Construction ע”י כלים אוטומטיים ואומת בצורה יסודית, אלא גם מהווה תכנון יותר טוב.
כדי להשלים את התכנון, הכרחי לבדוק ולאשר ברמת הביטים בקוד מקור. בתכנון חומרה , כל ביט נחשב כדי להשיג תכנון אופטימאלי במונחי הספק, שטח וביצועי זמן . זוהי הסיבה לכך שמשתנים בגודל שרירותי כל כך חשובים ב- HDL. למרות זאת,סוגי המשתנים של שפת C לא מספקים רמה כזאת של גמישות ודיוק.
בעוד זה מתקבל על הדעת לבנות מודל מבוסס 32Bit Integers ולאלץ גודל מסוים בביטים ב- RTL דרך תהליך ה -HLS , לגישה זו חסרון משמעותי בגלל חוסר האפשרות לבדוק ולאמת התנהגות ברמה ספציפית של ביטים במודל ה- high level . בכך נגחה ניפוי שגיאות ואימות של אספקט קריטי זה בתכנון עד לשלב מאוחר ב- RTL Netlist. לצורך זה, ולמניעת איטרציות מיותרות, דיוק ברמת הביטים צריך להיתמך ברמת קוד המקור. בעוד זה קשה להשגה בשפת C רגילה, שפת ה- C++ מספקת תמיכה ב- Classes, שמאד נוחים למטרה זו. משום כך הוגדרו משתנים מסוג Integer ( sc_int ) ונקודה קבועה (sc_fixed) בשפת- SystemC . סוגי משתנים נוספים הנגישים נמצאים בספריית Algorithmic C (ac_datatypes: ac_int and ac_fixed ). יש יתרון ברור לשימוש ב ac_datatypes, שמשלב הגדרתם ותכנונם, גם הסינתזה וגם האימות נלקחו בחשבון .הם עקביים מבחינה סמנטית בכל הדיוקים כמו גם בסימולציות C וביישומי חומרה. יש להם היתרון שהם מהירים עד פי 200 ממשתני S
ystemC ובעלי זמן קומפילציה מהיר יותר גם כן. בשנים האחרונות, כלי – HLS מתקדמים הורחבו לתמוך באריתמטיקה מרוכבת גם כן.
מודלים נבחרים בשפת C ובדיקות נרחבות ב- high level הנותנים תשתית אימות ל- RTL בחינם, מספקים לא רק סינתזה אלא גם אימות “בלחיצת כפתור” ל- RTL. לדוגמא, מערכת אימות אוטומטית, שנקראת SC_Verify, המאופשרת ע”י כלי סינתזה ל- Catapult C של מנטור גרפיקס , מייצרת לא רק את מודל ה- RTL אלא גם SystemC Transactor ומעטפת SystemC לסנכרן את התנהגות ה- RTL יחסית לאלגוריתם המקורי ב-ANSI C++. זהו יתרון גדול בגלל שהתכן ב- RTL יכול להיות מאומת ביחס למקור ב C++ ולעשות שימוש חוזר ב- testbench המקורי של ה C++ בכל סימולאטור פונקציונאלי סטנדארטי התומך בכמה שפות. כל האימות שנשאר לעשות ב- RTL הוא קל יותר, מהיר ויותר יעיל.
הזמן ל- RTL הוא לא כה חשוב כמו הזמן ל- RTL שעבר אימות.ל- HLS מבוסס C++ יש את הפוטנציאל להקטין באופן דרמטי את מאמץ האימות הכולל ל- RTL בגלל שהוא מאפשר לקבוצות הפיתוח להגיע מהר יותר לסיום האימות על הקוד C ואז לסנתז RTL שהוא Corrected-by-Construction. כדי לממש פוטנציאל זה, מהנדסי RTL חייבים לבחור כלי HLS שנבנה תוך כדי מודעות לאימות RTL. כלי כזה מזיז את מירב האימות לקוד C++ ANSI טהור, שם הוא צריך להיות, וממנף את תוצאות האימות של- C בשלב ה- RTL. ע”י שלילת הצורך בשלב הניפוי וע”י קיצור הזמן ל- RTL מאומת, פיתרון ה- HLS האופטימאלי מקל את העומס על מהנדסי אימות ה- RTL, כך שהם יכולים להתקדם בתכנונים מהירים ולהשיג זמני הגעה קצרים לשוק.
