RTL בעידן ה-Vibe Coding: 5 שערי אימות שעל כל מהנדס להקפיד עליהם

“האם אפשר לכתוב RTL באמצעות AI?”, “האם אפשר לסמוך על testbench ש-LLM יצר?” אלה שאלות שאני שומע לאחרונה לעיתים קרובות ממהנדסי תכנון ואימות וממועמדים לעבודה בסביבתי. מבלי לצטט אדם או פרויקט מסוים, אני מכליל כאן רק חששות אנונימיים שחזרו שוב ושוב ומשיב עליהם מנקודת מבטו של איש תעשייה.

התשובה בשורה אחת: אפשר ליצור טיוטת RTL בעזרת AI. עם זאת, אדם חייב לאשר את חמשת שערי האימות: מפרט → lint → simulation·coverage → formal·CDC → synthesis·STA·PPA.

עברנו כבר את השלב שבו AI רק מסייע בכתיבת כמה שורות Verilog. Cadence מסבירה כי ChipStack AI Super Agent מחבר בין יצירת RTL, יצירת testbench, תזמור regression ו-debug באמצעות סוכנים ייעודיים. באפריל 2026 היא הודיעה כי בעבודה עם לקוחות ראשונים נצפה שיפור בפרודוקטיביות של עד פי 10. נתון זה מבוסס על הודעת הספק ולא על benchmark עצמאי, ולכן אין להכליל ממנו כפי שהוא. עם זאת, הכיוון ברור: ממשק ה-EDA נע מ-GUI ו-Tcl לעבר “סוכן שמקבל יעד ומזין בחזרה את תוצאות הכלים”.

את המגמה הרחבה לגבי השלב הראשון בתעשייה שישתנה בעקבות AI EDA סקרנו במאמר מערך הפרודוקטיביות של AI EDA: האימות וה-closure משתנים לפני RTL. מאמר זה מתמקד בשערי אישור שאפשר ליישם בפרויקטים אמיתיים ובתיקי עבודות.

הבעיה מתחילה כשמחילים על RTL את אמת המידה של vibe coding בתוכנה: “אם זה מתקמפל והדמו רץ, זה מספיק”. RTL אינו קוד שהעבודה עליו מסתיימת ברגע שהפונקציונליות נכונה. זהו מפרט מימוש שחייב לעמוד יחד בדרישות של clock, reset, protocol, CDC, power intent, יכולת synthesis, ‏PPA ו-signoff constraint.

שער 1: האם הפכתם שפה טבעית למפרט בר-ביצוע?

“צור AXI slave” אינו מפרט. לכל הפחות, יש להכריע בנושאים הבאים.

• ה-protocol וה-subset הנתמכים
• רוחב data/address
• מספר ה-outstanding transactions
• יעדי latency ו-throughput
• סוג ה-reset וה-polarity שלו
• טיפול ב-invalid access
• תנאי backpressure
• תחומי clock ו-power

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

תנאי מעבר: רשימת הדרישות, טבלת I/O, מעברי המצב, דוגמת timing וההתנהגות בעת שגיאה מתועדים, ולכל אחד מהם יש מזהה מעקב.

שער 2: האם בדקתם את איכות ה-RTL, ולא רק את התחביר?

הצלחה ב-compile היא הסף הנמוך ביותר. יש לבדוק בניתוח סטטי אפשרות ל-latch inference, ‏width truncation, ‏signedness, ‏incomplete assignment, ‏combinational loop, ‏reset חסר ו-simulation-synthesis mismatch.

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

תנאי מעבר: compile/elaboration הושלמו בהצלחה, קריטריוני ה-lint severity מתקיימים, והנימוק לכל waiver מתועד.

שער 3: האם יש self-checking simulation ו-coverage?

כאשר AI מייצר יחד את ה-RTL ואת ה-testbench, הוא עלול לשכפל את אותה פרשנות שגויה בשני הקבצים. ככל האפשר, יש ליצור את ה-reference model, ה-assertions וה-testbench כייצוגים עצמאיים.

מערך הבדיקות המינימלי צריך לכלול את הפריטים הבאים.

• reset ושחרור reset
• single transaction תקינה ו-transactions רציפות
• backpressure והשהיה מרבית
• ערכי גבול ו-illegal input
• הצירופים האפשריים של protocol ordering
• long random regression

זו גם הסיבה שמחקרים ממשפחת VerilogEval מעריכים RTL של LLM באמצעות testbench, ושמחקרים עדכניים שיפרו את הביצועים באמצעות simulation-error localization-correction loop. לולאת משוב מבוססת כלים חשובה יותר מיצירה ב-one-shot.

תנאי מעבר: לכל מזהה דרישה מקושר test או assertion, ה-regression ניתן לשחזור, ופריטי ה-functional coverage שלא הושגו מוסברים.

שער 4: האם ה-RTL עבר formal, CDC ו-equivalence בלתי תלויים?

