Neden Bazı Mantıksal 1'ler İçin Veri Hattında Tuhaf Bir “Çentik” Görüyorum?


15

Bazı retrocomputing eğlencesi için bir Z80 homebrew bilgisayar inşa etmeye ve kendime elektronik tasarımın temellerini öğretmeye çalışıyorum. Kavram kanıtı için, önceki haftalarda breadboard'lara temel bir sistemi başarıyla kurdum.

Mevcut prototip son derece basittir. Sistemin saat olarak bir 74HCT04 Pierce osilatör tarafından tahrik edilen bir 4 MHz kristal kullanılan şeffaf modu (iki 74HCT573 mandal LE16-bitlik bir adres veri yolu için bir tampon olarak yüksek) tarafından kontrol ters yönde bir iki 74HCT573 RDve NOT RDbir çift yönlü veri olarak veri yolu tamponu. Bir bağlanmış 100 ns AT28C256 EEPROM (sadece 16-KB Yüklenme deşifre edilir) ve iki 150 ns sistem veri yoluna 8-KB Yüklenme SRAM fiş. I oluşturmak için bir 74HCT42 kullanılan CSsinyali ve kablolu OE, en düşük EEPROM'un WEEEPROM kontrol etmek için sadece tek bir CS sinyali bırakarak en yüksek seviyesine.

Breadboardlardaki her şey gürültülü, ancak her aşamayı tamamladıktan sonra sistem tamamen işlevsel görünüyordu. Şimdi O dan / SRAM yazma veri okumak ve, EEPROM talimat getirebilir ve başka mandal 74HCT573 yapılmış bir seri portu olmasına D0bağlı olduğu D0, LEolduğu (NOT (IOREQ NAND WR)), çıkış dan çıkar Q1başka bir deyişle, tek bir çıkış portuna, adres çözme mantığı olmadan. CPU / RAM yoğun bir karşılaştırma programı yazdım ve bilgisayarım beklenen sonucu verebilir. Memdumps ayrıca Z80'in EEPROM'daki tüm baytları doğru bir şekilde okuyabildiğini gösterdi, bu yüzden her şey çalışıyor.

Ama D0veri yolunun pinini araştırmaya çalıştığımda , bazı belirgin mantıksal 1 çıkışlar için garip bir "çentikler" görüyordum.

D0'da Tuhaf Çentikler örneği

ve CSEEPROM'un sinyali aktif hale geldikten kısa bir süre sonra her zaman bazı mantıksal 1'ler için görünüyorlar , örneğin, burada mavi EEPROM CS sinyalinin üzerine yerleştirilen garip çentiğin bir yakalanması.

CS sinyaline eklenen Garip Bir Çentik

Sorunu izole etmeye çalıştım, bu yüzden SRAM'ın tüm CS pinlerini YÜKSEK'e bağladım, onları etkili bir şekilde sistemden kaldırdım ve bellek erişimi olmayan basit bir test programı yazdım.

.org 0x00
    di

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

    jp loop

Ama sorun değişmedi, garip "çentikler" her zaman bazı mantıksal 1'ler için hala ortaya çıkıyor , hemen sonra MEMRQve / veya (aslında şimdi bir çip olduğu için) CS(mavi) azalıyor.

SRAM'ın tüm CS pinleri YÜKSEK, bu nedenle sistemde sadece bellek olarak bir AT28C256 EEPROM yongası ve çıkış portu olarak bir mandal bulunur. Sistem ayrıca, bir DMA talebi sırasında EEPROM'u anında yeniden programlamak için bir Atmega328p'den yapılmış bir sistem içi programcıya sahiptir, ancak programcının tüm verilerini ve adres çıktısını trista ettiğim için suçlu olduğunu düşünmüyorum ve Programcıyı eklemeden önce çentikler gördüm.

Bir başka "Çentik" Örneği

Dolayısıyla, bir opcode getirme döngüsü sırasında "çentikler" oluşturulmalıdır. Onlar neler?

