🤖 AI

ContractHIL-HLS: Contract-Aligned Multi-Agent Workflow with Hardware-in-the-Loop Feedback for HLS Design

تقدم هذه الورقة ContractHIL-HLS، وهو سير عمل متعدد الوكلاء متوافق مع العقود يدمج الترجمة المهيكلة من اللغة الطبيعية إلى العقود مع التغذية الراجعة في حلقة "الأجهزة في الحلقة" (hardware-in-the-loop) لتحسين معدلات النجاح بشكل كبير في مهام تصميم (HLS) وتحسين مسرعات التشفير لما بعد الكم على مستوى اللوحة.

المؤلفون الأصليون: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

نُشر 2026-07-29

📖 6 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Jingbo Zhang, Haoxiang Sun, Wenbo Wang, Wenbo Zhang

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك تحاول تعليم روبوت فائق السرعة وذكي للغاية كيفية بناء آلة معقدة، مثل منصة ألعاب فيديو مخصصة أو خزنة فائقة الأمان. تعطي الروبوت تعليمات باللغة الإنجليزية العادية، مثل "اجعلها سريعة وآمنة". يحاول الروبوت، المدعوم بنموذج لغوي كبير (ذكاء اصطناعي يقرأ ويكتب الكود)، بناء الآلة. لكن هناك مشكلة؛ فالروبوت بارع في كتابة "فكرة" الكود، لكنه غالبًا ما ينسى القواعد الصغيرة والمملة التي تحتاجها الآلات الحقيقية لتعمل فعليًا، مثل مقدار الطاقة التي تستهلكها أو ما إذا كانت القطع تتناسب مع بعضها البعض. هذا هو عالم "التوليف عالي المستوى" (HLS)، حيث يحاول البشر استخدام الذكاء الاصطناعي لتحويل الأفكار البسيطة إلى تصميمات أجهزة فعلية للرقائق. السؤال الكبير ليس فقط "هل يستطيع الذكاء الاصطناي كتابة الكود؟" بل "هل يستطيع الذكاء الاصطناعي بناء شيء يعمل فعليًا على لوحة حقيقية دون أن نضطر لإصلاح كل خطأ يدويًا؟"

هنا يأتي دور فريق من الباحثين من جامعة بكين للتكنولوجيا بفكرة جديدة تسمى ContractHIL-HLS. فكر في الأمر كـ "مدير مشروع ذكي" للذكاء الاصطناعي. بدلاً من مجرد ترك الذكاء الاصطناعي يدردش معك ذهابًا وإيابًا، فإنهم يجبرونه على توقيع "عقد" رسمي أولاً. هذا العقد هو قائمة صارمة ومنظمة من القواعد: "إليك بالضبط ما يجب أن تفعله الآلة، وإليك الأشياء التي لا يمكنها القيام بها مطلقًا، وإليك كيف سنختبرها". إذا حاول الذكاء الاصطناعي كسر القواعد، فإن النظام يكشف ذلك فورًا. والأروع من ذلك، أنهم يربطون هذه العملية بأجهزة حقيقية. إذا صمم الذكاء الاصطناي شريحة تسخن كثيرًا أو تعمل ببطء شديد، فإن الآلة الحقيقية ترسل "تقرير فشل" إلى الذكاء الاصطناعي، والذي يتعين عليه بعد ذلك إعادة كتابة التصميم لإصلاح الخطأ. إنه يشبه لعبة فيديو حيث لا يخمن الشخصية الحل فحسب، بل يصطدم بالفخ، ويرى سبب فشله بالضبط، ثم يحاول مرة أخرى بخطة أفضل.

المشكلة: الذكاء الاصطناعي بارع في الدردشة، سيئ في البناء

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

