لماذا لا يزال التصميم المشترك بين العتاد والبرمجيات بعيداً رغم صعود الذكاء الاصطناعي؟

لم يغيّر انتشار الذكاء الاصطناعي حقيقة أساسية في صناعة أشباه الموصلات: تطوير العتاد والبرمجيات ما زال يجري غالباً داخل مسارين منفصلين. ويرى تحليل نشرته Semiconductor Engineering في 15 سبتمبر 2026 أن الفائدة من التصميم المشترك بين الجانبين معروفة منذ سنوات، لكن تطبيقها على نطاق واسع يصطدم بعوائق تنظيمية وتقنية لم يحلها الذكاء الاصطناعي بعد.

المشكلة تبدأ من بنية فرق العمل نفسها. فمهندسو العتاد والبرمجيات يستخدمون أدوات ولغات مختلفة، ويعملون وفق جداول زمنية وإيقاعات تطوير غير متزامنة. وفي النموذج التقليدي، يصل التصميم إلى مرحلة إنتاج الشريحة قبل أن تتولى فرق البرمجيات تكييف النظام معها، بما في ذلك التعامل مع التغييرات والأخطاء المعروفة باسم errata. ويصف Sam Grove، رئيس البرمجيات والأدوات في MIPS/GlobalFoundries، هذا الوضع بأنه تسليم متأخر يترك فريق البرمجيات تحت ضغط تشغيل المنتج بدلاً من المشاركة في تصميم الجيل التالي.

الفجوة ليست تنظيمية فقط

حتى عندما تحاول الشركات تطبيق التكامل المستمر، تظل سرعة الحصول على نتيجة موثوقة عقبة مركزية. ويشير Frank Schirrmeister، المدير التنفيذي للبرامج الاستراتيجية لحلول الأنظمة في Synopsys، إلى أن الانتقال من المواصفات إلى نموذج العتاد والبرمجيات يمكن أن يصبح سريعاً جداً، بشرط القدرة على محاكاة النظام بالسرعة الكافية.

توجد نماذج أولية افتراضية ومحاكاة وأدوات emulation ونماذج مبنية على FPGA، لكن لكل خيار مقايضة مختلفة بين الدقة والأداء وزمن التنفيذ. فالنموذج الافتراضي قد يساعد على اختبار تأثير البرمجيات في المعمارية مبكراً، بينما تمنح المحاكاة أو النمذجة الأكثر تفصيلاً رؤية أفضل للأداء والطاقة. لكن تشغيل عبء عمل كامل وممثل للمنتج النهائي يظل أصعب بكثير من اختبار وظيفة صغيرة أو عبء اصطناعي.

وتزداد الصعوبة عندما تريد الفرق تنفيذ العبء نفسه عبر مراحل متعددة، من المنصة الافتراضية إلى emulation ثم النموذج المبني على FPGA وصولاً إلى السيليكون. فاختبار عشر ثوانٍ من زمن تشغيل الشريحة قد لا يكون عملياً في المحاكاة، ما يفرض تحديد الجزء الذي يمكن تنفيذه في كل مرحلة، بدلاً من افتراض أن نموذجاً واحداً سيغطي جميع الاستخدامات.

المواصفات المشتركة شرط سابق للذكاء الاصطناعي

يرى الخبراء أن أول المتطلبات هو إنشاء مواصفات غنية ومتكاملة يمكن للمهندسين ووكلاء الذكاء الاصطناعي استخدامها معاً. ووفق المادة، لا تفعل ذلك اليوم إلا قطاعات محدودة، من بينها الصناعات العسكرية والفضائية بدرجة أكبر. ومن دون هذا النوع من المواصفات، لا يملك الذكاء الاصطناعي مرجعاً موحداً يربط متطلبات النظام بتصميم RTL والبرمجيات ونتائج التحقق.

قد تساعد التجارب الاصطناعية في قياس زمن التنفيذ واستهلاك الطاقة لوظائف برمجية على مجموعة من المعماريات، لكن هذه الخطوة لا تكفي وحدها لاتخاذ قرار تصميم. فالمهندسون يوازنون أيضاً بين المرونة والأداء، والتكلفة والحجم، وميزانية الطاقة، والحرارة، والعوامل البيئية. ويقول Arvind Srinivasan، مهندس حلول التحقق في Normal Computing، إن أحد أكثر التصاميم أداءً قد يكون مخصصاً بالكامل للمهمة، في حين لا توجد حتى الآن طريقة موحدة لترميز كل هذه القيود كي تستخدمها خوارزمية ذكاء اصطناعي كأهداف قابلة للتحسين.