Birkaç hipotezim var:

  1. Yanlış bir şey yok, sadece breadboard'ların kötü sinyal bütünlüğünden kaynaklanıyor ve iyi tasarlanmış ve iyi ayrılmış bir PCB'de otomatik olarak kaybolacak . Breadboard her türlü sinyal bütünlüğü sorununa sahiptir: empedans uyumsuzlukları, yansımalar, parazitik kapasitans, karışma, EMI / RFI. Kartlar boyunca uzanan uzun otobüs telleri, sorunu büyük ölçüde daha da kötüleştirir.

    Eğer doğruysa, "çentiklerin" doğasını açıklayabilir misiniz? Bu fenomenin Enerji Verimliliği'nde bir adı var mı? Daha önce birçok aşma ve zil sesi gördüm, ama "çentikler" görmedim. Ve neden sadece bazı mantıksal seviyelerde görüyorum ?

  2. Zamanlama. EEPROM çıkışının veya diğer mantık devrelerinin kısa bir "bekleme süresi" veriyolunda bu garip etkiye neden olabilir mi?

  3. Fan-out. Belki de uzun veri yolu çok fazla akım çeker ve yüksek kapasitansa sahiptir, bu nedenle EEPROM çıkışı veri yolunu yüksek sürmekte zorlanıyordu? Ve muhtemelen osiloskop probu da otobüsü yüklüyor?

  4. Veri yolu çekişmesi veya veri yolunu çekmesine neden olan diğer mantık hataları. Sanırım pek mümkün değil mi? Veriyolundaki diğer bileşenler yalıtılmıştır ve tek bir AT28C256 EEPROM veya mandalın bunu nasıl yapabileceğini göremedim. Ancak sanırım bir kablolama hatası veya breadboard'larda gizli bir iç kısa devre nedeniyle hala mümkün.

Güncelleme: Zaten tahtadaki dekuplaj ve filtreleme kapasitörlerini baştan beri kullandım. Kartlar arasında oldukça az 0.1 uF dekuplaj kapasitörü kullandım ve CPU, dekuplaj için hem 0.1 uF hem de 0.01 uF kapasitörlere sahip. Mevcut sistem 8 panele sahiptir, her bir devre tahtasında yerel filtreleme için her iki rayda iki adet 4.7 uF alüminyum kapasitör bulunur. Ayrıca, devboard'dan elde edilen güç 200 uF tantal kapasitöre sahiptir. Ama dediğim gibi, sorun burada.

Yine de yeterli olup olmadığından emin değilim, özellikle bir breadboard üzerindeki cipslerin yakınında 104 kapasitör yerleştirmenin zorluğu düşünüldüğünde. Belki daha fazlasını eklemek sorunu çözebilir mi?

İlgilendiğim, sorunun temel nedenidir, eğer basitçe ayrışma veya zayıf tahta bütünlüğünün doğal problemleri olduğu teyit edilebiliyorsa, sorun gidermek veya endişelenmek için zaman harcamaktan vazgeçebilirim. son tasarım bir PCB olacaktır. Ama emin değilim.

Teşekkürler.

Update2: Aklımda, Bruce Abbott'un yorumunun doğru cevabı verdiğine ve problemin çözüldüğüne inanıyorum! Yarına kadar test edemesem de. Suçlu, Z80'in DRAM yenilemesidir, ayrıntılar için kendi cevabım bakın. Şu anda yeni bir yanıt gerekmiyor ve çözümü onayladığımda kendi cevabımı kabul edeceğim. Eğer işe yaramazsa, soruyu güncelleyeceğim. Herkesin yardımı için teşekkürler.


Düzenlemenizi yeni gördüm. Kullandığınız parçaların teknik özelliklerine ve tasarım notlarına / uygulamalarına bakmanın ideal olacağını düşünüyorum. Cihazınız için kapasitörlerin ayrılması dışında eksik bileşenler olabilir. Her spesifikasyona uyduğunuzdan emin misiniz? Bu iyi bir kök neden egzersizi. Şu an itibariyle, sorunuz devre şeması olmadan cevaplanamaz.
KingDuken

6
EMI / güç sorunlarını saat / mantıksal sorunlardan ayırmanın bir yolu daha yavaş bir frekans saati kullanmayı denemektir, örn. 0,5MHz veya 1MHz. Tuhaf aksaklık 250ns'den 1us'a çıkarsa, işlemci işlemine dayanır. Yaklaşık 250ns kalırsa, bir EMI / güç sorunu olabilir. Otobüste yukarı / aşağı dirençleriniz var mı (bu üç durumlu bir yanıt olabilir)?
W5VO

