मैं कुछ तार्किक 1s के लिए डेटा लाइन पर एक अजीब "पायदान" क्यों देख रहा हूं?


15

मैं कुछ रेट्रोकोम्प्यूटिंग फ़न के लिए Z80 होमब्रेव कंप्यूटर बनाने और खुद को इलेक्ट्रॉनिक डिज़ाइन का आधार सिखाने का प्रयास कर रहा हूँ। प्रूफ-ऑफ-कॉन्सेप्ट के लिए, मैंने पहले से ही पिछले हफ्तों में ब्रेडबोर्ड पर एक बुनियादी प्रणाली को सफलतापूर्वक इकट्ठा कर लिया है।

वर्तमान प्रोटोटाइप बेहद सरल है। मैंने सिस्टम घड़ी के रूप में 74HCT04 पियर्स थरथरानवाला द्वारा संचालित एक 4 मेगाहर्ट्ज क्रिस्टल का इस्तेमाल किया, पारदर्शी मोड ( LEउच्च) में दो 74HCT573 लैचेस 16-बिट एड्रेस बस के लिए बफर के रूप में, विपरीत दिशाओं में एक और दो 74HCT573 द्वारा नियंत्रित RDऔर NOT RDएक द्विदिश डेटा के रूप में। बस बफर। मैंने सिस्टम बस में 100 ns AT28C256 EEPROM (केवल 16-KiB डिकोड किया गया है) और दो 150 ns 8-KiB SRAM चिप्स अटैच किए । मैंने CSसिग्नल उत्पन्न करने के लिए 74HCT42 का उपयोग किया और OEEEPROM को नीचा दिखाने के लिए , WEउच्च को EEPROM को नियंत्रित करने के लिए केवल एक CS सिग्नल छोड़ दिया।

ब्रेडबोर्ड पर सब कुछ शोर है, लेकिन हर चरण को पूरा करने के बाद सिस्टम पूरी तरह से चालू हो गया। अब यह EEPROM से निर्देश प्राप्त कर सकता है, / SRAM से डेटा को पढ़ और लिख सकता है, और इसमें एक और कुंडी 74HCT573 से बना एक सीरियल पोर्ट है, D0से जुड़ा है D0, LEहै (NOT (IOREQ NAND WR)), आउटपुट Q1दूसरे शब्दों में, केवल दूसरे आउटपुट पोर्ट से आता है तर्क को डिकोड किए बिना। मैंने CPU / RAM- गहन बेंचमार्क प्रोग्राम लिखा है और मेरा कंप्यूटर अपेक्षित परिणाम प्राप्त कर सकता है। मेमडंप्स ने यह भी दिखाया कि Z80 EEPROM से सभी बाइट्स को सही ढंग से पढ़ सकता है, इसलिए सब कुछ काम कर रहा है।

लेकिन जब मैंने D0डेटा बस के पिन की जांच करने की कोशिश की , तो मुझे कुछ स्पष्ट तार्किक 1 आउटपुट के लिए कुछ अजीब "notches" दिखाई दे रहे थे।

D0 पर अजीब सूचनाओं का एक उदाहरण

और ऐसा लगता है कि वे हमेशा कुछ तार्किक 1s के लिए प्रकट होते हैं, CSजब EEPROM का संकेत सक्रिय हो जाता है, उदाहरण के लिए, यहाँ नीले EEPROM CS सिग्नल पर सुपरपाइप किए गए अजीब पायदान पर कब्जा है।

एक अजीब पायदान सीएस संकेत पर आरोपित है

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

.org 0x00
    di

    xor a
loop:
    out (0x00), a
    inc a

    jp loop

लेकिन समस्या अपरिवर्तित है, अजीब "निशान" अभी भी हमेशा कुछ तार्किक 1s के लिए दिखाई देते हैं , बस MEMRQऔर / या (क्योंकि यह अनिवार्य रूप से एक-चिप अब है) CS(नीला) कम हो जाता है।

