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

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

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

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

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

أحد هذه المجالات هو تحليل الطاقة. لقد كنت أكتب قصصًا عن مدى أهمية القوة والطاقة، وربما تصبح قريبًا هي المحدد للعديد من التصميمات الأكثر تعقيدًا. بعض الأسئلة التي أطرحها دائمًا هي:

• ما هي الأدوات التي يجري تطويرها للقيام بتحليل قوة البرمجيات؟
• كيف يمكنك حساب الطاقة المستهلكة لوظيفة معينة؟
• كيف يمكن للمستخدمين تحسين التصميم للطاقة أو الطاقة؟

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

لقد بدأت أعتقد أنني كنت أنبح الشجرة الخطأ وربما لم تكن هذه مخاوف مشروعة. تمت استعادة صحتي العقلية من خلال تعليق على إحدى قصصي الأخيرة المتعلقة بالطاقة. كتب ألان كانتل، قائد المشروع الفرعي لـ OCP HPC في Open Compute Project Foundation: "على الرغم من أنه من الرائع رؤية مقالات مثل هذه تسلط الضوء على حاجتنا جميعًا إلى التركيز على الحوسبة التي تركز على الطاقة، إلا أن الخبر المحزن هو أن أدواتنا لا تقوم بالإبلاغ الطاقة بأي طريقة واضحة لإظهار الأخطاء المعمارية الغبية التي نرتكبها غالبًا من منظور استهلاك الطاقة. نحن نعمل على حل جميع المشاكل من منظور تصاعدي من خلال تقريب الأمور من بعضها البعض. وفي حين أن ذلك يحقق فوائد هائلة في مجال كفاءة استخدام الطاقة، فإنه يؤدي أيضًا إلى زيادة كثافة الطاقة بشكل كبير. هناك الكثير من الثمار القريبة من نهج هندسة النظام من أعلى إلى أسفل والتي تفتقدها الصناعة لأننا بحاجة إلى التفكير خارج الصندوق وعبر صوامعنا.

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

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

في دفاع جزئي عن شركات EDA، فإنها تواجه العديد من المشكلات الجديدة هذه الأيام لدرجة أنها منتشرة للغاية في التعامل مع العقد الجديدة، 2.5D، 3D، Shift Left، الفيزياء المتعددة، خوارزميات الذكاء الاصطناعي - على سبيل المثال لا الحصر. إنهم ينفقون بالفعل على البحث والتطوير أكثر من معظم شركات التكنولوجيا كنسبة مئوية من الإيرادات.

ربما تستطيع شركة Accellera البدء في تضمين منتديات المناقشة في أحداث مثل DVCon. وهذا من شأنه أن يسمح بإجراء مناقشة مفتوحة حول المشاكل التي يحتاجون إلى حلها. ربما يمكنهم البدء في إنتاج نسخة EDA المكافئة لخارطة طريق ITRS القديمة. من المؤكد أنه سيوفر الكثير من الوقت والطاقة (يقصد التورية).