डिजिटल सर्किट का सत्यापन। सिंहावलोकन

मैं डिजिटल सर्किट के सत्यापन के बारे में सामान्य रूप से बात करने की कोशिश करूंगा।

इस क्षेत्र में सत्यापन एक महत्वपूर्ण प्रक्रिया है जिसमें अनुभवी इंजीनियरों की भागीदारी की आवश्यकता होती है। उदाहरण के लिए, एक नियम के रूप में सीपीयू के साथ सिस्टम पर काम करने वाला एक सत्यापन विशेषज्ञ, भाषाओं और कमांड शेल भाषाओं (Tcl, bash, Makefile, आदि), प्रोग्रामिंग भाषाओं (C, C ++, कोडांतरक), HDL / HDVL का मालिक होना चाहिए। (SystemVerilog [10, परिशिष्ट C - भाषा का इतिहास] [11], वेरिलोग, VHDL), आधुनिक कार्यप्रणाली और रूपरेखा (UVM)।

सत्यापन पर खर्च किए गए समय का अनुपात कुल परियोजना समय के 70-80% तक पहुंच जाता है। इस तरह के ध्यान का एक मुख्य कारण यह है कि आप चिप को "पैच" जारी नहीं कर सकते हैं क्योंकि इसे उत्पादन में डाल दिया गया है, आप केवल "सिलिकॉन इरेटा" जारी कर सकते हैं (यह FPGA / FPGA परियोजनाओं पर लागू नहीं होता है)।

डिजिटल सर्किट से मेरा मतलब है:

• जटिल कार्यात्मक ब्लॉक / बौद्धिक गुण (SFB / IP);
• अनुप्रयोग-विशिष्ट एकीकृत सर्किट (ASIC) कस्टम चिप्स
• प्रोग्रामेबल लॉजिक इंटीग्रेटेड सर्किट / फील्ड-प्रोग्रामेबल गेट एरे (FPGA);
• चिप / सिस्टम-ऑन-क्रिस्टल (SoC / SoC) पर सिस्टम;
• आदि

वास्तविक सत्यापन समस्याएं

सत्यापन के क्षेत्र में वर्तमान स्थिति और रुझानों को निम्नलिखित चुनौतियों और समस्याओं से आंका जा सकता है जो इसका सामना करती हैं [6]:

• सत्यापन ऑब्जेक्ट (OB) का आकार लगातार बढ़ रहा है। यहां तक ​​कि एक छोटा सा माइक्रोकंट्रोलर प्रकार आईसी दर्जनों सबमॉड्यूल का एक सेट है, बहुत जटिल कार्यक्षमता के साथ। बड़े आईसी जटिल होते हैं जिनमें करोड़ों-अरबों ट्रांजिस्टर हो सकते हैं, और अकेले शक्ति प्रबंधन योजना जटिलता में कुछ प्रोसेसर से अधिक हो सकती है [8];
• परियोजना की शुरुआत में आईएमएस के लिए एक विनिर्देश तैयार करना असंभव है और केवल भविष्य में इसका पालन करें, यह लगातार विकास प्रक्रिया में बदलता रहता है (ग्राहक आवश्यकताओं को बदलता है, तकनीकी समस्याएं या अधिक इष्टतम समाधान की खोज हमें दृष्टिकोणों पर पुनर्विचार करने के लिए मजबूर करती है, आदि)। इसके आधार पर, सभी प्रक्रियाओं को विनिर्देश परिवर्तनों की गतिशीलता का अनुभव करना चाहिए और आवश्यकताओं के अनुसार संशोधित किया जाना चाहिए;
• अक्सर, कई टीमें परियोजना सत्यापन पर एक दूसरे से काम करती हैं, जिनमें से संख्या दसियों लोगों तक पहुंच सकती है;
• व्यक्तिगत परीक्षणों की संख्या और उनके प्रकार एक बड़ी संख्या तक पहुँचते हैं, उनके परिणामों को एकत्र और विश्लेषण किया जाना चाहिए;
• मॉडलिंग भी डिजिटल सिस्टम कंप्यूटर समय की एक बहुत आवश्यकता है;
• परियोजना के लिए स्थापित तैयारियों के लक्ष्यों की पूर्णता काफी हद तक सत्यापन विशेषज्ञों की क्षमता और अंतर्ज्ञान पर निर्भर करती है;
• परीक्षणों (मेट्रिक्स) के साथ परियोजना कवरेज के संकेतकों के अस्तित्व के बावजूद, सत्यापन को पूरा करने का एकमात्र तरीका मुख्य रूप से निम्नलिखित निष्कर्षों के आधार पर, इसे निलंबित करने का निर्णय लेना है: परियोजना के चरण पर खर्च किए गए धन या समय को उत्पादन में लगाया जाना चाहिए, ऐसा लगता है कि वे 100 के कोड कवरेज तक पहुंच गए हैं %, हम एक सप्ताह से परीक्षण कर रहे हैं और इसमें कोई त्रुटि नहीं मिली है, आदि।