SRAM के सभी CS पिन उच्च हैं, इसलिए सिस्टम बहुत अधिक है जिसमें मेमोरी के रूप में केवल AT28C256 EEPROM चिप है, और आउटपुट पोर्ट के रूप में एक कुंडी है। सिस्टम में एक Dme अनुरोध के दौरान EEPROM को मक्खी पर रिप्रोग्राम करने के लिए Atmega328p से बनाया गया एक इन-सिस्टम प्रोग्रामर भी है, लेकिन मुझे नहीं लगता कि यह अपराधी है क्योंकि मैंने प्रोग्रामर के सभी डेटा और एड्रेस आउटपुट को अलग कर दिया है, और मैंने प्रोग्रामर को जोड़ने से पहले ही notches देखा है।

"पायदान" का एक और उदाहरण

तो "notches" एक opcode भ्रूण चक्र के दौरान बनाया जाना चाहिए। वे क्या हैं?

मेरे पास कुछ परिकल्पनाएं हैं:

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

    यदि यह सच है, तो क्या आप "notches" की प्रकृति की व्याख्या कर सकते हैं? क्या इस घटना का EE में नाम है? मैंने पहले कई ओवरशूट और रिंगिंग देखी हैं, लेकिन कभी "notches" नहीं देखा। और मैं इसे केवल कुछ तार्किक स्तरों के लिए क्यों देख रहा हूं ?

  2. समय। क्या यह संभव है कि EEPROM आउटपुट या अन्य लॉजिक सर्किट का एक छोटा "सेटल टाइम" बस पर इस अजीब प्रभाव का कारण बन रहा है?

  3. प्रशंसक बाहर। शायद लंबी बस में करंट बहुत ज्यादा होता है और इसकी कैपेसिटी बहुत ज्यादा होती है, इसलिए EEPROM आउटपुट में बस को चलाने में मुश्किल होती है? और शायद आस्टसीलस्कप जांच भी बस लोड कर रहा है?

  4. बस विवाद, या अन्य तर्क त्रुटियां जिनके कारण डेटा बस को खींचना पड़ता है। बेवजह मुझे लगता है? बस के अन्य घटक अलग-थलग हैं, और मैं यह देखने में विफल रहा कि एक AT28C256 EEPROM या एक कुंडी ऐसा कैसे कर सकती है। लेकिन मुझे लगता है कि ब्रेडबोर्ड में वायरिंग की त्रुटि या छिपे हुए आंतरिक शॉर्ट के कारण यह अभी भी संभव है।

अपडेट: मैंने पहले से ही बोर्ड पर पहले से ही डिकॉउलिंग और फ़िल्टरिंग कैपेसिटर का उपयोग किया था। मैंने बोर्डों में काफी कुछ 0.1 यूएफ डिकम्प्लिंग कैपेसिटर का उपयोग किया है, और सीपीयू में भी 0.1 यूएफ और 0.01 यूएफ कैपेसिटर दोनों हैं। वर्तमान प्रणाली में 8 बोर्ड हैं, प्रत्येक ब्रेडबोर्ड में स्थानीय फ़िल्टरिंग के लिए दोनों रेलों पर दो 4.7 यूएफ एल्यूमीनियम कैपेसिटर हैं। साथ ही, डेबोर्ड से प्राप्त शक्ति में 200 यूएफ टैंटलम संधारित्र होता है। लेकिन जैसा कि मैंने कहा, समस्या यहाँ है।

मुझे यकीन नहीं है कि अगर यह पर्याप्त है, खासकर एक ब्रेडबोर्ड पर चिप्स के पास 104 कैपेसिटर रखने की कठिनाई पर विचार करना। शायद अधिक जोड़ना इसे ठीक कर सकता है?

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

धन्यवाद।

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


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

6
घड़ी / तार्किक मुद्दों से अलग ईएमआई / बिजली के मुद्दों की मदद करने का एक तरीका धीमी आवृत्ति घड़ी, जैसे 0.5MHz या 10 मेगाहर्ट्ज का उपयोग करने की कोशिश करना है। यदि अजीब गड़बड़ 250ns से 1us तक जाती है, तो यह प्रोसेसर ऑपरेशन पर आधारित है। यदि यह 250 के लगभग रहता है, तो यह ईएमआई / बिजली का मुद्दा हो सकता है। क्या आपके पास बस में पुल-अप / डाउन रेसिस्टर्स हैं (क्या यह एक त्रि-राज्य प्रतिक्रिया हो सकती है)?
W5VO

