सिलिकॉन बग, इरेटा शीट


27

कई (अधिकांश ??, सभी ??) माइक्रोकंट्रोलरों में जो मैंने पिछले वर्षों में उपयोग किया है, जहां कभी-कभी कुछ सिलिकॉन स्तर के कीड़े होते हैं, और निर्माता इरेटा शीट्स के साथ इंजीनियरों को प्रदान करते हैं, जो यह बताता है कि वे किस अप्रत्याशित व्यवहार का सामना कर सकते हैं।

वे कभी इन "बग" को ठीक क्यों नहीं करते हैं? चूंकि उत्पाद अभी भी उत्पादित है, और ज्यादातर मामलों में समस्या को हल करना पिछले कार्यान्वयन को प्रभावित नहीं करेगा, इसलिए वे इसे संशोधित नहीं करते हैं? कई मामलों में उत्पाद को स्थिर किया जा सकता है, अधिकांश कीड़े पाए जा सकते हैं, और इसके आगे इसके जीवन-काल का महत्वपूर्ण हिस्सा हो सकता है।

क्या यह इतना मुश्किल है (तकनीकी रूप से)? महंगा?


4
क्योंकि बग को ठीक करना कठिन हो सकता है।
इग्नासियो वाज़क्वेज़-अब्राम्स

कभी-कभी वे करते हैं।
ब्राह्मण

7
उन्हें सिलिकॉन उत्पादन के लिए मास्क का एक नया सेट बनाने की भी आवश्यकता होगी। मास्क प्रक्रिया के अधिक महंगे भागों में से एक हो सकता है।
टॉम कारपेंटर

@ IgnacioVazquez-Abrams कोई फिक्सिंग बग आसान नहीं है, उन्हें ढूंढना कठिन हिस्सा है, लेकिन उपरोक्त मामले में, वे पहले से ही कठिन हिस्से से गुजर चुके हैं ...
फॉटिस पनागिओतोपोलस

5
अनिच्छुक अनुकूलता। डेवलपर्स एक सिलिकॉन बग का शोषण कर सकते हैं चाहे वह होशपूर्वक हो या नहीं। दूसरे दिन इस विषय पर एक प्रश्न था, किसी को एक पुराना संस्करण नियंत्रक मिला और उसके कार्यक्रम ने काम करने से इनकार कर दिया । सावधानीपूर्वक जाँच के बाद ही यह पता चला कि उसके उपकरण के भाग संख्या में अतिरिक्त अनुगामी कमी थी A। यह दस्तावेज के रूप में निकला, लेकिन यह लोगों को भ्रमित करता है।
जिप्पी

जवाबों:


28

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

कीड़े को ठीक करना मुश्किल और महंगा है। यह सिर्फ RTL कोड की एक पंक्ति को नहीं बदल रहा है। यदि आपने ऐसा किया है, तो आपको भौतिक लेआउट को फिर से आकार देना होगा, किसी भी समय की समस्याओं को ठीक करने के लिए लेआउट को बदलना होगा, एक नया मास्क सेट खरीदना होगा, नई वेफर्स का उत्पादन करना होगा, वेफर्स का परीक्षण करना चाहिए (सामान्य रूप से), नए फिक्स को मान्य करें, और संभवत: उत्पाद को फिर से चिह्नित या अर्हता प्राप्त करता है। इसमें कई महीने लगते हैं और एक परेशान राशि खर्च होती है। उस कारण से, हम सीधे लेआउट में कीड़े को ठीक करने की कोशिश करते हैं (अधिमानतः एक धातु की परत पर)। यह RTL संश्लेषण से शुरू होने की तुलना में तेज़ और सस्ता है, लेकिन यह अभी भी अच्छा नहीं है।

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

आम तौर पर, बग जो छोड़ दिया जाता है, वे केवल अजीब विन्यास में होते हैं, बहुत छोटी समस्याएं पैदा करते हैं, आसान वर्कअराउंड या उपरोक्त सभी होते हैं। वे मुसीबत के लायक होने के लिए बस बुरे नहीं हैं। और यदि आप अगले उत्पाद पर एक हार्डवेयर मॉड्यूल का पुन: उपयोग करते हैं, तो आपके मौजूदा ग्राहकों के पास पहले से ही वैसे भी उनके सॉफ़्टवेयर में वर्कअराउंड होगा।

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