1
Bir göz atın ve işlemci veri sayfasının veri yolundaki herhangi bir yukarı çekme veya aşağı çekme direnci önerip önermediğine bakın. Bu, üç durumlu operasyondan aksaklık olasılığını azaltmaya yardımcı olacaktır. Programınıza başka bir "inc a" talimatı eklediyseniz, muhtemelen hangi talimatın aksaklığa neden olduğunu anlayabilirsiniz.
W5VO

1
"... iki yönlü bir veri yolu tamponu olarak RD ve NOT RD tarafından kontrol edilen zıt yönlerde bir başka 74HCT573." - belki bu? Lütfen kontrol sinyallerini gösteren bir devre şeması sağlayın.
Bruce Abbott

5
Her M1 (opcode fetch) döngüsünün sonundaki yenileme işleminden kaynaklandığından şüpheleniyorum. Tam olarak nasıl CS ürettiğinizi görmeniz gerekir ve veri yolu tamponu etkinleştirir.
Bruce Abbott

Yanıtlar:


13

Herkesin yardımı için teşekkürler. Bruce Abbott'un doğru cevabı verdiğine inanıyorum.Yatağımdan gönderiyorum ve yarına kadar henüz test edemiyorum, amaAşağıdaki analiz doğrulandı, "yenileme" kelimesinden bahsettiğinde, sorunun zaten çözülmüş olduğunu düşünüyorum. Z80'in hafızayı nasıl yenilediğini biliyordum, ancak önceki günlerde onu tamamen unuttum.

... iki yönlü bir veri yolu tamponu olarak RD ve NOT RD tarafından kontrol edilen zıt yönlerde bir başka 74HCT573. "- belki bu? Lütfen kontrol sinyallerini gösteren bir devre şeması sağlayın.

Her M1 (opcode fetch) döngüsünün sonundaki yenileme işleminden kaynaklandığından şüpheleniyorum. Tam olarak nasıl CS ürettiğinizi görmeniz gerekir ve veri yolu tamponu etkinleştirir.

- Bruce Abbott

Çift yönlü veri tamponu ile kontrol edilir RDve NOT RDvarsa RD, aktif düşüktür, tampon disk CPU veri, aksi halde, RDyüksek, bir yazma / çıkış, tampon sürücüleri yolu anlamına gelmektedir.

çift ​​yönlü veri arabelleği

Bununla birlikte, Z80, opcode getirildikten hemen sonra DRAM yenilemesi için bir bellek okuması gerçekleştirir. Bu kez, RDbir HIGHonun yönünü çevirmek ve otobüs sürmek için tampon neden salt bir operasyon rağmen, sonuç bir otobüs çekişme olduğunu. DRAM yenileme döngüsü sırasında her zaman garip "çentikler" görünür, ancak sıradan bellek okuma / yazma veya G / Ç olmaz. Bu, "çentik" in neden her zaman ortaya çıkacağını açıklar, ancak sadece bazıları için ve tüm mantıksal 1'ler için değil.

Z80 opcode getirme zamanlama diyagramı

Ayrıca, SRAM'ın yenilenmesi gerekmez, bu nedenle DRAM yenilemesi sistemimde tamamen işe yaramaz ve bu veri yolu tartışması herhangi bir talimatı veya veriyi bozmaz, bu da sistemin tamamen işlevsel görünmesini sağlar.