सत्यापन के प्रकार

डिजिटल सर्किट के सत्यापन को निम्नलिखित मुख्य प्रकारों में विभाजित किया जा सकता है:

1. कार्यात्मक (कार्यात्मक सत्यापन) - नाम खुद के लिए बोलता है, आप जांचते हैं कि क्या आपका सिस्टम अपने कार्यों को सही ढंग से कर रहा है;
2. औपचारिक सत्यापन - इस सत्यापन के साथ, डिज़ाइन मार्ग के विभिन्न चरणों में आपके सिस्टम के अभ्यावेदन की समानता या स्रोत कोड में दिए गए कथनों की पूर्ति स्थापित की जाती है:
   
   • समतुल्यता जाँच (उदाहरण के लिए RTL-to-RTL, RTL-to-Gate, Gate-to-Gate);
   • एसवीए (उदाहरण के लिए) का उपयोग करते हुए कोड में निर्दिष्ट संपत्ति की जांच (मॉडल चेकिंग) (गुणों की जांच)।
3. स्थैतिक कोड विश्लेषण - भाषा और इसके निर्माण के नियमों के अनुपालन के लिए औपचारिक मानदंडों के अनुसार स्रोत कोड की जाँच करना। बहुत बार, कॉन्फ़िगर किए गए सत्यापन नियम आरएमएम [4] को भेजे जाते हैं। ऐसे सत्यापन के कार्यक्रमों को आमतौर पर लिंट या लिंटर के रूप में संदर्भित किया जाता है;
4. भौतिक सत्यापन - मूल रूप से डीआरसी, एलवीएस, पीईआरसी आदि जांचों का तात्पर्य है, तकनीकी मानकों के अनुपालन के लिए प्रणाली के भौतिक प्रतिनिधित्व की जाँच की जाती है और भौतिक और तार्किक अभ्यावेदन आदि की अनुरूपता। चेकों की संरचना अत्यधिक प्रौद्योगिकी पर निर्भर है। आमतौर पर, भौतिक सत्यापन एक इंजीनियर या टोपोलॉजिकल डिज़ाइन टीम द्वारा किया जाता है।
5. प्रोटोटाइप - कार्यात्मक सत्यापन [18] के लिए FPGA का उपयोग।

सभी कार्यों के दायरे में कार्यात्मक सत्यापन सबसे महत्वपूर्ण है और प्रत्यक्ष मानव भागीदारी की आवश्यकता है।

स्टेटिक कोड विश्लेषण के लिए केवल प्रारंभिक उपकरणों के विन्यास की आवश्यकता होती है, जो कंपनी द्वारा अपनाए गए आंतरिक डिजाइन नियमों से मेल खाती है, फिर उपकरण इस तथ्य में संलग्न है कि यह डेवलपर्स को "मूल्यवान मार्गदर्शन" प्रदान करता है और निरंतर पर्यवेक्षण की आवश्यकता नहीं होती है।

औपचारिक सत्यापन उपकरण अक्सर बहुत स्वतंत्र होते हैं, इसके लिए केवल उन रिपोर्टों के सावधानीपूर्वक विश्लेषण की आवश्यकता होती है जो वे उत्पन्न करते हैं। वे रिवर्स इंजीनियरिंग के लिए भी उपयुक्त हैं, जब किसी कारण से आप जानते हैं कि आपको सर्किट की सूची से कोड को पुनर्स्थापित करना होगा।

