هل يجب عليك إزالة جميع التحذيرات في تصميم Verilog أو VHDL؟ لما و لما لا؟

Question

في البرامج (العادية) ، عملت في الشركات التي يتم فيها استخدام خيار GCC -wall لإظهار جميع التحذيرات. ثم يحتاجون إلى التعامل معهم. مع تصميم FPGA/ASIC غير التافهة في Verilog أو VHDL ، غالبًا ما توجد العديد من التحذيرات. هل يجب أن تقلق بشأنهم جميعًا؟ هل لديك أي تقنيات محددة تقترحها؟ إن تدفق بلدي هو أساسا FPGAs (Altera و Xilinx على وجه الخصوص) ، لكنني أفترض أن نفس القواعد سوف تنطبق على تصميم ASIC ، وربما أكثر بسبب عدم القدرة على تغيير التصميم بعد بنائه.

تحديث 4/29/2010: كنت أفكر في الأصل في التحذيرات التوليف والتوليف (Place & Route) ، لكن تحذيرات المحاكاة صالحة أيضًا.

Answer 1

إليكم وجهة نظري من عالم ASIC (99 ٪ Verilog ، 1 ٪ VHDL).

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

نظرًا لوجود العديد من أنواع الأدوات التي يمكن أن تولد تحذيرات (محاكاة/تصحيح الأخطاء/linter/التوليف/التكافؤ ، وما إلى ذلك) ، سأركز هذه المناقشة على مترجم محاكاة تحذيرات.

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

استثناء من المنهجية أعلاه هو IP لجهات خارجية ، التي لا يُسمح لنا بتعديل رمز Verilog.

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

باختصار ، نبذل قصارى جهدنا للقضاء على التحذيرات ، لكن ليس من العملي دائمًا القيام بذلك.

Answer 2

هذا ما أفعله ، كمرجع. أقوم بفحص جميع ملفات السجل من الأدوات (الأدوات).

بالنسبة إلى Altera Quartus II الذي يتضمن تقارير الخريطة والملائمة والاندماج. أقوم أيضًا بتشغيل خيار فحص قاعدة التصميم (DRC) وتحقق من هذا الملف. بالنسبة لبعض الرسائل التي يسهل إصلاحها ، على سبيل المثال ، مفقود المنفذ من التثبيت أو العرض الثابت غير الصحيح ، أقوم بإصلاحها. آخرون أنا أنظر إليه. بالنسبة للأشخاص الموجودين في النوى ، على سبيل المثال عدم تطابق العرض لأنني لا أستخدم الإخراج الكامل المتعمد ، أميزها ليتم قمعها في ملف .srf. أنا فقط أقمع الرسائل المحددة ، وليس كل "الرسائل المماثلة" نظرًا لوجود آخرين ، إما الآن أو في المستقبل ، وهي مشاكل.

Answer 3

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

Answer 4

السبب الأكثر أهمية الذي يمكنني التفكير فيه هو عدم التوافق في التشكيل. تقوم أدوات التوليف بالكثير من التحسينات (كما ينبغي بحق) ، وإذا تركت ثغرات في التصميم الخاص بك ، فأنت تطلب المتاعب. ارجع إلى IEEE 1364.1-2002 للحصول على تفاصيل حول معيار التوليف.

Answer 5

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

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

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

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

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

Answer 6

من المتوقع بعض التحذيرات وهناك مشكلة إذا لم تحصل على تحذير.

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

لذلك لا ، أنت لا تريد دائمًا "التعامل" مع جميع التحذيرات.