تجارب مع التطوير القائم على الاختبار (TDD) لتصميم المنطق (الرقاقة) في Verilog أو VHDL

Question

لقد بحثت على الويب ويبدو أن المناقشات/الأمثلة مخصصة لتطوير البرامج التقليدية.منذ Verilog وVHDL (المستخدمين لتصميم الرقائق، على سبيل المثال.FPGAs وASICs) تشبه تطوير البرمجيات C وC++، ويبدو أنها منطقية.ومع ذلك، لديهم بعض الاختلافات كونها متوازية بشكل أساسي وتتطلب أجهزة للاختبار الكامل.

ما هي التجارب، الجيدة والسيئة، التي مررت بها؟هل هناك أي روابط يمكنك اقتراحها على هذا التطبيق المحدد؟

التعديلات/التوضيحات:28/10/09:أنا أسأل بشكل خاص عن TDD.أنا على دراية بعمل مقاعد الاختبار، بما في ذلك مقاعد الفحص الذاتي.أدرك أيضًا أن SystemVerilog لديه بعض الميزات الخاصة لمقاعد الاختبار.

28/10/09:تتضمن الأسئلة المتضمنة 1) كتابة اختبار لأي وظيفة، وعدم استخدام الأشكال الموجية مطلقًا للمحاكاة و2) كتابة الاختبار/مقاعد الاختبار أولاً.

29/11/09:في تظهر الدراسات التجريبية أن التطوير القائم على الاختبار يحسن الجودة أبلغوا عن (برنامج) TDD "انخفضت كثافة عيوب ما قبل الإصدار للمنتجات الأربعة، والتي تم قياسها على أنها عيوب لكل ألف سطر من التعليمات البرمجية، بنسبة تتراوح بين 40% و90% مقارنة بالمشاريع التي لم تستخدم TDD.أبلغت إدارة الفرق بشكل شخصي عن زيادة بنسبة 15-35% في وقت التطوير الأولي للفرق التي تستخدم TDD، على الرغم من أن الفرق اتفقت على أن هذا يقابله انخفاض تكاليف الصيانة. تأثير الجدول الزمني المعتدل. هذا لديه أيضا بعض البيانات.

29/11/09:أنا أقوم بشكل أساسي بتنفيذ كود التحكم ومسار البيانات، وليس كود DSP.بالنسبة لمعالج الإشارة الرقمية (DSP)، يتضمن الحل النموذجي محاكاة ماتلاب دقيقة للبت.

03/02/10:ميزة TDD هي التأكد من فشل الاختبار أولاً.أفترض أن هذا يمكن أن يتم مع التأكيدات أيضا.

Answer 1

وأنا أكتب رمز لشرائح (FPGA)، وليس ASICS ... ولكن TDD هو بلدي لا يزال توجهي المفضل. أحب أن يكون مجموعة كاملة من الاختبارات لكافة التعليمات البرمجية وظيفية وأنا أكتب، وأنا أحاول (وليس دائما بنجاح) لكتابة testcode أولا. يحدق في الطول الموجي يحدث دائما في مرحلة ما عندما كنت التصحيح، ولكنها ليست وسيلة جيدة للتأكد من صحة التعليمات البرمجية (IMHO).

ونظرا لصعوبة إجراء اختبارات المناسبة في الأجهزة الحقيقية (تحفيز الحالات الزاوية هو بشكل خاص)، وحقيقة أن VHDL-ترجمة يأخذ ثانية (مقابل و"لأجهزة" تجميع التي تأخذ عدة دقائق (أو حتى ساعات)) ، وأنا لا أرى كيف يمكن لأي شخص أن تعمل أي وسيلة أخرى!

وأنا أيضا بناء التأكيدات إلى RTL كما أكتبه للقبض على الأشياء وأنا أعلم لا ينبغي أن يحدث من أي وقت مضى. Apparantly هذا يعتبر قليلا "غريب"، وهناك تصور بأن المهندسين التحقق إرسال تأكيدات والمصممين RTL لا. ولكن في الغالب أنا بلدي التحقق مهندس، لذلك ربما لهذا السبب!

Answer 2

أنا أستعمل وحدة V للتطوير القائم على الاختبار باستخدام VHDL.

VUnit هي مكتبة Python التي تستدعي مترجم VHDL ومحاكيه وتقرأ نتائج المحاكاة.كما أنه يوفر العديد من مكتبات VHDL الرائعة التي تجعل من السهل جدًا كتابة مقاعد اختبار أفضل، مثل مكتبة الاتصالات, مكتبة التسجيل و أ مكتبة التحقق.

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

يبدو أن VUnit نشط للغاية وقد تمكنت عدة مرات من طرح الأسئلة مباشرة على المطورين وحصلت على المساعدة بسرعة كبيرة.

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

