منهجية التحقق الشاملة  منهجية التحقق الشاملة (UVM) هي منهجية موحدة للتحقق من تصميمات الدوائر المتكاملة . يتم اشتقاق منهجية التحقق الشاملة بشكل أساسي من OVM ( منهجية التحقق المفتوح ) والتي كانت ، إلى حد كبير ، تعتمد على eRM (منهجية إعادة الاستخدام الإلكترونية) للغة التحقق الإلكترونية التي طورتها شركة فيريسيتي في عام 2001.  توفر مكتبة قوالب منهجية التحقق الشاملة الكثير من الأتمتة للغة سيستم فيريلوج مثل المتتابعات وميزات أتمتة البيانات (التعبئة والنسخ والمقارنة) وما إلى ذلك ، وعلى عكس المنهجيات السابقة التي تم تطويرها بشكل مستقل من قبل كل شركة من شركات التصميم الالكتروني الآلي ، فهي معيار مُقدم من أكسيليرا بدعم من بائعين متعددين: منتور وكيدنس وسينوبسيس وزايلنكس وألديك  في ديسمبر 2009 ، صوتت لجنة فرعية فنية تابعة لشركة أكسيليرا — وهي منظمة معايير في صناعة التصميم الإلكتروني الآلي — لتأسيس منهجية التحقق الشاملة وقررت أن تبني هذا المعيار الجديد على منهجية التحقق المفتوح (OVM-2.1.1) ، منهجية تحقق تم تطويرها بشكل مشترك في عام 2007 بواسطة كيدانس و منتور .  في 21 فبراير 2011 ، وافقت أكسيليرا على الإصدار 1.0 من المنهجية الشاملة الذي يتضمن دليلًا مرجعيًا وتطبيقًا مرجعيًا في شكل مكتبة قوالب أساسية مبنية على لغة سيستم فيريليوج ودليل مستخدم.   المصنع هو مفهوم شائع الاستخدام في البرمجة كائنية التوجه. إنه كائن يتم استخدامه لإنشاء كائنات أخرى. هناك طريقتان لتسجيل كائن في المصنع. في إعلان الصنف A ، يمكن استدعاء وحدات ماكرو التسجيل `` uvm_object_utils (A) أو `uvm_component_utils (A). بخلاف ذلك ، يمكن استخدام وحدات الماكرو `uvm_object_registry (A، B) أو` uvm_component_registry (A، B) لتعيين سلسلة B إلى صنف من النوع A. يوفر مصنع UVM مجموعة متنوعة من طرق الإنشاء التي تسمح للمستخدم إنشاء كائن باسم مثيل معين ونوع مسجل.   المتتابع مسؤول عن ثلاث وظائف رئيسية:   في هذه المرحلة ، يجب ضبط التصميم قيد الاختبار والبيئة الموجودة فيه على الظروف المرغوبة قبل المحاكاة. من المحتمل أن يشمل ذلك:   يمكن تنفيذ لوحة النتائج بطرق مختلفة. بشكل عام ، تأخذ لوحة النتائج المدخلات إلى التصميم والمخرجات منه ، وتحدد ما يجب أن تكون عليه علاقة المدخلات والمخرجات ، وتحكم على ما إذا كانت تلتزم بالمواصفات. غالبًا ما يتم تحديد علاقة الإدخال والمخرج هذه بواسطة نموذج يسمى المتنبئ. يمكن تنفيذ المتنبئ بلغة برمجة عالية المستوى ، مثل SystemC.  يتم تنفيذ فئات لوحة النتائج UVM كفئة فرعية من فئة uvm_scoreboard ، والتي تعد في حد ذاتها فئة فرعية من uvm_component.  يحتوي فئة uvm_scoreboard فقط على دالة واحدة ، وهي طريقة المُنشئ "new". يتم تحديد بقية التنفيذ من قبل المستخدم.  في الدارات المتكاملة الحديثة ، قد يحتوي التصميم على واجهات متعددة. قد تحتوي كل من هذه الواجهات على كائنات مختلفة مرتبطة بها. على سبيل المثال ، إذا كانت التصميم عبارة عن رقاقة كاملة ، فقد تكون هناك واجهات منفصلة لـ PCI و Ethernet ومواثيق الاتصال الأخرى. ستكون شاشة النتائج والمراقب لواجهة PCI مختلفة عن تلك الخاصة بواجهة Ethernet. يمكن تنظيم الكائنات المختلفة كأعضاء في قالب تعرف باسم وكيل. سوف تقوم الوكلاء الخاملة فقط بتحليل قيم منفذ الواجهة ويجب أن تحتوي على مراقب. الوكلاء النشطة ستسيِّر المنافذ ويجب أن تحتوي على مسيِّر، ربما بالإضافة إلى مراقب.   يتم تنفيذ فئات الوكلاء كفئة فرعية من فئة uvm_agent ، والتي تعد في حد ذاتها فئة فرعية من uvm_component. مثل uvm_scoreboard ، فإن uvm_agent قليل الدوال. دالته الوحيدة هي المُنشئ "new" ودالة "get_is_active". إذا تم استخدام الوكيل لتسيير المنافذ ، فإن get_is_active ترجع UVM_ACTIVE. وإلا ، فإن get_is_active ترجع إلى UVM_PASSIVE.  يتم وصف المتتابعات للاختبار بشكل تجريدي. على سبيل المثال ، إذا كان التصميم عبارة عن سجل (مجموعة من المسجلات) ، فقد يحتوي على منافذ لعنوان قراءة وعنوان كتابة. قد يحتوي كائن المتتابعة على متغيرات لعنوان القراءة وعنوان الكتابة. ومع ذلك ، يجب أن تصبح هذه القيم في النهاية بتات عند منافذ الإدخال إلى التصميم. قد يكون هناك أيضًا ترميز غريب يستخدم عند توفير المدخلات إلى التصميم الذي يجب استخراجه من بقية عناصر الوكيل. تتمثل مسؤولية المحرك في أخذ المتتابعات هذه وتوفير الحث المناسب لمنافذ التصميم.  يتم تنفيذ فئات المحرك كفئة فرعية من فئة uvm_driver ، والتي تعد في حد ذاتها فئة فرعية من فئة uvm_component.   يسمح UVM باستخدام وحدات الماكرو