सत्यापन उपकरण उदाहरण

डिजिटल सर्किट सत्यापन उपकरण (डिजिटल-ऑन-टॉप रूट) के उदाहरण:

• सत्यापन प्रबंधन उपकरण
  
  • मेंटर ग्राफिक्स - क्वेस्ट वेरिफिकेशन मैनेजमेंट
  • ताल - vManager
  • सिनोप्सिस - वर्डी, वीसी एक्ज़ीक्यूशन मैनेजर ("एक्सकेमन")
• कार्यात्मक - आमतौर पर सिमुलेटर
  
  • Mentor ग्राफिक्स - ModelSim, QuestaSim
  • ताल - गुप्त, Xcelium
  • Synopsys - वीसीएस
  • स्वतंत्र डेवलपर्स से मुफ्त सॉफ्टवेयर - सिमुलेटर वेरीलेटर, इकारस [5]
• औपचारिक
  
  • मेंटर ग्राफिक्स - फॉर्मल प्रो, क्वेस्टा फॉर्मल वेरिफिकेशन
  • ताल - जैस्परगॉल्ड, कॉनफ़ॉर्मल LEC, इनसिक्टिव फॉर्मल वेरिफिकेशन प्लेटफ़ॉर्म
  • सिनोप्सिस - औपचारिकता, वीसी औपचारिक
• स्थैतिक कोड विश्लेषण
  
  • मेंटर ग्राफिक्स - क्वेस्टा ऑटोचेक
  • ताल - एचएएल, जैस्परगोल्ड
  • Synopsys - स्पाईग्लास लिंट
• भौतिक सत्यापन
  
  • मेंटर ग्राफिक्स - कैलिबर
  • ताल - पेगासस, भौतिक सत्यापन प्रणाली,
  • सिनोप्सिस - हरक्यूलिस, आईसी वैलिडेटर

कार्यात्मक सत्यापन के तरीके

कार्यात्मक सत्यापन - परीक्षणों का एक सेट है, मैं सशर्त रूप से खुद को तीन समूहों में विभाजित करने की अनुमति दूंगा (यह एक हठधर्मिता नहीं है, यह व्यक्तिगत अनुभव से है):

1. सकारात्मक शाखाएं - सामान्य स्थितियों में व्यवहार का सत्यापन, उपकरण या मानक के लिए विनिर्देश द्वारा विनियमित, आदि। यानी हम स्थितियों की जांच करते हैं जब सब कुछ ठीक चल रहा होता है।
2. नकारात्मक शाखाएं - मानक स्थितियों से विचलन की जांच करना, लेकिन एक विनिर्देश या मानक के ढांचे के भीतर, उदाहरण के लिए - चेकसम का एक बेमेल, प्राप्त डेटा की संख्या, आदि। यानी जब कुछ गलत होता है, लेकिन हम जानते थे कि यह हो सकता है और हम जानते हैं कि इस स्थिति में कैसे काम करना है।
3. गैर-मानक परिस्थितियां - संचार प्रोटोकॉल के उल्लंघन से किसी भी यादृच्छिक स्थिति, डेटा का क्रम, इंटरफेस में भौतिक टकराव, तर्क तत्वों की स्थिति में यादृच्छिक परिवर्तन आदि। यानी यह तब है जब कुछ भी हो सकता है और आपको यह सुनिश्चित करने की आवश्यकता है कि ओबी इसके बाद काम करने की स्थिति में आएगा।

पहले दो चरणों को यूवीसी / वीआईपी (यूनिवर्सल वेरिफिकेशन कंपोनेंट / वेरिफिकेशन आईपी) का उपयोग करके स्वचालित किया जा सकता है और काफी जल्दी आप विभिन्न परीक्षणों की मात्रा बढ़ा सकते हैं, जिनमें स्वचालित रूप से उत्पन्न भी शामिल हैं। तीसरा चरण सत्यापन में एक "उत्कृष्ट कृति" है, इस चरण में एक असाधारण दृष्टिकोण और अनुभव की आवश्यकता होती है, क्योंकि इसे स्वचालित करना बहुत मुश्किल है, क्योंकि अधिकांश स्थितियां एक अलग एल्गोरिथ्म हैं, शायद सीएडी के लिए एक स्क्रिप्ट या "मैनुअल" चेक के लिए निर्देश।