أدرك الباحثون أنه بدلاً من الاعتماد على محادثة طويلة وفوضوية، كانوا بحاجة إلى عقد مهيكل. تخيل أنك تطلب بيتزا مخصصة. بدلًا من قول "أريد بيتزا لذيذة"، تقوم بملء نموذج: "العجينة: رقيقة. الإضافات: بيبيروني فقط. بدون فطر. يجب أن تكون جاهزة في 10 دقائق". هذا النموذج هو "العقد". في عالم تصميم الرقائق، يترجم هذا العقد فكرتك الغامضة إلى مجموعة صارمة من القواعد التي يجب على الذكاء الاصطناعي اتباعها.

الحل: سير عمل الوكلاء الثلاثة

بنى الفريق نظامًا يتكون من ثلاثة "وكلاء" متخصصين (مساعدي ذكاء اصطناعي) يعملون معًا مثل آلة متناغمة:

وكيل العقد (The Contract Agent): يأخذ هذا الوكيل طلبك غير المنظم باللغة الطبيعية (مثل "اصنع نظام رسائل آمن") ويحوله إلى ذلك "العقد" الصارم والممهد. إنه يحدد الواجهة، والقيود (ما هو محظور)، وقواعد الاختبار.
وكيل HTML (The HTML Agent): يأخذ هذا الوكيل العقد ويحوله إلى صفحة ويب (HTML) نظيفة ومهيكلة. لماذا صفحة ويب؟ لأنها سهلة القراءة للبشر، وسهلة الفهم لوكيل الذكاء الاصطناعي التالي، وسهلة التحقق منها بواسطة سكربتات الكمبيوتر. إنها تعمل كسجل دائم وغير قابل للتغيير للقواعد.
وكيل الحلقة في العتاد (The HIL Agent): هذا هو الباني. ينظر إلى عقد HTML، ويكتب الكود، ثم — وهنا يكمن السحر — يختبره فعليًا على أجهزة حقيقية أو يحاكيه. إذا قالت الأجهزة "مهلاً، هذا التصميم يستهلك الكثير من الذاكرة"، يرى وكيل HIL هذا الدليل، ويقرأ العقد، ويعيد كتابة الكود لإصلاح الأمر. إذا لم يتمكن من الإصلاح، يعرف النظام وجوب "التراجع" وتجربة نهج مختلف.

ما وجدوه: انتصارات صغيرة وقفزات كبيرة

اختبر الفريق هذا النظام بطريقتين مختلفتين تمامًا لمعرفة ما إذا كان يعمل حقًا.

1. اختبار "التصميم الصغير" (HLS-Eval)
أولاً، اختبروا النظام على 94 مهمة برمجة صغيرة ومعيارية. قارنوا بين ثلاث طرق:

المباشرة (Direct): مجرد سؤال الذكاء الاصطناعي دون أي قواعد خاصة.
العقد (Contract): استخدام العقد المهيكل ولكن بدون تغذية راجعة من الأجهزة الحقيقية.
ContractHIL-HLS: استخدام النظام الكامل مع العقد وتغذية الأجهزة الراجعة.

كانت النتائج واضحة. نجحت الطريقة "المباشرة" في اجتياز الاختبارات بنسبة 64.0% تقريبًا. وعندما أضافوا العقد، ارتفع معدل النجاح إلى 70.2%. ووصل النظام الكامل إلى 70.4% للمحاولات الفردية و 76.6% إذا سمحت للذكاء الاصطناعي بالمحاولة خمس مرات. وهذا يثبت أن مجرد إجبار الذكاء الاصطناعي على اتباع عقد مهيكل يجعله أكثر موثوقية، حتى قبل أن يلمس الأجهزة الحقيقية.

2. اختبار "العالم الحقيقي" (دراسة حالة PQC)
الاختبارات الصغيرة جيدة، ولكن هل تنجح في الأنظمة الكبيرة والمعقدة؟ لمعرفة ذلك، بنى الفريق مسرع رسائل آمن باستخدام التشفير ما بعد الكم (PQC) — وهو طريقة فائقة الأمان لإرسال الرسائل لا يمكن حتى لأجهزة الكمبيوتر الكمومية المستقبلية كسرها. هذا تحدٍ هندسي هائل يتضمن الذاكرة، والتوقيت، والطاقة.