सॉफ्टवेयर भी ग्राहक की ओर से एक मुद्दा है। यदि आपका बगफिक्स किसी भी तरह से पश्चगामी संगतता को तोड़ता है, तो आपके सभी ग्राहकों को अपने कोड को अपडेट करना होगा, जो कि उनके पास अब तक उपकरण भी नहीं हो सकते हैं।

जैसा कि कोई व्यक्ति जो माइक्रोकंट्रोलर विकास में काम करता है, मैं आपको बता सकता हूं कि हम सभी को हर बग को ठीक करना पसंद करेंगे। लेकिन ऐसा करने की कोशिश करने से अप्रत्याशित रूप से विकास में देरी होगी, ग्राहकों को परेशान करना होगा, एक टन पैसा खर्च करना होगा, और यह सब खत्म होने पर भी हम शायद असफल रहेंगे।


1
+1, विशेष रूप से यह उल्लेख करने के लिए कि मौजूदा ग्राहकों के पास पहले से ही लागू किए गए वर्कअराउंड होंगे।
Null

13

यह आम तौर पर खर्च के कारण है।

जब आप बग को "ठीक" करते हैं तो हमेशा कुछ और टूटने का खतरा होता है। उस वजह से, निर्माता को आमतौर पर डिवाइस को पूरी तरह से पुन: अर्हता प्राप्त करने और फिर से चिह्नित करने की आवश्यकता होती है, यह सुनिश्चित करने के लिए कि "फिक्स" ने एक अलग (और शायद और भी अवांछनीय) बग पेश नहीं किया है। इसका मतलब है कि पैसा और समय (जो निर्माता के लिए भी पैसा है)। इसका मतलब यह भी है कि निर्माता के पास किसी नए उत्पाद को विकसित करने के बजाय एक मौजूदा उत्पाद को ठीक करना है।

संबंधित नोट पर, कभी-कभी ग्राहकों को यह सुनिश्चित करने के लिए अपने उत्पाद (उत्पादों) में निर्धारित डिवाइस की पुन: योग्यता की आवश्यकता होती है कि बग फिक्स उनके सिस्टम में कुछ भी नहीं तोड़ता है । उनके लिए पैसा और समय खर्च होता है, और ग्राहक उन लागतों को स्वीकार करने के लिए तैयार नहीं हो सकते हैं - वे अभी भी "छोटी गाड़ी" संस्करण की मांग करेंगे।

कुछ मामलों में, निश्चित रूप से, बग वास्तव में तकनीकी रूप से ठीक करना मुश्किल है। उस मामले में, इसे ठीक करना और भी महंगा है।


1
+1 यह हमेशा पैसे, और कुछ हद तक संसाधनों के बारे में रहा है। मास्क सस्ते नहीं हैं, बैकएंड सेवाएं सस्ती नहीं हैं आदि
कुछ हार्डवेयर गाइ


@ user2813274 xkcd कितना भयानक है।
नल

1
जब मैं ASIC पर एक कंपनी में काम कर रहा था (RTL में, लेआउट / बैकएंड में नहीं), तो मैंने सुना कि एक मुखौटा सेट की कीमत 3 मिलियन डॉलर हो सकती है। एक छोटी सी टीम / एसिक पर, मास्क का प्रत्येक नया सेट आपके एनआरई को आसानी से 10% बढ़ा सकता है । वैसे भी, कि मैं अपने 8 साल में चिप देव कर संख्याओं के लिए ballpack है 'वास्तव में मास्क सेट खरीदने में शामिल होने के बिना कभी शामिल नहीं हुआ।
रॉस रोजर्स

8

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

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