1
एक नज़र डालें और देखें कि क्या प्रोसेसर डेटाशीट डेटा बस पर किसी भी पुल-अप या डाउन रेसिस्टर्स की सिफारिश / सुझाव देता है। यह त्रि-राज्य संचालन से गड़बड़ करने की संभावना को कम करने में मदद करेगा। यदि आपने अपने प्रोग्राम में एक और "inc" निर्देश जोड़ा है, तो आप संभवतः यह पता लगा सकते हैं कि कौन सा निर्देश गड़बड़ था।
W5VO

1
आरडी और नॉट आरडी द्वारा एक द्विदिश डेटा बस बफर के रूप में विपरीत दिशाओं में एक और दो 74HCT573। - शायद यह? कृपया नियंत्रण संकेतों को दिखाते हुए एक सर्किट आरेख की आपूर्ति करें।
ब्रूस एबट

5
मुझे संदेह है कि यह प्रत्येक M1 (opcode fetch) चक्र के अंत में रिफ्रेश के कारण होता है। यह देखने की आवश्यकता है कि आप CS और डेटा बस बफर कैसे सक्षम कर रहे हैं।
ब्रूस एबट

जवाबों:


13

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

... एक अन्य दो 74HCT573 विपरीत दिशाओं में RD और NOT RD द्वारा एक द्विदिश डेटा बस बफर के रूप में नियंत्रित किया जाता है। "- शायद यह? कृपया नियंत्रण संकेतों को दिखाते हुए एक सर्किट आरेख की आपूर्ति करें।

मुझे संदेह है कि यह प्रत्येक M1 (opcode fetch) चक्र के अंत में रिफ्रेश के कारण होता है। यह देखने की आवश्यकता है कि आप CS और डेटा बस बफर कैसे सक्षम कर रहे हैं।

- ब्रूस एबट

द्विदिश डेटा बफर द्वारा नियंत्रित किया जाता है RDऔर NOT RDयदि RDसक्रिय कम है, तो बफर सीपीयू को डेटा ड्राइव करता है, अन्यथा, यदि RDउच्च है, तो इसका मतलब है कि लिखना / आउटपुट, बफर बस को ड्राइव करता है।

द्विदिश डेटा बफर

फिर भी, Z80 ओपकोड लाने के तुरंत बाद DRAM रिफ्रेश के लिए मेमोरी रीडिंग करता है। इस बार, RDहै HIGHके बावजूद यह एक पढ़ने आपरेशन है, इसकी दिशा फ्लिप और बस ड्राइव करने के लिए बफर के कारण, परिणाम एक बस विवाद है। इतना अजीब "notches" हमेशा DRAM रिफ्रेश चक्र के दौरान दिखाई देगा, लेकिन सामान्य मेमोरी रीड / राइट या I / O नहीं होती है। यह बताता है कि "पायदान" हमेशा क्यों दिखाई देगा, लेकिन केवल कुछ के लिए, और सभी तार्किक 1s नहीं।

Z80 ओपकोड लाने का समय आरेख

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