कार्यात्मक सत्यापन मैट्रिक्स के प्रकार

मेट्रिक्स किसी परियोजना के परीक्षण कवरेज के संकेतक हैं। उन्हें यह समझने के लिए आवश्यक है कि संभावित स्थितियों को सत्यापित करने के लिए अन्य परीक्षणों को विकसित करने की आवश्यकता है और सत्यापन में कितना समय लग सकता है [16]।

दुर्भाग्य से, परियोजना के स्रोत कोड के आधार पर केवल एक प्रकार की मीट्रिक का मूल्यांकन किया जाता है, शेष प्रकारों के लिए मानदंड की परिभाषा बौद्धिक कार्य का परिणाम है।

इसके अलावा, यह याद रखना चाहिए कि एक प्रकार की मीट्रिक द्वारा वांछित संकेतकों की उपलब्धि का मतलब सामान्य रूप से व्यावहारिकता नहीं है, जटिल का मूल्यांकन करना हमेशा आवश्यक होता है।

मैट्रिक्स के प्रकार [3]:

• कार्यात्मक कोटिंग । दिखाता है कि ओबी फ़ंक्शन का कितना परीक्षण किया गया है। इस कवरेज के मानदंड परीक्षण योजना और परीक्षण वातावरण और / या ओएम में विशेष निर्माणों (कवरग्रुप [1]) की शुरूआत से निर्धारित किए जा सकते हैं, जो निगरानी करते हैं कि यह या उस कार्य / क्रिया को किया गया था या नहीं, क्या डेटा एक निश्चित तरीके से बदल गया है, आदि। स्रोत कोड में डिज़ाइन किए गए डिज़ाइन की जानकारी सीएडी द्वारा स्वचालित रूप से एकत्र की जा सकती है।
• कोड कवरेज - परीक्षण के दौरान स्रोत कोड निर्माण की स्थिति को बदलना। यह सीएडी द्वारा स्वचालित रूप से एकत्र किया जाता है, स्रोत कोड में किसी भी संरचना की शुरूआत की आवश्यकता नहीं होती है। उदाहरण के लिए:
  
  • स्विचिंग रजिस्टर (टॉगल कवरेज);
  • कोड की प्रत्येक पंक्ति की गतिविधि (लाइन कवरेज);
  • अभिव्यक्ति की गतिविधि (स्टेटमेंट कवरेज), वास्तव में - यह लाइन कवरेज है, लेकिन उन अभिव्यक्तियों को ट्रैक कर सकता है जो संपादक में एक से अधिक रेखाएं हैं;
  • एक सशर्त विवरण या प्रक्रिया (ब्लॉक कवरेज) के अंदर एक कोड खंड की गतिविधि, स्टेटमेंट कवरेज की भिन्नता;
  • सशर्त विवरणों की सभी शाखाओं की गतिविधि जैसे कि, केस, जबकि, दोहराएं, हमेशा के लिए, लूप (शाखा कवरेज);
  • घटक तार्किक अभिव्यक्तियों (अभिव्यक्ति कवरेज) के सभी राज्यों (सच्चे, झूठे) का परिवर्तन;
  • राज्य मशीन की स्थिति (परिमित-राज्य मशीन कवरेज)।
• दावे कवर । कथन विशेष भाषा निर्माण हैं जो विभिन्न घटनाओं और अनुक्रमों को ट्रैक करते हैं, और निर्दिष्ट मानदंडों के अनुसार उनकी घटना की वैधता निर्धारित करते हैं।

कार्यात्मक सत्यापन के तरीके

निर्देशित टेस्ट विधि (DTM)