بدأوا بتصميم واحد (تدفق بت واحد) يستغرق 207.3 مللي ثانية لمعالجة الرسالة. حلل النظام التغذية الراجعة من الأجهزة وأدرك أن التصميم مزدحم وبطيء للغاية. باتباع قواعد العقد، قام الذكاء الاصطناعي بتقسيم التصميم إلى جزأين منفصلين (تنظيم تدفق بت مزدوج). أحد الأجزاء يتولى الإرسال، والآخر يتولى الاستقبال.

النتيجة؟ عالج التصميم الجديد الرسائل في 52.4 مللي ثانية فقط. هذا تسريع هائل! كما استهلك طاقة أقل واجتاز جميع فحوصات التوقيت. نجح النظام في استخدام "العقد" لتوجيه الذكاء الاصطناعي من تصميم واحد بطيء إلى تصميم منقسم وسريع، مع الحفاظ على قواعد الأمان كاملة.

لماذا يهم هذا؟

تظهر الورقة البحثية أننا لسنا بحاجة لانتظار أن يصبح الذكاء الاصطناعي "عبقريًا" من تلقاء نفسه. بدلاً من ذلك، يمكننا بناء سير عمل حيث يتم توجيه الذكاء الاصطناعي بواسطة عقد صارم وغير قابل للكسر وتصحيحه بواسطة أدلة من العالم الحقيقي. وجد الباحثون أن هذا النهج لا يجعل الذكاء الاصطناعي يكتب الكود بشكل أسرع فحسب، بل يجعل الكود يعمل.

ومع ذلك، تشير الورقة بحذر إلى أن هذا ليس عصا سحرية لكل شيء. في اختباراتهم، كانت هناك مجموعة واحدة من المهام (تسمى "machsuite") حيث فشل الذكاء الاصطناعي تمامًا، حتى مع وجود العقد. وهذا يشير إلى أنه بينما يساعد العقد الذكاء الاصطناعي على اتباع القواعد، فإنه لا يستطيع إصلاح الأمر إذا كان الذكاء الاصطناعي ببساطة لا يعرف الرياضيات أو المنطق الأساسي بعد.

باختصار، ContractHIL-HLS هو جسر بين العالم الفوضوي للأفكار البشرية والعالم الصارم لرقائق الأجهزة. إنه يحول الذكاء الاصطناعي من كاتب مبدع إلى مهندس منضبط، مما يضمن أنه عندما نطلب آلة آمنة وسريعة، فإننا نحصل بالفعل على واحدة تعمل.

ملخص تقني: ContractHIL-HLS

بيان المشكلة

بينما أظهرت النماذج اللغوية الكبيرة (LLMs) قدرة على توليد أكواد الأجهزة (hardware code)، فإن هندسة التوليف عالي المستوى (HLS) العملية تتطلب سير عمل يحافظ على قصد التصميم عبر التكرارات، مما يضمن التوافق مع التغذية الراجعة لأدوات الأتمتة الإلكترونية (EDA)، والتحكم في المضيف، وملكية الذاكرة، وقياسات النشر على مصفوفات البوابات المنطقية القابلة للبرمجة ميدانياً (FPGA). تُظهر المعايك المرجعية الحالية (مثل Chip-Chat وRTLLM وHLS-Eval) أن النماذج يمكنها توليد كود صالح، لكنها غالباً ما تفشل في إنشاء سير عمل يضمن بقاء قصد التصميم قابلاً للتتبع مقابل التغذية الراجعة للأدوات ونتائج النشر. تعتمد النهج الحالية عادةً على مطالبات الأدوار الحوارية أو تاريخ المحادثة كحالة (state)، مما قد يؤدي إلى إغفال القيود التي فرضها مطالبات "المعماري" (architect) من قبل مطالبات "المبرمج" (coder) اللاحقة. علاوة على ذلك، يظل العمل المساعد لـ HLS باستخدام النماذج اللغوية الكبيرة متمحوراً بشكل أساسي حول النواة (kernel-centric)، ويفتقر إلى تغطية تقسيم البت ستريم (bitstream partitioning)، وملكية الحالة الحية (live-state ownership)، وحدود الأمان عبر المراحل.

