الرقائق وأشباه الموصلات

التكامل الرأسي يفرض نفسه في تصميم الأنظمة والرقائق

يرى تحليل Semiconductor Engineering أن الفصل التقليدي بين فرق hardware وsoftware لم يعد مناسباً للأنظمة الحديثة، خصوصاً مع تسارع أعباء الذكاء الاصطناعي واشتداد قيود الطاقة والحرارة. ويدفع ذلك الشركات إلى تصميم عتاد أكثر تخصصاً بالتوازي مع البرمجيات، مع بقاء تحديات الأدوات والتكلفة والتوحيد القياسي.

13 أغسطس 2026
6 دقائق قراءة
1 قراءة
التكامل الرأسي يفرض نفسه في تصميم الأنظمة والرقائق

لم يعد تحسين النظام ممكناً من خلال النظر إلى العتاد والبرمجيات كلٌّ على حدة، وفق تحليل نشره Brian Bailey، محرر التكنولوجيا المتخصص في EDA لدى Semiconductor Engineering. فالأحمال البرمجية تتغير بوتيرة أسرع من دورات تطوير الرقائق، بينما أصبحت الطاقة والأداء والحرارة عوامل مترابطة تفرض تعاوناً مبكراً بين فرق البرمجيات والعتاد، بدلاً من تسليم التصميم من فريق إلى آخر بعد انتهاء كل مرحلة.

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

من الفصل بين الفرق إلى النماذج الافتراضية

يقول Steve Roddy، كبير مسؤولي التسويق في Quadric، إن زمن بناء فريق العتاد لتصميمه ثم تسليمه إلى فريق البرمجيات المضمنة انتهى منذ أكثر من عقدين. وقد توسعت النمذجة الافتراضية خلال العقد الماضي لتشمل المدخلات الفيزيائية وواجهات المستشعرات، ضمن ما يُعرف بنمذجة التوأم الافتراضي.

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

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

موجة التخصص تعود بدافع الطاقة

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

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

ويشير Patrick Coles، كبير العلماء في Normal Computing، إلى أن وحدات معالجة الرسومات قد لا تكون نهاية تطور الحوسبة، مع تزايد الأدلة على اتساع دور ASICs. كما يوضح Frank Schirrmeister من Synopsys أن شركات الحوسبة فائقة النطاق تطور شرائح ومسرّعات خاصة بها لتحقيق تحسين مشترك لمؤشرات الأداء الرئيسية، مثل الأداء واستهلاك الطاقة، بدلاً من التركيز على السرعة وحدها.

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

RISC-V مثال على التخصيص المرتبط بالحمل

يبرز RISC-V في التحليل بوصفه مثالاً على الاتجاه نحو «الشرائح المصممة للحمل». فالشركات تطور امتدادات مخصصة للأنوية بهدف تحسين الأداء أو الطاقة، لكن هذه الامتدادات تتطلب أيضاً أجزاء من النظام البيئي، مثل المترجمات وأدوات الدمج البرمجي.

وتوضح Andrea Gallo، الرئيسة التنفيذية لـ RISC-V International، أن استخدام تعليمات مخصصة يحمّل الشركة كامل تكلفة الملكية، بما في ذلك سلسلة الأدوات والتكامل البرمجي. وقد تكون هذه المقاربة وسيلة سريعة للابتكار، لكن الشركة قد تسعى لاحقاً إلى تحويل الامتداد إلى معيار، بحيث تتوزع كلفة صيانته على النظام البيئي الأوسع. ويشير التحليل كذلك إلى أن معرفة حمل البرمجيات مسبقاً تتيح جعل عناصر المعالجة ملائمة للتطبيق، في حين تظل محركات الحوسبة العامة والقابلة للتوسع مهمة عند تشغيل برمجيات غير معروفة أو متغيرة.

الطاقة والحرارة توسعان نطاق التصميم المشترك

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

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

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

وتوضح مناقشة امتدادات المصفوفات في RISC-V أن حلاً واحداً لا يناسب جميع الاستخدامات: فامتداد صغير قد يقلل الطاقة، بينما توفر مجموعة أكبر من السجلات والعمليات والمراكم إنتاجية أعلى، لكن على حساب مساحة القالب واستهلاك الطاقة. ويعتمد الاختيار في النهاية على طريقة توزيع الأنوية والمسرّعات والحمل المستهدف. ويخلص التحليل إلى أن الطريق نحو التكامل الرأسي ما زال بعيداً عن الاكتمال، لكنه أصبح اتجاهاً ضرورياً لمواءمة التصميم مع البرمجيات والطاقة والأداء في الأنظمة الحديثة.

من نفس التصنيف

مقالات قد تهمك

عرض جميع المقالات