Answer 3

تتضمن ملحقات SystemVerilog لمعيار IEEE Verilog مجموعة متنوعة من التركيبات التي تسهل إنشاء مجموعات اختبار شاملة للتحقق من التصاميم المنطقية الرقمية المعقدة.SystemVerilog هو واحد من لغات التحقق من الأجهزة (HVL) التي تستخدم للتحقق من شريحة ASIC التصاميم عبر المحاكاة (على عكس المحاكاة أو استخدام FPGA).

تتمثل المزايا المهمة مقارنة بلغة تصميم الأجهزة التقليدية (Verilog) في ما يلي:

• العشوائية المقيدة
• التأكيدات
• التجميع التلقائي لبيانات التغطية الوظيفية والتأكيد

المفتاح هو الوصول إلى برامج المحاكاة التي تدعم هذا المعيار الأخير (2005).لا تدعم جميع أجهزة المحاكاة بشكل كامل الميزات الأكثر تقدما.

بالإضافة إلى معيار IEEE ، هناك مكتبة SystemVerilog مفتوحة المصدر من مكونات التحقق المتاحة من VMM Central (http://www.vmmcentral.com).يوفر إطارًا معقولًا لإنشاء بيئة اختبار.

يمكنك أيضا إجراء المزيد من الأبحاث حول الموضوع من خلال البحث في ملف منتدى نقابة التحقق.

SystemVerilog ليست مكتبة HVL الوحيدة، كما أن VMM ليست المكتبة الوحيدة.ولكني أنصح بكلا الأمرين لو لديك حق الوصول إلى المناسب ادوات.لقد وجدت أن هذه منهجية فعالة في العثور على التصميم البق قبل تصبح السيليكون.

Answer 4

وأنا لا أعرف الكثير عن تصميم الأجهزة / رقاقة، ولكن أنا عميقا في TDD، حتى أستطيع أن ما لا يقل عن مناقشة ملاءمة عملية معك.

والسؤال أسميه الأكثر المناسب هو: كيف يمكن بسرعة الاختبارات الخاصة بك تعطيك ردود الفعل على التصميم؟ تتعلق بما يلي: كيف بسرعة يمكنك إضافة اختبارات جديدة؟ وكيف بئر زمزم (بنية تغيير دون تغيير السلوك) أدوات دعم إعادة الهيكلية من التصميم الخاص بك؟

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

Answer 5

وفيما يتعلق أدوات إعادة الهيكلية للغات الأجهزة، أود أن أشير لك أداة لدينا Sigasi HDT . يوفر Sigasi على IDE مع محلل وVHDL refactorings المدمج في VHDL.

وفيليب فايس، Sigasi

Answer 6

ANVIL - آخر فيريلوج محادثات التفاعل طبقة حول هذه بعض. لم أحاول ذلك.

Answer 7

وحاولت أبدا بنشاط TDD على تصميم RTL، ولكن كان لي أفكاري في هذا الشأن.

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

ولكن أود أن لا تعتمد كليا على تأكيدات، وهذا يمكن أن تصبح شعر جدا.

وربما يمكنك التعبير عن أفكارك حول هذا أيضا، كما كنت تطلب منه ذلك اعتقد انك تحمل بعض الأفكار في رأسك؟

Answer 8

ما هو TDD بالنسبة لك؟ هل يعني وجود كل ما تبذلونه من الشفرة عن طريق اختبارات التلقائي تمارس في جميع الأوقات، أو هل تذهب أبعد من ذلك على أنه يعني أن اختبارات مكتوبة قبل رمز وكتابة أية القانون الجديد إلا إذا فشلت الاختبارات؟

وأيا كان النهج الذي تفضله، اختبار كود HDL هو لا يختلف كثيرا عن اختبار البرمجيات. لها إيجابياتها (تغطية أفضل بكثير وعمق الاختبار) وسلبيات (من الصعب اقامة ومرهقة نسبيا البرمجيات).

ولقد كان تجربة جيدة جدا مع استخدام بيثون والمتعاملين HDL عام لتنفيذ اختبارات شاملة وتلقائية لوحدات HDL synthesizable. والفكرة هي تشبه إلى حد ما ما يانيك بيرجيرون يعرض في كتبه، ولكن بدلا من SystemVerilog، يستخدم بيثون ل (1) إنشاء رمز VHDL من سيناريوهات اختبار مكتوبة في بيثون و (2) التحقق من النتائج كتبه المتعاملين الرصد التي تقبل الطول الموجي من خلال تصميم والمحاكاة.

وهناك أكثر من ذلك بكثير أن تكون مكتوبة حول هذه التقنية، ولكن لست متأكدا ما تريد التركيز عليها.