المنهجية

يقترح البحث ContractHIL-HLS، وهو سير عمل متعدد الوكلاء متوافق مع العقود، مصمم لتحويل الطلبات غير الدقيقة باللغة الطبيعية إلى تطبيقات HLS قابلة للتتبع. يتميز سير العمل بثلاث آليات أساسية:

العقد المهيكل كأثر تنفيذي (Structured Contract as an Execution Artifact): بدلاً من الاعتماد على تاريخ حواري فضفاض، يقدم سير العمل عقداً رسمياً ( $C = \langle R, I, F, H, K, O, V, B \rangle$ ) يشفر المتطلبات في حقول صريحة: الدور/المنصة، الواجهة العامة، القصد الوظيفي، القيود الصارمة/السلبية، التوافق، قصد التحسين، أدلة التحقق، وسياسة التراجع (Rollback Policy). يعمل هذا العقد كأداة للمحاذاة الدلالية وتنفيذ المهام.
تفكيك الوكلاء حسب التدرج الدلالي (Agent Decomposition by Semantic Lowering): يتم تعريف الوكلاء بناءً على مهام التحويل الخاصة بهم بدلاً من الأدوار الحوارية:
- وكيل العقد (Contract Agent): يقوم بتطبيع اللغة الطبيعية إلى العقد المهيكل.
  بناءً على العقد، يقوم وكيل HTML بتقديم العقد في شكل أثر HTML مستقر وقابل للفحص يحتوي على أقسام وجداول وقوائم تحقق. هذا الأثر قابل للقراءة من قبل البشر والبرامج على حد سواء.
- وكيل الحلقة في الحلقة (Hardware-in-the-Loop - HIL Agent): يقوم بتنفيذ وتعديل التصميم باستخدام أثر HTML مدمج مع أدلة الأجهزة المقاسة.
حلقة التغذية الراجعة للحلقة في الحلقة (HIL Feedback Loop): يدمج سير العمل التغذية الراجعة من أدوات HLS (مثل Vitis)، وأدوات التنفيذ (مثل Vivado)، وقياسات تشغيل اللوحة (مثل PYNQ) مباشرة في حلقة التوليد واتخاذ القرار. وهذا يوسع التصميم بمساعدة النماذج اللغوية الكبيرة من كود النواة نحو إغلاق النظام واللوحة بالكامل. تتضمن الحلقة طلبات تنفيذ محدودة، وفحوصات رفض منخفضة التكلفة (التحليل، التجميع، اختبار الوحدة)، وفحوصات التوليف والتنفيذ، وقرار الاستمرار أو التراجع بناءً على الأدلة المقاسة (مثل أسوأ وقت سالب للتعادل WNS، واستخدام الموارد، واستهلاك الطاقة، ووقت التشغيل).

المساهمات الرئيسية

يحدد البحث ثلاث مساهمات رئيسية:

العقد المهيكل كأثر تنفيذي: يتم تشفير المتطلبات كحقول صريحة (الواجهة، القيود، التحقق، التحسين، التراجع) لمواءمة التوليد مع كائن هندسي مشترك بدلاً من تكرار نص المطالبة.
ملف HTML المستمر وحلقة التغذية الراجعة HIL: يتم تقديم العقد في شكل HTML مهيكل، ويتم تغذية مخرجات الأدوات (HLS، Vivado، مقاييس النشر) كحالات سير عمل من الدرجة الأولى لدفع قرارات التنفيذ والتراجع.
تنسيق الوكلاء من المعايك المرجعية إلى الحالات الهندسية: يوضح سير العمل أن النهج المتوافق مع العقود يحسن النتائج في 94 مهمة من مهام HLS-Eval المحلية، وينجح في نقل حلقة التصميم إلى نظام رسائل آمن يعتمد على التشفير ما بعد الكمي (PQC) ومختبر على اللوحة.