जबकि मैं समझ सकता हूं कि माइक्रोचिप UART बग की तरह कीड़े कैसे अंदर घुस सकते हैं, यह तय करना मुश्किल नहीं होना चाहिए: मुझे उम्मीद है कि माइक्रोचिप गैर-सिंक्रनाइज़ किए गए "ट्रांसमिशन पूर्ण" और "वर्ण लोड" के आधार पर एक "गो" सिग्नल उत्पन्न करता है। "सिग्नल, और परेशानी होती है यदि पूर्व सिग्नल ठीक बाद में बदल जाता है (जिससे TX बफर सर्किट किसी दिए गए चक्र पर वर्ण डेटा को लोड करने का मौका चूक जाता है, लेकिन TX सीक्वेंसर को उस चक्र पर एक नया प्रसारण शुरू करने की अनुमति देता है) ; भले ही माइक्रोचिप सामान्य मामलों में जहां ट्रांसमीटर खाली है और एक पात्र लोड किया गया है, या जहां एक चरित्र लोड होने के बाद ट्रांसमीटर खाली हो जाता है, में समकालिकता देरी को जोड़ना नहीं चाहता है, तो समस्या समय को प्रभावित किए बिना तय की जा सकती है उन मामलों मेंतीन नंद द्वार और दो तुल्यकालन कुंडी जोड़कर। हालाँकि, कई हिस्सों ने इस समस्या के प्रकाशित होने के बाद, बिना किसी सुधार के जोड़ दिया है।


5

यह वास्तव में कंपनी और फिक्स की जटिलता पर निर्भर करता है। उदाहरण के लिए, PIC18F23K22 के लिए यह इरेटा देखें । आप देख सकते हैं कि आठ ज्ञात कीड़े थे जो सिलिकॉन के पहले ("ए 1") संशोधन को प्रभावित करते थे।

इस उत्तर के समय, उनके पास एक "A2" संशोधन है। मूल आठ कीड़ों में से, तीन को इस नए संशोधन में सुधारा गया है।

एक अन्य निर्णायक कारक उत्पाद का विनिर्माण जीवनकाल है। यहां तक ​​कि अगर कोई निर्माता किसी मौजूदा हिस्से में एक विशेष समस्या को ठीक नहीं करने का विकल्प चुनता है, तो भी वे यह सुनिश्चित करके समस्या को "हल" कर सकते हैं कि नए उत्पादों में कीड़े नहीं हैं।


+1, विशेष रूप से उत्पाद के जीवनकाल का उल्लेख करने के लिए।
नल

4

हो सकता है कि वे बग का पता चलने पर हजारों या लाखों आईसीएस का उत्पादन (लेकिन अभी तक नहीं बेचा) कर चुके हों। बग के कारण वे उन्हें दूर नहीं फेंकते हैं।

मुझे लगता है कि आप इसकी तुलना पुस्तक छपाई से कर सकते हैं। थोड़े समय (दिन, सप्ताह) के भीतर एक बार में कई हजारों की संख्या में किताबें छपती हैं। लेकिन वे वर्षों या दशकों के भीतर बेचे जाते हैं। टाइपो या अन्य त्रुटि मिलते ही पुस्तकों को फेंक दिया जाता है और पुन: मुद्रित किया जाता है। इसके अलावा पुस्तकों के लिए इरेटा शीट मुद्रित और उपयोगकर्ता को सौंपी जाती हैं।

अगले संस्करण में ज्ञात बग (टाइपो, त्रुटियां) को रोका जाएगा।


हां, वही मैं बात कर रहा था। "अगले संस्करण" में फिक्सिंग ...
Fotis Panagiotopoulos

आईसी का उत्पादन लगातार नहीं किया जाता है, अर्थात वे उसी दर से नहीं बिकते हैं, जब वे बेचे जाते हैं। अगले संस्करण तक इसमें कुछ समय, शायद साल लग सकते हैं।
दही

वाह! साल? ... हालांकि कभी नहीं उनके बैच इतने बड़े हैं!
फोटीस पैनियागोटोपॉलोस

वास्तव में मुझे यकीन नहीं है कि अगर यह आम है कि एक उत्पादन रन से अगले तक वर्षों का समय लगता है, लेकिन निश्चित रूप से कई साल लग सकते हैं जब तक कि एक उत्पादन रन के सभी उत्पाद नहीं बिकते हैं। बेशक ग्राहक उन उत्पादों की त्रुटियों के बारे में सूचित करना चाहता है जिन्हें वह खरीदता है।
दही
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.