בחודשים האחרונים, עולם פיתוח התוכנה עובר טלטלה. מפתחים מדברים על vibe coding כתיבת קוד על ידי תיאור רעיון בשפה טבעית, תוך כדי שה-AI ממיר אותו לקוד עובד בזמן אמת. בהרצאתו לאחרונה בפתיחת כנס GTC, אמר ג'נסן הואנג, מנכ"ל NVIDIA, ש100% ממהנדסי התוכנה בארגון משתמשים באחד או יותר מהכלים כמן Claude Code, Codex וCursor. קלות פיתוח התוכנה בעזרת AI גרמה לקריסת מניות חברות תוכנה ארגוניות, במה שכונה Saaspocalypse.
השאלה שמטרידה אותנו — מהנדסי חומרה — היא פשוטה: האם זה יגיע גם אלינו?
האם AI ישנה גם את עולם תכנון השבבים?
על פניו, התשובה נראית ברורה. אם AI יכול לכתוב קוד Python בצורה אוטונומית, מדוע שלא יוכל לכתוב RTL? אם אפשר לתאר פונקציונליות בשפה טבעית ולקבל תוכנה עובדת — מדוע לא ניתן לקבל סביבת וריפיקציה בSV/UVM?
למעשה, בשנתיים האחרונות צצו סטארטאפים רבים המציעים בדיוק את זה: כלי AI לתכנון שבבים, לאוטומציה של אימות, ליצירת RTL מתוך מפרטים. גם חברות ה EDA הגדולות — Cadence, Synopsys, Siemens — מתחילות להציע פתרונות AI משלהן (או לרכוש חברות סטארטאפ בתחום) כחלק מסביבות העבודה המוכרות.
ואכן, בכנס המרכזי של תעשיית הEDA, ה-DAC, בשנה שעברה ארגנתי מושב בו אירחנו 7 חברות שהציגו פתרונות בתחום, וגם השנה, בכנס שיערך בסוף יולי בלונג-ביץ', אנחנו צפויים לארגן שני מושבים כאלו.
אבל מה המצב בפועל? ומתי נוכל באמת לתכנן שבבים באופן אוטומטי?
מחזור ההייפ של גארטנר
כדי להמחיש את התשובה על השאלה הזו בצורה טובה, כדאי להיעזר ב"מחזור ההייפ" של גארטנר — מסגרת מוכרת שמתארת כיצד טכנולוגיות חדשות מתפתחות לאורך זמן. לפי המודל הזה, כל טכנולוגיה עוברת מסלול דומה: מתחילה כסוד שידוע רק למביני עניין, שעם הזמן מתפשט בהתלהבות רחבה שמנפחת ציפיות לשמיים. בהמשך, הרבה מציפיות אלו מתנגשות בקרקע המציאות והטכנולוגיה צוללת ל"תהום האכזבה" — ואז, לאט לאט, חלק מההצוותים מגלים מה באמת עובד ומטפסים אל "רמת הפרודוקטיביות הבשלה".
לאחרונה כתבתי מאמר בו מיפיתי את הנוף הנוכחי של AI בעיצוב שבבים על פי מודל זה. התמונה שהתקבלה מורכבת — אבל בדיוק בגלל זה היא שימושית. לא כל כלי AI בתעשייה שלנו נמצאים באותו מקום על הציר:
- עזרי יצירת קוד וסביבות IDE כבר נמצאים כמעט בכל שולחן ומספקים ערך אמיתי בסביבת עבודה יומיומיות.
- כלים מסויימים בתחום הdebug מספקים תוצאות אמינות בסביבות מבוקרות, ומתחילות להופיע בחלק מהפרויקטים.
- יצירת RTL מלא על ידי LLM – יש בזה הרבה נסיונות אבל מעט הוכחות בסביבת עבודה אמיתית ובקנה מידה גדול.
- אג'נטים שמתכננים שבב שלם לבד — נמצאים בפסגת ההייפ: החזון מרתק, המציאות עדיין לא שם.
- אחרון חביב, מודלי שפה (או (multi-modal לתכנון מעגלים — הטכנולוגיה שיכולה לשנות את הכל — עדיין ברובו בשלבי מחקר ובבעבודה בstealth mode בחברות מסויימות.
מחזור ההייפ של AI בתכנון שבבים — מיפוי נכון לתחילת 2026
המצב בפועל: מה עובד עכשיו ומה עדיין רחוק
כאמור, בינתיים, הפתרון הנפוץ ביותר בתעשייה שלנו הוא GitHub Copilot — או כלי IDE דומים — לעזרה בכתיבת קוד. וכאן חשוב להיות מדויקים: הכלים האלה ממש עובדים. הם עוזרים לכתיבת סקריפטים, לאוטומציה של משימות חוזרות, לכתיבת test benches פשוטים, ולפיסות RTL קטנות ומוגדרות היטב.
אבל — וזה "אבל" גדול — הם עדיין לא מסוגלים לכתוב בלוקים שלמים ומורכבים, ובוודאי לא לאמת אותם. המהנדס עדיין חייב להיות בשליטה, עדיין בודק, עדיין מחליט. ה-AI הוא עוזר מוכשר, לא מחליף.
זה רחוק מאוד מvibe coding שרואים בתוכנה. והשאלה היא מדוע?
מדוע עיצוב שבבים לא מתקדם באותו קצב של תוכנה?
הפער הזה אינו מקרי — יש לו ארבע סיבות מבניות שמסבירות אותו:
1. בעיית דאטה לאימון: GitHub מכיל מאות מיליוני מאגרי קוד פתוח. מיליארדי שורות של Python JavaScript ו-C++ שאומנו לתוך מודלים שמבינים תוכנה לעומק. לעומת זאת, לא תמצא ב GitHubהרבה קבצי תכנון שבבים. על פי רוב, הקוד שמתכנני שבבים כותבים לעולם לא עוזב את החברה ויכול לשמש לאימון מודלים. ולכן המודל מתחיל את העבודה בחוסר מידע קיצוני: קבצי Verilog ו-SystemVerilog ביחד מונים פחות מ-7,000 מאגרים ציבוריים בגיטהאב.
2. בעיית המשוב: בתוכנה, ה-AI יכול לנסות משהו, לטעות, לראות את התוצאה ולתקן — תוך שניות. זו הבסיס של הvibe coding . בתכנון שבבים, ריצת סימולציה יכולה לקחת שעות עד ימים. קשה לבנות לולאת אג'נטית מהירה כשלולאת המשוב איטית כל כך.
3. בעיית רף הנכונות: בתוכנה, "מספיק טוב לשחרר" הוא סטנדרט לגיטימי. מקסימום, אפשר לתקן אחרי. בתכנון שבבים, רף הנכונות הוא גובה הרבה יותר! טעות קטנה שמגיעה לסיליקון עולה מיליוני דולרים וחודשים של זמן תיקון. תכנון שהוא "כמעט נכון" — לא מספיק.
4. בעיית שרשרת הכלים: כלי הפיתוח בתוכנה מתועדים, רבים מהם כלי קוד פתוח, וה AI אומן עליהם בהיקף רחב. שרשרת כלי ה-EDA איננה פתוחה. בנוסף, הפורמטים של קבצים רבים הוא מורכב ולא נגיש – מה שמקשה על אימון מודלים.
ארבעת הסיבות האלו מצטרפות לכך שהתקדמות בעולמות השבבים איטית יותר.
אז מה כן עובד?
אחרי שהרצנו במספר פרויקטים שבהם הכנסנו AI לתהליכי תכנון ואימות, מצאנו שישנן משימות ספציפיות ומוגדרות שבהן AI מספק ערך אמיתי כבר היום — ומשימות אחרות שבהן AI עדיין פחות יעיל.
כמו כן, לעיתים, הצלחת ה-AI בעיצוב שבבים תלויה לא בשאלה "האם להכניס AI" אלא ב"כיצד והיכן להכניס AI".
בהרצאה בכנס Chipex נרחיב על הניסיון שלנו בתחום וניתן עצות מעשיות, טכנולוגיות וארגוניות, הנדרשות כדי להפיק את התועלת המירבית מהיכולות הבאמת מרשימות של הבינה המלאכותית.
משה זלצברג הוא מנכ"ל חברת שירותי תכנון שבבים Veriest Solutions. המאמר הזה עובד ממאמר רחב יותר שלו שניתן למצוא כאן