النتائج

تقييم HLS-Eval (إعداد التصميم الصغير)

تم التقييم باستخدام 94 مهمة HLS-Eval قابلة للتنفيذ محلياً باستخدام سلسلة أدوات Vitis HLS:

الأساس مقابل العقد: أدى إدخال العقد المهيكل وحده إلى تحسين معدل اجتياز اختبار الوحدة المقدر للنموذج الواحد (pass@1) من 64.0% (المطالبة المباشرة) إلى 70.2%.
سير العمل الكامل: حقق تدفق ContractHIL-HLS الكامل نسبة 70.4% لـ pass@1 ونسبة 76.6% لـ pass@5.
كفاءة الرموز (Tokens): استخدم إعداد "العقد" عدداً أقل من الرموز (3555) مقارنة بإعداد "المباشر" (3741) من خلال استبدال التعليمات المتكررة الفضفاضة بحقول مسمى، مما يشير إلى تحسن في الموثوقية دون مجرد زيادة طول المطالبة.
تحليل الفئات: لوحظت تحسينات في معظم عائلات المعايك (مثل chstone وpolybench وrosetta)، رغم أن مجموعة machsuite ظلت عند معدل اجتياز 0.0%، مما يشير إلى أن سير العمل يحسن الموثوقية للتنفيذات المعقولة ولكنه لا يستطيع التعويض عن القدرات الخوارزمية المفقودة.

دراسة حالة PQC (النشر على مستوى اللوحة)

تم التحقق من الصحة على مسرع رسائل آمن يعتمد على التشفير ما بعد الكمي (ML-KEM/ML-DSA):

الأداء: نجح سير العمل في الانتقال من تصميم أحادي البت ستريم إلى تنظيم ثنائي البت ستريم (تقسيم منطق KEM وDSA/XOR). أدى هذا إلى تقليل متوسط وقت تشغيل النص من 207.3 مللي ثانية إلى 52.4 مللي ثانية.
الكفاءة: تحسن حاصل الطاقة والزمن (EDP) المتحفظ من 171.3 mJ·s إلى 23.6 mJ·s.
التوقيت والموارد: عالج التصميم المقسم انتهاكات التوقيت (تحسن WNS من 1.570 نانو ثانية في الصورة الأحادية إلى 0.769 نانو ثانية و0.171 نانو ثانية في الصور المقسمة) وأعاد توزيع ضغط الذاكرة، حيث حققت كلتا الصورتين وقتاً إيجابياً للربط (routed timing slack).
التحقق: حافظ سير العمل على قواعد حدود المستقبل (receiver-boundary) والتحقق من الرسالة المفكوكة، مما ضمن أن ملكية الحالة كانت مرئية وصحيحة.

الأهمية والادعاءات

يزعم البحث أن ContractHIL-HLS يعالج الفجوة بين توليد الكود المعزول وتنفيذ سير العمل القابل للتتبع. تكمن أهميته في:

محاذاة الحالة: إثبات أن تحويل متطلبات اللغة الطبيعية الضمنية إلى هياكل مستقرة وقابلة للفحص (العقود/HTML) يحسن بشكل كبير من موثوقية توليد كود الأجهزة قبل توفر أي تغذية راجعة من اللوحة.
الإغلاق على مستوى النظام: إثبات أن سير العمل المتوافق مع العقود نفسه يمكن أن يتوسع من مستويات النواة في المعارك المرجعية إلى أنظمة معقدة مختبرة على اللوحة تتضمن تقسيم البت ستريم، وتنسيق المضيف، وحدود الأمان.
المراجعة القائمة على الأدلة: إنشاء آلية تصبح فيها مخرجات الأدوات (QoR، التوقيت، الطاقة) أثراً من الدرجة الأولى يقود قرارات التراجع، مما يمنع الانتشار الصامت للتصاميم التي تفشل في تحقيق بوابات محددة (مثل قيود التوقيت أو الموارد).

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