प्रत्यक्ष, सार्थक परीक्षण। यदि इस पद्धति को परियोजना में अपनाया जाता है, तो सत्यापन योजना ब्याज के विशिष्ट बिंदुओं (राज्यों) पर कार्बनिक पदार्थों के व्यवहार की जांच करने के उद्देश्य से परीक्षणों से बना है। सभी संभावित स्थितियों की जाँच करना, विशेष रूप से जटिल परियोजनाओं में, लगभग असंभव है।
उसी समय, परीक्षण द्वारा कवर नहीं की जाने वाली स्थितियों में उत्पन्न होने वाली समस्याओं का पता नहीं लगाया जा सकता है इससे पहले कि डिवाइस को वास्तविक परिस्थितियों में उपयोग किया जाना शुरू हो। आमतौर पर, ये परीक्षण कार्यात्मक कवरेज मैट्रिक्स का उपयोग करते हैं।

कवरेज-ड्रिवेन वेरिफिकेशन, मेट्रिक-ड्रिवेन वेरिफिकेशन (CDV, MDV) [17]

कार्बनिक पदार्थों की एक निश्चित "परीक्षण कवरेज" प्राप्त करने के उद्देश्य से परीक्षण बनाने की अवधारणा। वे यह समझने के लिए मीट्रिक पर भरोसा करते हैं कि परियोजना की तत्परता लक्ष्यों को प्राप्त करने के लिए सत्यापन योजना में क्या परीक्षण जोड़े जाने की आवश्यकता है।
सत्यापन योजना में और क्या देखने के लिए आपको कवरेज विश्लेषण उपकरणों का उपयोग करने की आवश्यकता है। वास्तव में, यदि हम DTM में सत्यापन योजना को समायोजित करना शुरू करते हैं, तो कम से कम "कोड कवरेज" पर भरोसा करते हैं, तो हम पहले ही मान सकते हैं कि हमने आसानी से DTM से CDV में स्विच कर लिया है।

विवश यादृच्छिक सत्यापन (CRV)

यादृच्छिक प्रभावों को प्रस्तुत करके सत्यापन। ये ओएम पर यादृच्छिक प्रभावों की पीढ़ी के साथ वास्तव में स्वचालित परीक्षण हैं, लेकिन एबीवी के साथ सहजीवन के बिना उनकी कल्पना करना मुश्किल है।
विधि पहली बार में बहुत महंगी है, क्योंकि साधनों को तैयार करने में लंबा समय लगता है। प्रारंभिक चरण की तैयारी पूरी होने के बाद, अलग-अलग प्रारंभिक डेटा के साथ बार-बार परीक्षण स्वचालित रूप से शुरू किया जा सकता है। यदि एक मुखर बेमेल का पता लगाया जाता है, तो विकास और सत्यापन टीम ने पाया त्रुटि का विश्लेषण करना शुरू कर देती है।
एक वास्तविक परियोजना में, कोई व्यक्ति केवल इस विधि तक ही सीमित नहीं रह सकता है, क्योंकि इस पद्धति का उपयोग करके, आप कोड कवरेज और स्टेटमेंट कवरेज एकत्र कर सकते हैं, और वे ओएस के सही संचालन के बारे में कुछ नहीं कह सकते हैं, अर्थात्। विनिर्देशों का अनुपालन। यह कार्यात्मक परीक्षणों के साथ पूरक होना चाहिए।
इस पद्धति को लागू करने के लिए आवश्यक है:

1. ओबी के स्रोत कोड और परीक्षण पर्यावरण के सभी महत्वपूर्ण बिंदुओं में "जोर" लागू करें;
2. उनके कार्यों के यादृच्छिक प्रभावों और परिदृश्यों के जनरेटर विकसित करने के लिए, अर्थात्। प्रभाव यादृच्छिक होते हैं, लेकिन सीमाएँ होती हैं (हमारे पास सब कुछ छांटने का समय नहीं है), दाखिल करने का क्रम आदि।

दावे के आधार पर सत्यापन [9] (एबीवी)

बयानों के साथ सत्यापन। शायद, यह एक स्वतंत्र विधि भी नहीं है, लेकिन उपरोक्त कुछ घटक या बुनियादी घटक है।

एबीवी के साथ एक महत्वपूर्ण मुद्दा यह है कि अभिकथनों को कैसे वितरित किया जाए, जो कि ओबी के स्रोत कोड में सबसे अच्छे रूप में रखे गए हैं, जो कि परीक्षण वातावरण में होने चाहिए।

