מסינכרוני לאסינכרוני: אתגרים בתכנון ואימות

חיים כהן, Freescale Semiconductor, Inc.‎

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

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

הקדמה

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

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

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

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

ברמה הרחבה יותר, ניתן לחלק את קישורי התכנון ל’סינכרון נתונים’ או ‘סינכרון לוגיקת בקרה’. ברוב קטגוריות התכנון, נלקח בחשבון בלוק תכנון סינכרוני, ומנומקות הצעות למקבילים אסינכרוניים.

סינכרון נתונים

תורי נתונים

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

הנה FIFO אסינכרוני לדוגמה: הגישה הכללית לתכנון FIFO אסינכרוני מוצגת בתמונה 1.

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

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

דגימה של כניסת נתונים אסינכרוניים

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

צורך זה יוצר בעיה ייחודית בתכנון. הזמן הדרוש לסינכרון כזה תלוי ביחס שבין השעונים שבהם הנתונים מסונכרנים. יש לוודא כי קצב השינוי של נתונים אלה אינו חורג מהזמן הדרוש לסינכרון שלהם; אחרת, יתרחש אובדן נתונים בגבול השעון. לכן, יחס השעונים קובע, או “מגביל”, את קצב השינוי של נתוני הכניסה שיש לסנכרן.

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

TDin > Tsync

 כאשר TDin הוא זמן המינימום הזמין לפני החלפה של מסגרות קיימות של נתוני כניסה במסגרת המגיעה לאחר מכן, ו-Tsyncהוא הזמן הדרוש לסינכרון המסגרת שהתקבלה.

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

סינכרון לוגיקת בקרה

יחסי שעונים

בעת הוספה של כמה שעונים לתכנון, עולה בעיה ייחודית שמעולם לא הופיעה בתכנונים סינכרוניים – העברה של אותות משעון מהיר יותר לשעון מהיר פחות.

בתרחישים כאלה, האות בשעון המקור (המהיר יותר) עשוי להיות קטן מדי, וייתכן ששעון היעד (האיטי יותר) יחמיץ אותו לחלוטין. תמונות 3 ו-4 ממחישות בעיה זו.

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

במקרה שבו לא ניתן להחזיק אות מקור, ניתן לשקול גישה אחרת, שבה נעשה שימוש בקצה (edge) העולה (או היורד) של אות הבקרה בתור כניסת שעון בכניסה אל D Flip-Flop אשר D הכניסה שלו קשורה ל-1. היציאה של אותו FLOP מסונכרנת בכניסה לשעון היעד (האיטי יותר), וכך האות עובר בהצלחה מהשעון המהיר יותר אל האיטי יותר, כמתואר בתמונה 5.

איפוסים אסינכרוניים

במקרה של שעונים מרובים, FLOPS פועלים עם איפוסים אסינכרוניים. אחת הבעיות העיקריות באיפוסים אסינכרוניים היא שחרור האיפוס (release), המכונה גם הסרת איפוס (removal).

האיפוסים הם אסינכרוניים, הן ב-Assertion והן ב-De-assertion של איפוסים. ה-Assertion לא מהווה בעיה, אך ה-De-assertion כן. במקרה של שחרור האיפוס האסינכרוני בקצה של השעון הפעיל של Flip-Flop או בסביבתו, תיתכן מטה-יציבות ביציאת ה-Flip-Flop, וכתוצאה מכך ייתכן אובדן של מצב האיפוס של בלוק התכנון.

לכן, כל תכנון המשתמש באיפוס אסינכרוני אמור לכלול מעגל לסינכרון איפוסים. מעגל כזה יבטיח כי למרות הביצוע האסינכרוני של Assertion איפוס, De-assertion של איפוס יהיה תמיד סינכרוני ביחס לשעונים האסינכרוניים השונים.

אוגרי קריאה/כתיבה

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

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

פוסט-תכנון

במהלך ההעברה של תכנון ממבנה סינכרוני לאסינכרוני, ישנם כמה ענייני אימות שיש לקחת בחשבון על מנת להבטיח תכנון איכותי, המאפשר שילוב חלק עם SOC.

סביבת האימות

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

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

• דרייבר: דרייבר עשוי להיות דרייבר פשוט של פרוטוקול, שכולל יכולת מובנית לשינוי היציאה בהתאם לזמן הבאוד ולמקור השעון כמו ב-DUT. ייתכן כי לדרייבר יידרשו פרטי השעון המתאימים ולוגיקה מסוימת כדי לטפל בשעונים אסינכרוניים. אם הארכיטקטורה של ה-Testbench לא כוללת הפרדה מתאימה של דרייברים עבור כל ממשק שעון, יש לבנות מחדש את הארכיטקטורה של הדרייבר. לדוגמה, בתמונה Fig 8, ה-Testbench כולל דרייבר עבור כל ממשק, ולכן כל שינוי של השעונים הוא בעצם שינוי של השעון לפי הממשקים בלבד, אך אם יש לנו Testbench כמו זה שמוצג בתמונה 7, עלינו להפריד בבירור בין הממשקים.
• מוניטור: המוניטור משתמש בשעונים שונים ליצירת תגובה המשמשת את בודק התגובות. יש לוודא הפרדה מתאימה של התגובה שהמוניטור יוצר לפי שעונים, בהתאם לשינויים שנעשו בשעון ב-DUT, כדי להבטיח בדיקה נכונה. כמו עם הדרייבר, יש לחבר כל מוניטור בממשק אחר, ועלינו רק לשנות את השעון כדי כדי להפוך את ה-Testbench לאסינכרוני.
• בודק התגובות/ניקוד: בודק התגובות עוזר לבדוק את תקינות הנתונים. ברמה הבסיסית, הוא יוצר את הנתונים הצפויים בהתאם לשעוני הכניסה, ובודק את הנתונים בשעוני היציאה. לכן, חשוב לשמור על גבול ברור בין השעונים בתוך הבודק, כדי להבטיח בדיקת תגובות נכונה. ב-Testbench בתמונה 8, פעולה זו מטופלת באופן אוטומטי אם אנו משתמשים בבלוקי התזמון של הממשק המסוים לצורך עדכון הבדיקה עבור אותו ממשק.

ייתכן שצריך יהיה לעדכן את הרכיבים הבאים בסביבת האימות:

• Testcase: יש לשנות או להוסיף Testcase על מנת לבדוק את התפקוד במגוון יחסי שעונים וערכי הפרדת שעונים (dividers). יחסי שעונים וערכי הפרדה אקראיים יאפשרו בדיקה טובה של התכנון האסינכרוני. בשימוש במערכת המבוססת על System Verilog, ניתן לעשות זאת על-ידי הזנת יחסי השעונים והטיות השעונים כפרמטרים שניתן ליצור באופן אקראי. הבדיקות של אוגר קריאה-כתיבה הן חשובות משום שייתכנו קריאה או כתיבה של נתונים בשעונים שונים ואסינכרוניים זה לזה, ולכן צריך יהיה לבדוק את לוגיקת ההמתנה המתאימה בתכנון. לדרייבר האוגר של קריאה/כתיבה אמורה להיות היכולת לבדוק זאת.
• Cover Points: יש להוסיף כיסוי בדיקות לגבי יחסי שעונים והטיות שעונים עבור כל הבלוקים הפונקציונליים הקיימים. לדוגמה

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

סיכום:

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