Çözüm: uygulamak (RD AND REFRESH)ve (NOT (RD AND REFRESH). Bir sonraki revizyonda, BUSACKveri tamponunun bir DMA işlemi sırasında da veri yolunu sürmediğinden emin olmak için test etmeliyim .

Güncelleme: Sorunu ve çözümü onaylayabilirim. Yeni şemalarda gösterildiği gibi sorunu kullanmak WRve NOT WRdüzeltmek( bunu yapma! Bu da yanlış, bkz. Güncelleme 2 ).

Yeni şemalar (yanlış)

Dalga formu şimdi normal görünüyor!

Sorunu gösteren yeni dalga formu düzeltildi.

Güncelleme2: Yukarıdaki şemalar da bozuldu, eğer bu cevabı okuyorsanız, kullanmayın! Otobüs varsayarak ise WRzaman RDsinyal yeterince kötü inaktif olduğunu, otobüs varsayarak olduğu RDzaman WRetkin olmasa da kötüdür. İlk test için önceki programı kullandım, bu yüzden sistem çalışıyor gibi görünüyordu, ancak kritik bir sorunu kaçırdı.

Bir bellek yazma döngüsü sırasında Z80 CPU, aktif seviyeye düşmeden önce veriyolunu sürmeye başlayacaktı WR, şu anda veri arabelleği hala CPU'ya doğru veri çekiyordu, bir veri yolu çekişi oluşturuyordu.

Z80 bellek okuma / yazma zamanlama diyagramı

Bruce Abbott doğrudur: her bir tamponu kontrol etmek için her zaman bağımsız olarak kullanmak RDve WRsinyal vermek daha iyidir , tek bir tamponu tersine çevirmek yerine.

Örneğin,

Yeni şemalar (sabit, ancak DMA kullanılmıyor, bunu ele almalısınız.

Şimdi mükemmel çalışıyor.

Ve son olarak, yine, yukarıdaki şemalar bir sadeleştirmedir, aynı zamanda BUSACKveri tamponunun bir DMA işlemi sırasında da veriyolunu sürmediğinden emin olmak için test edilmelidir .


6
Üst arabelleği etkinleştirmek için ters / RD yerine / WR kullanmayı düşünebilirsiniz. Bu şekilde, gerçek bir okuma veya yazma işlemi yapılmadıkça veri yolu etkin olmaz.
Bruce Abbott

8

Tüm IC'lerinizde yeterli ayırıcı kapasitörlere sahip olduğunuzdan emin olun. Her IC'de güçten toprağa 100nF'lik bir seramik, kablolarını mümkün olduğunca kısa tutar ve düşük ESR elektrolitik, güç rayları boyunca breadboard üzerinde 100uF diyor.


Dijital IC'ler için bir çok istikrarsızlık için çözüm gibi görünüyor :)
KingDuken

4
@KingDuken Kesinlikle ve benim için biraz sıcak bir konu, bir arkadaşım birini kaçırdığı için bir kez kovuldu. Bir nakit taşıma makinesinde çok fazla istikrarsızlığa neden oldu.
RoyC

2
Ayrıştırma önemlidir, ancak her şeyin cevabı değildir. Dalga formundan, burada alakalı olmasının muhtemel olmadığı açık olmalıdır.
pericynthion

4

Burada iki olasılık görüyorum:

1) D0 tristated

Ne sürüyor olsaydı, D0 tristata (yüksek empedans modu) gider ve daha sonra D0 ağında bir yerde aşağı çekme gerilimi yavaşça düşürür (çekme direnci ve IC'lerin ve izlerin parazitik kapasiteleri ile tanımlanan zaman sabiti). Dalga formunun üstel doğası, hattın güçlü bir şey tarafından değil, nispeten zayıf bir aşağı çekme tarafından yönlendirildiğinin güçlü bir göstergesidir.

Çizgiye başka bir aşağı çekme direnci eklemeyi deneyin ve üstel dalga formunun sıfıra daha hızlı olup olmadığını kontrol edin.

Bunun mutlaka bir sorun olmadığını ve otobüsünüzün bununla mükemmel şekilde çalışabileceğini unutmayın.

2) Dikkat

Hipoteziniz # 4. D0'ın başka bir mantık hattına kısa devre olması da mümkündür. Bunu olası bulmuyorum, çünkü bu durumda, şu anda gördüğünüz gibi nispeten uzun zaman sabiti olan üstel bir dalga formu göremezsiniz. Devrenizdeki diğer ağları kısa devre yaptığınızı gösteren başka bir özdeş dalga formu aramak için sorgulayabilirsiniz.

İyi şanslar!

PS - bu bir sinyal bütünlüğü sorunu değil, darbe genişliği bunun için çok uzun

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.