समाधान: लागू (RD AND REFRESH)और (NOT (RD AND REFRESH)। अगले संशोधन में, मुझे यह BUSACKसुनिश्चित करने के लिए भी परीक्षण करना चाहिए कि डेटा बफर एक डीएमए ऑपरेशन के दौरान भी बस नहीं चला रहा है।

अपडेट: मैं समस्या और समाधान की पुष्टि कर सकता हूं। उपयोग करना WRऔर NOT WRइसके बजाय समस्या को ठीक करना, जैसा कि नए योजनाबद्ध में दिखाया गया है( ऐसा न करें! यह गलत है, अपडेट 2 देखें )।

नई योजनाएं (गलत)

तरंग अब सामान्य लग रही है!

नई तरंग, समस्या को दर्शाती है।

Update2: ऊपर दिए गए योजनाबद्ध रूप में अच्छी तरह से टूट गया है, अगर आप इस उत्तर के पाठक हैं, तो इसका उपयोग न करें! यदि मान लिया जाए कि WRजब बस RDनिष्क्रिय है तो सिग्नल काफी खराब है, बस मान लिया RDजाए WRकि निष्क्रिय है तो और भी बुरा है। मैंने प्रारंभिक परीक्षण के लिए पिछले कार्यक्रम का उपयोग किया था, इसलिए सिस्टम काम करता दिखाई दिया, लेकिन यह एक महत्वपूर्ण समस्या से चूक गया।

मेमोरी लिखने के चक्र के दौरान, Z80 CPU सक्रिय कम होने से पहले बस को चलाना शुरू कर देगा WR, इस समय, डेटा बफर अभी भी सीपीयू की ओर डेटा चला रहा था, उफ़, बस विवाद पैदा कर रहा था।

Z80 मेमोरी पढ़ने / लिखने का समय आरेख

ब्रूस एबट सही है: प्रत्येक बफर को नियंत्रित करने के लिए हमेशा स्वतंत्र रूप से उपयोग करना RDऔर WRसंकेत देना बेहतर होता है , बजाय एक सिंगल इन्वर्टिंग के।

उदाहरण के लिए,

नई योजनाएं (निश्चित, लेकिन डीएमए अपरिवर्तित है, आपको इसे संभालना चाहिए।

यह अब पूरी तरह से काम करता है।

और अंत में, फिर से, उपरोक्त योजनाबद्धता एक सरलीकरण है, एक को यह BUSACKसुनिश्चित करने के लिए भी परीक्षण करना चाहिए कि डेटा बफर एक डीएमए ऑपरेशन के दौरान भी बस नहीं चला रहा है।


6
आप ऊपरी बफर को सक्षम करने के लिए उल्टे / आरडी के बजाय / WR का उपयोग करने पर विचार कर सकते हैं। इस तरह से डेटा बस निष्क्रिय हो जाएगी जब तक कि एक वास्तविक रीड या राइट प्रगति पर न हो।
ब्रूस एबट

8

सुनिश्चित करें कि आपके पास अपने सभी आईसी पर पर्याप्त डेकोप्लिंग कैपेसिटर हैं। प्रत्येक आईसी पर बिजली से जमीन पर 100nF सिरेमिक जितना संभव हो उतना कम होता रहता है और एक कम ESR इलेक्ट्रोलाइटिक पावर रेल के पार ब्रेडबोर्ड पर 100uF कहता है।


डिजिटल आईसीएस के लिए बहुत अस्थिरता का हल होने लगता है :)
KingDuken

4
@KingDuken बिल्कुल और मेरे लिए एक गर्म विषय का एक सा, मेरे एक दोस्त को एक बार लापता होने के लिए निकाल दिया गया। कैश हैंडलिंग मशीन में बहुत अस्थिरता का कारण बना, वूप्स।
रॉयसी

2
Decoupling महत्वपूर्ण है, लेकिन यह सब कुछ का जवाब नहीं है। यह तरंग से स्पष्ट होना चाहिए कि यह यहां प्रासंगिक होने की संभावना नहीं है।
पेरीसिनेशन

4

मैं यहां दो संभावनाएं देखता हूं:

1) D0 को काट दिया जाता है

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

लाइन में एक और पुल-डाउन रोकनेवाला जोड़ने की कोशिश करें और जांचें कि घातीय तरंग शून्य शून्य पर जाती है या नहीं।

यह ध्यान रखें कि यह एक समस्या नहीं है और आपका बस इसके साथ पूरी तरह से ठीक काम कर सकता है।

2) ध्यान दें

आपकी परिकल्पना # 4 यह भी संभव है कि D0 को किसी अन्य तर्क पंक्ति में छोटा किया जाए। मुझे इसकी संभावना कम लगती है, क्योंकि इस मामले में आप अपेक्षाकृत लंबे समय तक स्थिर के साथ एक घातीय तरंग नहीं देखेंगे जैसा कि आप अभी देखते हैं। आप एक और समान तरंग के लिए खोज में अपने सर्किट में अन्य जाल की जांच कर सकते हैं, यह दर्शाता है कि आपके पास एक छोटा है।

सौभाग्य!

पुनश्च - यह एक संकेत अखंडता समस्या नहीं है, इसके लिए पल्स की चौड़ाई बहुत लंबी है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.