מאת: מייקל פרקר, Altera Corporation
בשעה שיחידות עיבוד גרפיות רב תכליתיות (GP-GPUs) מאפשרות שיעורים גבוהים של חישובי נקודה צפה בשנייה (FLOPs), רכיבי FPGA מציגים ביצועים המתחרים בהן בכל הנוגע לעיבוד נקודה צפה. נוסף על כך, מתודולוגית פיתוח לרכיבי FPGA מתוצרת ®Altera תומכת כיום ב-™OpenCL, סביבת עבודה לפיתוח תוכנה עבור מערכות הטרוגניות, שפת תכנות שנתמכה עד היום ע”י יצרני CPU ו-GPU.
מבוא
FPGA ו-CPU מהווים זה זמן רב חלק אינטגראלי מעיבוד אותות מכ”ם. FPGAs משמשים באופן מסורתי לעיבוד קצה קדמי, בשעה ש-CPUs משמשים לעיבוד קצה אחורי. דרישות העיבוד עלו באופן דרמטי לאור העובדה שיכולות הביצוע והמורכבות של מערכות המכ”ם הלכו וגברו. בעוד ש-FPGA שמר על הקצב בכל בנוגע להגברת יכולות העיבוד והתפוקה, התקשה CPU לספק את יכולת הביצוע הנדרשת בעיבוד האותות של מכ”ם הדור הבא. קושי זה הוביל להגדלת השימוש במאיצי CPU, כדוגמת יחידות עיבוד גרפיות (GPUs) על מנת לספק תמיכה לעומסי העיבוד הכבדים.
נייר עמדה זה משווה בין FPGA ל-GPUבכל הנוגע לביצועי נקודה צפה ועיצוב התוכניות. במהלך השנים האחרונות, GPU התקדם אל מעבר לגרפיקה והפך לפלטפורמת עיבוד נקודה צפה חזקה, המכונה GP-GPUs והמאפשרת שיעורים גבוהים של חישובי FLOPs. רכיבי ה-FPGA, שבהם השתמשו באופן מסורתי לעיבוד אותות דיגיטלי (DSP) עבור נקודה קבועה, מציגים כיום ביצועים מתחרים בכל הנוגע לעיבוד נקודה צפה, ועובדה זו הופכת אותם למועמדים בכל הנוגע להאצת עיבוד קצה אחורי של מכ”ם.
בחזית ה-FPGA, פורסמו מספר בוחני ביצועים השוואתיים של נקודה צפה הניתנים לאימות ב-40 וב-28 ננומטר. FPGAs ברמת ביצוע גבוהה המהווים את הדור הבא של Altera יתמכו בביצוע של לפחות
5TFLOP באמצעות מינוף תהליך Tri-Gate של אינטל לייצור 14 ננומטר. ניתן לצפות לעד 100GFLOPs/W בעקבות השימוש בתהליך מתקדם זה במוליך למחצה. נוסף על כך, FPGAs מתוצרת Altera תומכים כיום ב-OpenCL, שפת תכנות מובילה שבה משתמשים ב-GPUs.
דירוגי שיא של GFLOPs
ל-FPGAs הקיימים יש יכולות של
1+peak TFLOPs, בעוד שה-AMD
וה-GPUs העדכניים של Nvidia מדורגים אף גבוה מכך, עד כמעט 4TFLOPs. ואולם, דירוג השיא של GFLOPs או TFLOPs מספק מידע מועט בנוגע ליכולת של רכיב נתון ביישום מסוים. הוא מציין רק את המספר הכולל של תוספות נקודה צפה תיאורטית או מכפילים שניתנים לביצוע בשנייה. ניתוח זה מצביע על כך
ש-FPGAs מסוגלים, במקרים רבים, לעלות על התפוקה של GPUs באלגוריתמים וגדלי נתונים השכיחים ביישומי מכ”ם.
אלגוריתם שכיח במורכבות בינונית הוא התמרת פורייה מהירה (FFT). מאחר שרוב מערכות המכ”ם מבצעות את רוב העיבוד שלהן בתחום התדר, נוהגים להשתמש באלגוריתם FFT בשכיחות גבוהה. למשל, FFT בנקודה 4,096 יושמה תוך שימוש בעיבוד נקודה צפה בדיוק רגיל. האלגוריתם מסוגל לקלוט ולפלוט ארבעה מדגמים בכל מחזור שעון. כל ליבת FFT יחידה יכולה לפעול ב-80GFLOPs,
ול-28 ננומטר יש משאבים ליישם שבע ליבות כאלה.
ואולם, כפי שמציין תרשים 1, אלגוריתם FFT על FPGA זה הוא כמעט
400GFLOPs. תוצאה זו מבוססת על קומפילציית OpenCL פשוטה, ללא צורך במומחיות ב-FPGA. השימוש באופטימיזציות של logic-lock ו-DSE
(), מאפשר לדגם שבע-ליבות להשיג גישה ל-fMAX של דגם הליבה היחידה, ולהאיץ אותו
ל-500GFLOPs, עם יותר מ-10GFLOPs/W תוך שימוש ב-28 ננומטר.
תוצאת GFLOPs/W זו גבוהה הרבה יותר מיעילות צריכת החשמל הניתנת להשגה באמצעות CPU או GPU. במושגים של השוואות GPU, ה-GPU אינו יעיל באורכי FFT אלה, ולכן לא מוצגים בוחני ביצועים כלשהם. ה-GPU הופך יעיל עם אורכי FFT של מאה אלף נקודות, כשהוא יכול לספק האצה מועילה ל-CPU. ואולם, אורכי FFT קצרים יותר שכיחים בעיבוד מכ”ם, כשהנורמה היא אורכי FFT של 512 עד 8,192.
לסיכום, GFLOPs מועילים הם בד”כ מקטע מהשיא או מה-GFLOPs התיאורטיים. בשל סיבה זו, גישה טובה יותר היא להשוות את הביצוע עם אלגוריתם, שמסוגל לייצג באופן סביר מאפיינים של יישומים טיפוסיים. עם עליית המורכבות של האלגוריתם המשווה, הוא הופך לטיפוסי יותר לביצוע של מערכת המכ”ם עצמה.
בוחן ביצועים השוואתי של אלגוריתם
במקום להתבסס על דירוגי ה-GFLOPs של הספק בקבלת החלטות בטכנולוגיית עיבוד, החלופה היא להתבסס על הערכות של צד ג’ תוך שימוש בדוגמאות בעלות מורכבות מספקת. אלגוריתם שכיח למכ”ם (space-time adaptive processing) הוא פירוק חולצקי. בד”כ משתמשים באלגוריתם זה באלגברה ליניארית לפתרון יעיל של משוואות מרובות, וניתן להשתמש בו במטריצות מתאם.
לאלגוריתם חולצקי יש מורכבות מספרית גבוהה, וכמעט תמיד הוא מצריך ייצוג מספרי של נקודה צפה לשם קבלת תוצאות הגיוניות. החישובים הנדרשים הם פרופורציונאליים ל-3N, כש-N הוא ממד המטריצה, כך שדרישות העיבוד הן בד”כ תובעניות. מאחר שמערכות מכ”ם בד”כ פועלות בזמן אמת, אחת הדרישות היא תפוקה גבוהה. התוצאה תהיה תלויה הן בגודל המטריצה והן בתפוקת העיבוד של המטריצה הנדרשת, אבל לעתים קרובות היא עשויה להיות גדולה מ-100GFLOPs.
טבלה 1 מציגה את תוצאות בוחני הביצועים ההשוואתיים בהתבסס על GPU של Nvidia המדורג ב-1.35 TFLOPs, תוך שימוש בספריות שונות, כמו גם Xilinx Virtex6 XC6VSX475T, FPGA ששופר עבור עיבוד DSP עם צפיפות של 475K LCs. רכיבים אלה זהים בצפיפות ל-FPGA מתוצרת Altera שבו השתמשו לבוחני הביצועים של חולצקי. LAPACK ו-MAGMA הן ספריות המסופקות באופן מסחרי, בשעה ש-GPU GFLOPs מתייחסים ליישום ה-OpenCL שפותח באונ’ טנסי. ה-GPU GFLOPs משופרים בבירור בגדלי מטריצה קטנים יותר.
460K אלמנטים לוגיים (KEs) בגודל בינוני מתוצרת החברה עבר בוחן ביצועים ע”י החברה באמצעות אלגוריתם חולצקי בעיבוד נקודה צפה בדיוק רגיל. כפי שרואים בטבלה 2, ביצועי ה-FPGA מסוג Stratix V על אלגוריתם חולצקי הרבה יותר גבוהים מאשר תוצאות Xilinx. בוחני הביצועים של החברה כללו פירוק QR, אלגוריתם עיבוד מטריצה נוסף במורכבות סבירה. ניתן להשיג מהחברה את חולצקי ו-QRD כליבות פרמטריות.
יש לציין כי גדלי המטריצה בבוחני הביצועים אינם זהים. התוצאות של אונ’ טנסי מתחילות בגדלי מטריצה של [512 . 512], בשעה שבוחני הביצועים של החברה הגיעו עד [360×360] עבור חולצקי ו-[450×450] עבור QRD. הסיבה לכך היא ש-GPUs אינם יעילים בגדלי מטריצה קטנים יותר, כך שכמעט אין תמריץ להשתמש בהם להאצת CPU במקרים אלו. בניגוד לכך, FPGAs מסוגלים לפעול באופן יעיל עם מטריצות הרבה יותר קטנות. יעילות זו היא חיונית, שכן מערכות מכ”ם זקוקות לתפוקה די גבוהה, באלפי מטריצות בשנייה.
משתמשים בגדלים קטנים יותר, גם כשקיים צורך בחלוקת מטריצה גדולה למטריצות קטנות יותר לצורכי עיבוד.
נוסף על כך, בוחני הביצועים של החברה מיוחסים לכל ליבת חולצקי. כל ליבת חולצקי פרמטרית מאפשרת בחירה של גודל מטריצה, גודל וקטור וספירת ערוצים. גודל הווקטור קובע בקירוב את משאבי ה-FPGA. מטריצה גדולה יותר [360 . 360] משתמשת בווקטור גדול יותר, וכך מאפשרת לליבה אחת ב-FPGA זה לפעול ב-91GFLOPs. המטריצה הקטנה יותר
[60 . 60] משתמשת בפחות משאבים, כך שניתן ליישם שתי ליבות, ובסך הכול 2 . 42 = 84GFLOPs. המטריצה הקטנה ביותר [30 . 30] מאפשרת שלוש ליבות, ובסך הכול, 3 . 25 = 75GFLOPs.
נראה ש-FPGAs מתאימים יותר לבעיות עם נתונים בגדלים קטנים יותר, וזה המקרה במערכות מכ”ם רבות. היעילות המופחתת של GPUs נובעת מהגדלת עומסי מחשוב כדוגמת 3N, הגדלת נתוני I/O כדוגמת 2N ובסופו של דבר צווארי בקבוק I/O של ה-GPU הופכים לבעייתיים פחות כאשר מערך הנתונים גדל. נוסף על כך, עם עליית גדלי המטריצה, תפוקת המטריצה לשנייה צונחת באופן דרמטי בשל העיבוד המוגבר בכל מטריצה. בשלב מסוים, התפוקה הופכת נמוכה מדי מכדי לעשות בה שימוש במסגרת דרישות זמן אמת במערכות מכ”ם.
עבור FFTs, עומס המחשוב גדל ל-N log2 N, בעוד שנתוני I/O עולים כ-N. ושוב, בגדלי נתונים משמעותיים, ה-GPU הופך למנוע מחשוב יעיל. בניגוד לכך, FPGA הוא מנוע מחשוב יעיל בכל גדלי הנתונים, והוא מתאים יותר ברוב יישומי המכ”ם שם גדלי FFT הם צנועים, אבל התפוקה נמצאת בשיאה.
מתודולוגיית תכנון של GPU ו-FPGA
GPUs מתוכנתים באמצעות שפת CUDA שהיא קניינה הרוחני של Nvidia או שפת OpenCL, שפה בתקן פתוח. שפות אלה דומות מאוד מבחינת יכולת, כשההבדל הגדול ביותר ביניהן הוא שניתן להשתמש ב-CUDA א ורק ב-GPUs של Nvidia.
FPGAs מתוכנתים בד”כ באמצעות שפות HDL ,Verilog או VHDL. שפות אלה אינן מתאימות לתמיכה בדגמי נקודה צפה, אף שהגרסאות האחרונות משלבות הגדרה, לאו דווקא סינתזה, של מספרי נקודה צפה. למשל, במערכת Verilog, משתנה אמיתי קצר אנלוגי ל-IEEE יחיד (צף) ואמיתי ל-IEEE כפול.
Builder Advanced Blockset DSP
סינתזה של מסלולי נתונים של נקודה צפה לתוך FPGA באמצעות שיטות מסורתיות אינה יעילה, כפי שהודגם ע”י היכולת הנמוכה של ה-FPGAs מתוצרת Xilinx על אלגוריתם חולצקי, שבוצע באמצעות יישומי ליבת GEN של נקודה צפה של Xilinx. ואולם, Altera מציעה שתי חלופות. הראשונה היא שימוש ב-DSP Builder Advanced Blockset, מבנה המבוסס על Mathworks. כלי זה כולל תמיכה למספרים קבועים ומספרי נקודה צפה, ותומך בשבעה דיוקים שונים של עיבוד נקודה צפה, לרבות יישומי מחצית IEEE, יישומי דיוק רגיל ודיוק כפול. נוסף על כך תומך כלי זה בווקטוריזציה, שנדרשת ליישום יעיל של אלגברה ליניארית. העובדה החשובה מכל היא יכולתו של כלי זה למפות ביעילות מעגלי נקודה צפה על ארכיטקטורות FPGA בעלות נקודה קבועה הקיימות כיום, כפי שהודגם ע”י בוחני הביצועים התומכים קרוב ל-100GFLOPs על אלגוריתם חולצקי בגודל בינוני של 28 ננומטר. לשם השוואה, יישום חולצקי על FPGA בגודל דומה מתוצרת Xilinx, ללא יכולת הסינתזה הזו מציג רק 20GFLOPs של ביצוע על אותו אלגוריתם.
OpenCL עבור FPGAs
OpenCL היא שפה מוכרת למתכנתי GPU. מהדר OpenCL עבור FPGAs משמעותו שקוד OpenCL שנכתב עבור GPUs של AMD או Nvidia יכול להתהדר על FPGA. נוסף על כך, מהדר OpenCL מתוצרת Altera מאפשר לתוכניות GPU להשתמש ב-FPGAs, ללא כל צורך לפתח מערך טיפוסי של יכולות עיצוב ל-FPGA.
השימוש ב-OpenCL עם FPGAs מאפשר מספר יתרונות מפתח על פני GPUs. ראשית, GPUs נוטים להיות מוגבלי I/O. ה-CPU המארח חייב לעבור על כל נתוני הקלט והפלט דרך ממשק ®PCI Express
(). העיכובים הנובעים מכך עלולים להשהות את מנועי העיבוד של GPU, והדבר יוביל לביצועים נמוכים.
הרחבות OpenCL עבור FPGAs
FPGAs ידועים בשל המגוון הרחב של יכולות I/O בפס רחב. יכולות אלה מאפשרות לנתונים לזרום אל ה-FPGA וממנו בטכנולוגיית Gigabit Ethernet
(), ב-®Serial RapidIO () או ישירות מממירים אנלוגיים לדיגיטליים (ADCs) ומממירים דיגיטליים לאנלוגיים
() .החברה הגדירה הרחבה ספציפית לספק לתקן OpenCL לשם תמיכה בפעולות הזרמה. הרחבה זו היא מאפיין חיוני במערכות מכ”ם, שכן היא מאפשרת לנתונים לנוע ישירות מעיבוד המרת תדר דיגיטלי מטה ועיצוב אלומה בקצה האחורי של הנקודה הקבועה אל שלבי עיבוד נקודה צפה לשם דחיסת דופק, דופלר, STAP, אבחנת מטרות נעות (MTI) ופונקציות אחרות המוצגות בתרשים 2. באופן זה, זרם הנתונים נמנע מצוואר בקבוק CPU לפני שהוא מועבר אל מאיץ GPU, כך שזמן האחזור הכולל של תהליך העיבוד יורד.
FPGAs מסוגלים להציע זמן אחזור לעיבוד שהינו נמוך בהרבה מזה של ה-GPU, אפילו באופן נפרד מצווארי הבקבוק של ה-I/O. ידוע היטב ש-GPUs חייבים לפעול על אלפי חוטים כדי לתפקד באופן יעיל, בשל זמני האחזור הארוכים אל הזיכרון וממנו ואפילו בין ליבות העיבוד הרבות של ה-GPU. בפועל, ה-GPU חייב להפעיל משימות רבות כדי למנוע מליבות העיבוד להשתהות בשעה שהן ממתינות לנתונים, עובדה המתבטאת בזמן אחזור ארוך מאוד לכל פעולה נתונה.
לעומת זאת, ה-FPGA משתמש בארכיטקטורת “מיקבול ברמת גרעיניות גסה”. ארכיטקטורה זו יוצרת מסלולי נתונים מקבילים וממוטבים, שכל אחד מהם פולט תוצאה אחת בכל מחזור שעון. מספר ההדגמים במסלול הנתונים תלוי במשאבי ה-FPGA, אבל באופן טיפוסי הוא נמוך יותר ממספר ליבות ה-GPU. ואולם, לכל הדגם של מסלול נתונים יש תפוקה גבוהה יותר מזה של ליבת GPU. היתרון העיקרי בגישה זו היא זמן אחזור נמוך המהוה יתרון ביצוע חיוני ביישומים רבים.
יתרון נוסף של FPGAs הוא צריכת החשמל הנמוכה שלהם, שמשמעותה GFLOPs/W נמוך באופן דרמטי. מדדי ההספק של FPGA המשתמשים בלוחות פיתוח מצביעים על 5-6GFLOPs/W עבור אלגוריתמים כדוגמת חולצקי ו-QRD, וכ-10GFLOPs/W עבור אלגוריתמים פשוטים יותר כדוגמת FFTs. מדדי יעילות האנרגייה של GPU קשים יותר למציאה, אבל השימוש בביצועי GPU ברמה של 50GFLOPs עבור חולצקי וצריכת חשמל טיפוסית של W200, משמעותו
0.25GFLOPs/W, כלומר, צריכת חשמל גדולה פי 20 לכל FLOPs שימושי.
עבור מכ”ם מוטס או נייד, שיקולי הגודל, המשקל וההספק (SWaP) חשובים ביותר. ניתן לדמיין מזל”טים נושאי מכ”ם עם עשרות TFLOPs במערכות עתידיות. כושר העיבוד הזמין מותאם ביכולותיו לצרכי הרזולוציה והכיסוי הנדרשים למערכת מכ”ם מודרנית.
מסלול נתונים משולב
הן OpenCL והן DSP Builder מתבססים על טכניקה הידועה בשם “מסלול נתונים משולב” (תרשים 3), שבה עיבוד נקודה צפה מבוצע באופן כזה שמפחית בצורה דרמטית את מספר המעגלים מזיזי התוף הנדרשים, ועובדה זו מאפשרת יצירת דגמים בהיקף נרחב בעלי נקודה צפה בעלת יכולת ביצוע גבוהה תוך שימוש
ב-FPGAs.
כדי להפחית את התדר של יישום הזזת תוף, תהליך הסינתזה מחפש הזדמנויות שבהן השימוש ברוחבי מנטיסה גדולים יותר עשוי לקזז את הצורך התכוף בנורמליזציה ודה-נורמליזציה. הזמינות של מכפילים קשיחים 27*27 ו-36*36 מאפשרת שימוש במכפילים גדולים יותר באופן משמעותי מ-23 ביטים הנדרשים ע”י יישומים בדיוק רגיל. יצירת מכפילים 54*54 ו-72*72 מאפשרת יותר מ-52 ביטים הנדרשים ליישומים בדיוק כפול. הלוגיקה של FPGA כבר ממוטבת עבור יישומים של מעגלי מסכם גדולים בעלי נקודה קבועה, לרבות מעגלים מובנים בפונקציית carry look-ahead.
במקרים בהם נדרשות נורמליזציה ודה-נורמליזציה, יישום חלופי שנמנע מרמת ביצוע נמוכה וניתוב מוגבר הוא השימוש במכפילים. מכפיל 24 . 24 מזיז את הקלט בהכפלה ב-2n עבור מנטיסה ברמת 24 ביט בדיוק רגיל (לרבות סיבית סימן). ושוב, הזמינות של המכפילים הקשיחים
ב-27 . 27 ו-36 . 36 מאפשרים גדלי מנטיסה מורחבים ביישומי דיוק רגיל, וניתן להשתמש בהם כדי ליצור את גדלי המכפיל עבור יישומים בדיוק כפול.
הוצאת dot product לווקטור היא הפעולה הבסיסית הצורכת את רוב
ה-FLOPs שבהם משתמשים באלגוריתמים ליניאריים באלגברה. יישום בדיוק רגיל של dot product ב-64 long מצריך 64 מכפילי נקודה צפה, ובעקבותיו יגיע עץ מסכם שעשוי מ-63 מסכמי נקודה צפה. יישום כזה יצריך מעגלי הזזת תוף רבים.
במקום זאת, הפלטים של 64 מכפילים עשויים לעבור דה-נורמליזציה למעריך רגיל, שהוא הגדול ביותר בין 64 המעריכים. בשלב זה ניתן לסכם את 64 הפלטים באמצעות מעגל של מסכם נקודה קבועה, ונורמליזציה אחרונה תתבצע בסוף העץ המסכם. עיבוד נקודה צפה בבלוק מקומי מחולק עם כל הנורמליזציה והדה-נורמליזציה הזמניות הנדרשות בכל מסכם אינדיבידואלי, והוא מוצג בתרשים 4. אפילו בעיבוד נקודה צפה לפי IEEE 754, המספר עם המעריך הגדול ביותר קובע את המעריך בסוף, כך שהשינוי הזה מעביר את התאמת המעריך לנקודה מוקדמת יותר בחישוב.
ואולם, כשמבצעים עיבוד יחיד, התוצאות הטובות ביותר מתקבלות בביצוע דיוק רב ככל האפשר במסגרת ביצוע קיצוץ תוצאות בסוף החישוב. הגישה כאן מפצה על הדגמה מוקדמת תת-מיטבית זו באמצעות ביצוע רוחבי סיביות מנטיסה נוספות מעל אלה שנדרשות ע”י עיבוד נקודה צפה לפי דיוק רגיל, בד”כ מ-27 ועד 36 ביטים. הרחבת המנטיסה מבוצעת עם מכפילי נקודה צפה כדי להימנע מהצורך לנרמל את המוצר בכל שלב.
גישה זו עשויה גם להפיק תוצאה אחת לכל מעגל שעון. ארכיטקטורות GPU עשויות להפיק את כל מכפילי הנקודה הצפה במקביל, אבל לא יכולות לבצע ביעילות את הסיכומים במקביל. חוסר יכולת זו נובעת מהדרישות שעל פיהן ליבות שונות חייבות להעביר נתונים דרך זיכרונות מקומיים כדי לתקשר זו עם זו, ולכן אין להן את גמישות הקישוריות של ארכיטקטורת FPGA.
גישת מסלול הנתונים המשולב מייצרת תוצאות מדויקות יותר מאשר התוצאות הקונבנציונליות של הנקודה הצפה לפי IEEE 754, כפי שמודגם בטבלה 3.
תוצאות אלה הושגו ביישום היפוכי מטריצה גדולים תוך שימוש בפירוק אלגוריתם חולצקי. אלגוריתם זהה יושם בשלוש דרכים שונות:
1. ב-MATLAB/Simulink עם עיבוד נקודה צפה בדיוק רגיל לפי IEEE 754.
2. ב-RTL עיבוד נקודה צפה בדיוק רגיל באמצעות גישת מסלול הנתונים המשולב.
3. ב-MATLAB עם עיבוד נקודה צפה בדיוק כפול.
יישום בדיוק כפול מדויק פי מיליארד (910) מאשר יישום בדיוק רגיל.
השוואה זו של טעויות בדיוק רגיל של MATLAB, טעויות דיוק רגיל של RTL וטעויות דיוק כפול של MATLAB מאשרת את עקביות הגישה של מסלול הנתונים המשולב. גישה זו מוצגת הן ביחס לטעות מנורמלת לאורך כל האלמנטים המורכבים במטריצת הפלט ואלמנט המטריצה עם טעות המקסימום. הטעות הכוללת או הנורמה מחושבת באמצעות נורמת פרובניוס:
מאחר שהנורמה כוללת טעויות בכל האלמנטים, היא בד”כ הרבה יותר גדולה מאשר הטעויות האינדיבידואליות.
נוסף על כך, הן DSP Builder Advanced Blockset וכלי זרימה של OpenCL תומכים וממטבים באופן ברור מודלים קיימים לדור הבא בארכיטקטורת FPGA. ניתן לצפות לשיאים של עד כ-100GFLOPs/W בשל חידושים בארכיטקטורה וחידושים בטכנולוגיית עיבוד.
סיכום
למערכות מכ”ם ברמת ביצועים גבוהה יש כיום אפשרויות פלטפורמות עיבוד חדשות. נוסף על SWaP משופר מאוד, מסוגלים FPGAs לספק זמן אחזור נמוך יותר ו-GFLOPs גבוהים יותר מאשר פתרונות מבוססי מעבד. יתרונות אלה יהיו דרמטיים אף יותר עם הצגת הדור הבא של FPGAs, שיהיו בעלי יכולת חישוב אופטימאלית ובעלי יכולת ביצוע גבוהה.
מהדר OpenCL מתוצרת Altera מספק מעבר כמעט בלתי מורגש עבור מתכנתי GPU על מנת להעריך את היתרונות של ארכיטקטורת עיבוד חדשה זו. OpenCL של Altera תואם 1.2, עם מערכת מלאה של תמיכה בספריות מתמטיות. הוא מסיר את המגבלות המסורתיות של FPGA בכל הנוגע לסגירת תזמון, ניהול זיכרון DDR וחיבור לממשק של מעבד מארח PCIe.
למפתחי non-GPU, מציעה החברה כלי זרימה DSP Builder Advanced Blockset, שמאפשר למפתחים ליצור תוכניות DSP עם נקודה צפה או בעלי high-fMAX fixed, שמשמרות את היתרונות של ההדמיה מבוססת Mathworks ושל סביבת פיתוח. מפתחי מכ”ם השתמשו במוצר זה במשך שנים באמצעות FPGAs כדי ליצור מהלך עבודה והדמיה יעילים יותר, והוא מציע את ביצועי אותה fMAX כ-HDL המקודד ידנית.
מידע נוסף
1. נייר עמדה: השגת One TeraFLOPS באמצעות FPGA 28nm.
2. השוואת יכולות ביצוע של פירוק חולצקי על GPUs ו-FPGAs,, Depeng Yang, Junqing Sun, JunKu Lee, Getao Liang, David D. Jenkins, Gregory D. Peterson, and Husheng Li,, מחלקת הנדסת חשמל ומדעי המחשב, אונ’ טנסי:
saahpc.ncsa.illinois.edu/10/papers/paper_45.pdf
3. נייר עמדה: יישום תכנון FPGA בתקן OpenCL
תודות לכותב המאמר, מייקל פרקר, מנהל תכנון מוצר DSP, Altera Corporation
היסטוריית תיקון מסמך.
טבלה 4 מציגה את היסטוריית התיקון של מסמך זה.