ما الذي يستطيع الذكاء الاصطناعي فعله الآن؟

الاستخدامات الحالية أكثر محدودية من فكرة أن الذكاء الاصطناعي سيصمم النظام كاملاً. يقول Andy Meier، مدير تسويق المنتجات الرئيسي في Siemens EDA، إن العملاء يستخدمونه أساساً لإنشاء RTL وبيئات الاختبار، لكنه لا يراه مستخدماً على نطاق مماثل في القرارات المعمارية. ويرتبط ذلك بأن هذه القرارات تتطلب معرفة واسعة بالمفاضلات بين الأداء والطاقة والتكلفة وسلوك أعباء العمل.

في المقابل، تستخدم MIPS/GlobalFoundries وكلاء الذكاء الاصطناعي لكتابة البرمجيات والعتاد في مهام محددة، مع التشديد على فهم حدود الأداة وأخطائها. كما يلفت Steve Roddy، كبير مسؤولي التسويق في Quadric، إلى أن البرمجيات قد تتغير مرات كثيرة خلال الفترة بين بناء نموذج التصميم ووصول السيليكون، سواء بفعل المطورين أو مساعدي الذكاء الاصطناعي. وهذا يعني أن التصميم المشترك ليس قراراً يُتخذ مرة واحدة في بداية المشروع، بل عملية يجب أن تتعامل مع تغير البرمجيات باستمرار.

وتطرح Normal Computing احتمال استخدام الذكاء الاصطناعي لاستخلاص تمثيلات أكثر تجريداً للعتاد، بحيث يستطيع مطورو البرمجيات العمل قبل اكتمال RTL. ويستند هذا التصور إلى وجود تمثيل للمواصفات أو ontology يمكن أن يكون مرجعاً مشتركاً، لكنه لا يلغي الحاجة إلى ربط هذا التمثيل بالنماذج اللاحقة والتحقق من مطابقتها.

التحقق والتعاون هما عنق الزجاجة

يؤكد التحليل أن التقدم المرجح سيكون تدريجياً، لأن استبدال المنهجيات القائمة بالكامل يرفع مخاطر المشروع. ويشير Srinivasan إلى أن أدوات EDA لا تزال تعالج أجزاء صغيرة من المشكلة بدلاً من تحسين النتيجة العامة، كما أن الصناديق السوداء تحتاج إلى ضمانات للصحة وقابلية التدقيق وسجل موحد يوضح علاقة عناصر التصميم ونتائج التحقق بعضها ببعض.

وتظل المزامنة بين النماذج تحدياً عملياً. فالنموذج العالي المستوى في SystemC غير محدد التوقيت لا يساوي RTL من حيث الدقة الزمنية، وإبقاء الاثنين متسقين يستهلك وقتاً كبيراً في التحقق والتصديق وتهيئة البرمجيات. لذلك لا يكفي توفير نموذج افتراضي؛ المطلوب هو سلسلة مترابطة من نماذج المحاكاة والتحليل ونقل المعرفة بين فرق التصميم والتطبيقات ودعم العملاء.

من منظور certi.news، التغير الفعلي ليس إطلاق أداة واحدة ولا انتقال الصناعة فوراً إلى تصميم ذاتي يقوده الذكاء الاصطناعي. التغير هو أن البرمجيات بدأت تؤثر في تعريف المعمارية قبل اكتمال الشريحة، وأن أدوات EDA تحاول ربط مراحل كانت منفصلة. لكن المصدر لا يقدم دليلاً على أن هذه المشكلة حُلت، بل يوضح أن نقص المواصفات الموحدة، وكلفة المحاكاة، وتغير البرمجيات، والحاجة إلى قابلية التدقيق ما زالت قيوداً أساسية. لذلك ستبقى الخبرة البشرية حاسمة في القرارات المعمارية، بينما يتركز أثر الذكاء الاصطناعي في مهام محددة يمكن اختبارها ومراجعة نتائجها.