Intel Keynote عن رسمي تمهيدي للعقل

Intel Keynote عن رسمي تمهيدي للعقل

عقدة المصدر: 2528571

نشرت شركة Synopsys على موقع SolvNet محاضرة رائعة ألقاها الدكتور ثيو درين من شركة Intel Graphics. الموضوع هو التحقق من معادلة مسار البيانات. قد يبدو الأمر وكأنه مجرد تأييد رسمي آخر لـ Synopsys VC ولكن يجب عليك مشاهدته على أي حال. هذه مناقشة توسع العقل حول الاستخدامات والاعتبارات الرسمية والتي ستأخذك إلى ما هو أبعد من نوع دليل المستخدم الروتيني إلى منطقة أكثر روعة.

إنتل الكلمة الرئيسية على الرسمي

الفهم الفكري مقابل اختبار العينة

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

يشجعك Formal على فهم الوظيفة على مستوى عميق (على الأقل إذا كنت تريد تقديم نتيجة قيمة). في المثال أعلاه، فشل سؤال بسيط - هل يمكن أن تكون z جميعها 1 - في توضيح مثال في مليار دورة على جهاز محاكاة. ليس من المستغرب، لأن هذه حالة زاوية متطرفة. يقدم الاختبار الرسمي مثالاً محددًا وغير واضح للغاية في 188 ثانية، ويمكن أن يثبت أن هذه هي الحالة الوحيدة من نوعها في وقت أقل قليلاً.

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

قضايا المواصفات

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

رسمي كآلة بيع الأخطاء

تأتي مقارنة المواصفات بين لغة C وRTL مع مخاطر أخرى، خاصة فيما يتعلق بعرض البتات. يعد اقتطاع أو فقدان البت المحمول في الإشارة المتوسطة (رقم 3 أعلاه) من الأمثلة الجيدة. هل هذه مشاكل المواصفات؟ ربما منطقة رمادية بين المواصفات وخيارات التنفيذ.

أبعد من التحقق من التكافؤ

يبدو أن الغرض الأساسي من DPV هو التحقق من التكافؤ بين مرجع C أو RTL وتنفيذ RTL. لكن هذه الحاجة نادرة نسبيًا، وهناك طرق أخرى مفيدة يمكن من خلالها تطبيق مثل هذه التكنولوجيا، ولو بطريقة خارجة عن المألوف. في البداية، كان الأمر كلاسيكيًا في عالم التنفيذ - لقد أجريت تغييرًا وأصلحت خطأً ما - هل أدخلت أي أخطاء جديدة نتيجة لذلك؟ يشبه إلى حد ما التحقق من SEQ بعد إضافة بوابة الساعة. قد يكون تحليل إمكانية الوصول في مخرجات الكتلة تطبيقًا مفيدًا آخر في بعض الحالات.

ليس فقط التحقق من التكافؤ

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

لف

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

كلام مؤثر جداً، يستحق المشاهدة هنا على سولفنت!

شارك هذا المنشور عبر:

الطابع الزمني:

اكثر من سيميويكي