यह तुरंत ध्यान दिया जाना चाहिए कि वेरिलॉग भाषा में इसके मानक में जोर नहीं है (वे मूल भाषा के निर्माणों का उपयोग करके बनाई जा सकती हैं, लेकिन सिंथेसाइज़र के लिए निर्देशों की आवश्यकता होती है ताकि यह उनके रूपांतरण के साथ व्यवहार न करें)। दावे केवल SystemVerilog मानक में दिखाई देते हैं, और वे मूल रूप से VHDL और ई भाषा मानक में भी थे।

मेरा सुझाव है कि आप अपने आप को विशेषज्ञों की सिफारिशों के साथ परिचित करें, जिसमें क्लिफर्ड कमिंग्स [एसवीए के बारे में लेख], उनके लेखन पर कार्यों के वितरण के साथ-साथ सत्यापन अकादमी वेबसाइट [13] पर एबीवी पर सामग्री भी शामिल है।

संदर्भ

1. IEEE एसटीडी 1800TM-2012। SystemVerilog के लिए IEEE मानक - एकीकृत हार्डवेयर डिज़ाइन, विशिष्टता और सत्यापन भाषा
2. क्लाइव मैक्सफील्ड। FPGA डिजाइन। वास्तुकला, उपकरण और विधियाँ। युवा लड़ाकू का कोर्स। आईएसबीएन 978-5-94120-147-1 (आरयूएस), आईएसबीएन 0-7506-7604-3 (इंग्लैंड)
3. सत्यापन अकादमी। कवरेज कुकबुक। प्रो परीक्षण कवरेज
4. माइकल कीटिंग, पियरे ब्रिकॉड। सिस्टम-ऑन-ए-चिप डिजाइन के लिए पुन: उपयोग पद्धति। आईएसबीएन 1-4020-7141-8, ईबुक आईएसबीएन 0-306-47640-1 प्रिंट करें
5. लाइसेंस प्राप्त और स्वतंत्र रूप से वितरित सीएडी की सूची
6. मेंटर ग्राफिक्स। वर्तमान स्थिति और सत्यापन के दायरे पर आंकड़ों का एक उदाहरण
7. WikiChip। चिप्स विकिपीडिया
8. विकिपीडिया। आईसी में ट्रांजिस्टर की संख्या पर सामान्यीकृत डेटा
9. हैरी फोस्टर, एडम क्रोलनिक, डेविड लेसी। अभिकथन-आधारित डिज़ाइन।प्रीति आईएसबीएन 1-4020-8027-1, ईबुक आईएसबीएन 1-4020-8028-एक्स
10. स्टुअर्ट सदरलैंड, साइमन डेविडमैन, पीटर फ्लेक। डिज़ाइन के लिए SystemVerilog। आईएसबीएन -10: 0-387-33399-1, ईबुक आईएसबीएन -10: 0-387-36495-1 प्रिंट करें
11. क्रिस स्पीयर, ग्रेग तुम्बुश। सत्यापन के लिए SystemVerilog। आईएसबीएन प्रिंट करें: 978-1-4614-0714-0, ईबुक आईएसबीएन: 978-1-4614-0715-7
12. सनबर्स्ट डिज़ाइन। पत्रों
13. सत्यापन अकादमी। एबीवी पाठ्यक्रम
14. Doulos। ऑन लाइन और संदर्भ पुस्तकों में उपयोगी सामग्री
15. प्रकाश रशिंकर, पीटर पैटरसन, लीना सिंह। सिस्टम-ऑन-ए चिप सत्यापन। कार्यप्रणाली और तकनीक। आईएसबीएन प्रिंट करें: 0-792-37279-4, ईबुक आईएसबीएन: 0-306-46995-2
16. सत्यापन अकादमी। एसओसी सत्यापन में मेट्रिक्स
17. Doulos। कवरेज-संचालित सत्यापन पद्धति
18. डौग अमोस, ऑस्टिन लेसा, रेने रिक्टर। FPGA- आधारित प्रोटोटाइप कार्यप्रणाली मैनुअल: डिज़ाइन-फॉर-प्रोटोटाइपिंग (FPMM) में सर्वोत्तम प्रथाएँ। आईएसबीएन प्रिंट करें: 978-1617300042 Synopsys वेबसाइट से मुफ्त में डाउनलोड करें