Simulation בוחנת רק את הנתיבים שהורצו. formal property יעילה במיוחד בבלוקים שבהם מרחב המצבים חשוב, כגון control logic, ‏arbitration ו-protocol safety property. אם קיימים כמה clocks או asynchronous reset, ניתוח CDC/RDC צריך להיות שער נפרד.

אם AI ביצע אופטימיזציה ל-RTL קיים או יצר ECO, ‏equivalence חשובה במיוחד. Cadence מתארת את כלי ה-equivalence ממשפחת Conformal כ-auditor עצמאי שבודק אם התוצאה שהפיק כלי המימוש זהה מבחינה לוגית. המילה החשובה כאן אינה AI, אלא עצמאי. אסור לקשור את המחולל ואת הבודק לאותו תהליך הסקה.

תנאי מעבר: נשמרים assertion proof או bound מפורש, החלטה מתועדת לגבי כל CDC/RDC violation ותוצאת equivalence לפני השינוי ואחריו.

שער 5: האם ה-RTL עומד בדרישות synthesis, STA, PPA ובתנאים הפיזיים?

גם RTL נכון פונקציונלית עלול להיכשל לאחר synthesis. דוגמאות אופייניות הן combinational path ארוך, priority chain מוגזמת, clock gating שגוי, fanout גדול וכשל ב-memory inference.

אל תתנו ל-AI יעד PPA כמספר יחיד. צמצום area בלבד עלול לפגוע ב-timing או ב-testability. לאחר שמקבעים את ה-constraint, ה-library, ה-corner וגרסת הכלי, יש להשוות יחד את הפריטים הבאים.

• worst/total negative slack
• area ו-cell count
• אומדן dynamic/leakage power
• congestion ו-physical feasibility
• ההשפעה על כללי DFT ו-low-power

תנאי מעבר: תוך שמירה על functional equivalence מול RTL הבסיס, מתקיימים הטווחים המוסכמים ל-timing·area·power·physical feasibility.

מה אפשר להפקיד בידי AI, ומה דורש אישור אנושי

מיומנויות הנדסיות שערכן עולה בעידן ה-AI

היקף הקלדת הקוד עשוי להצטמצם. לעומת זאת, ערכן של ארבע יכולות עולה.

1. היכולת להמיר דרישות עמומות לחוזה בר-ביצוע
2. היכולת למצוא את הסיבה האמיתית ב-logs וב-waveform
3. היכולת לתכנן את עצמאות המחולל והבודק
4. היכולת להסביר את ה-trade-off בין פונקציונליות, ביצועים, הספק ומימוש פיזי

שאלות נפוצות

ש. האם אפשר לכלול בפורטפוליו RTL שנוצר באמצעות ChatGPT או Claude?

כן. עם זאת, הציגו ראיות לאימות ולא את ה-prompt. צריכים להיות לכם מפרט, test plan, ‏assertions, ‏coverage, תוצאות synthesis ותיעוד שמראה כיצד גיליתם ותיקנתם שגיאות שה-AI יצר.

ש. אם AI יצר גם את ה-testbench, האם האימות לא הסתיים?

לא. ה-RTL וה-testbench עלולים לחלוק אותה פרשנות שגויה. נדרשים oracles אחרים, כגון reference model עצמאי, protocol assertions, ‏formal ו-VIP מסחרי.

ש. אם כך, האם מספר המשרות למהנדסי RTL יקטן?

משקלם של קידוד חוזר וסיווג logs עשוי לרדת. מנגד, חשיבותם של האנשים האחראים ל-spec, ‏architecture, ‏verification closure ו-physical trade-off תגדל. סביר יותר שמוקד האחריות יעבור מאשר שהתפקיד ייעלם.

ש. האם אפשר להזין קוד של החברה ל-AI חיצוני?

אל תעשו זאת ללא אישור בהתאם למדיניות החברה ולדרישות האבטחה. RTL, ‏constraint, ‏log ו-waveform עשויים להכיל את מבנה המוצר ואת נקודות התורפה שלו. תחילה יש להגדיר סביבת enterprise מאושרת וגבולות נתונים.

לסיכום

“האם אפשר לסמוך על RTL ש-AI יצר?” אינה השאלה המדויקת. השאלה הטובה יותר היא זו.

האם דאגנו שהוא יעבור את אותם חמישה שערי אימות, בלי קשר לזהות היוצר?

Vibe coding מייצר טיוטות במהירות. הדרך לסיליקון עדיין עוברת בראיות הניתנות לאימות.

מקורות פומביים

• Cadence ChipStack AI Super Agent
• הכרזת Cadence–NVIDIA על agentic AI
• Cadence Conformal AI Studio
• המאמר OpenLLM-RTL
• Understanding and Mitigating Errors of LLM-Generated RTL Code
• מאגר NVIDIA VerilogEval

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