Чому я бачу дивну «виїмку» в рядку даних для деяких логічних ходів?

Я намагаюся побудувати домашній комп'ютер Z80 для задоволення від ретрокомп'ютерів і навчити себе основ електронного дизайну. Для підтвердження концепції я вже попередні тижні успішно зібрав базову систему на дошках.

Поточний прототип надзвичайно простий. Я використовував 4 МГц-кристал, керований генератором 74HCT04 Pierce як системний такт, два засувки 74HCT573 у прозорому режимі ( LEвисокий) як буфер для 16-бітної шини адреси, ще два 74HCT573 у протилежних напрямках, керованих RDта NOT RDяк двонаправлені дані буфер шини. Я приєднав 100 нс AT28C256 EEPROM (розшифровується лише 16-KiB) та два мікросхеми 8 n -KiB SRAM з розміром 150 ns до системної шини. Я використовував 74HCT42 для генерації CSсигналу та провідного електропроводу OEEEPROM на низький, WEвисокий, залишаючи лише один CS-сигнал для управління EEPROM.

Все на дошках шумно, але система, здавалося, була повністю функціонуючою після того, як я проходив усі етапи. Тепер він може отримувати інструкції від EEPROM, читати і записувати дані з / в SRAM, і він має послідовний порт, зроблений з іншої засувки 74HCT573, D0підключений до D0, LEтобто (NOT (IOREQ NAND WR)), вихід виходить з Q1, іншими словами, тільки одного вихідного порту без логіки декодування адреси Я написав орієнтирову програму на CPU / RAM, і мій комп'ютер може вивести очікуваний результат. Memdumps також показало, що Z80 може читати всі байти з EEPROM правильно, тому все працює.

Але коли я намагався пробувати D0штифт шини даних, я бачив якісь дивні "виїмки" для явних логічних виходів 1.

і, здається, вони завжди з'являються протягом певних логічних 1s незабаром після того, як CSсигнал EEPROM активізується, наприклад, ось захоплення дивної виїмки, накладеної на синій сигнал EEPROM CS.

Я спробував усунути проблему, тому я з'єднав усі CS-штифти SRAM на HIGH, ефективно видаляючи їх із системи, і я написав просту тестову програму, яка не має доступу до пам'яті.

.org 0x00
    di

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

    jp loop

Але проблема не змінюється, дивні "виїмки" все ще завжди з'являються для деяких логічних 1, відразу після MEMRQта / або (оскільки це по суті односхемовий) CS(синій) знижується.

Всі CS штифти SRAM є ВИСОКИМИ, тому система в значній мірі має лише чіп AT28C256 EEPROM як пам'ять та засувку як вихідний порт. У системі також є системний програміст, створений з Atmega328p для перепрограмування EEPROM на ходу під час запиту DMA, але я не думаю, що це винуватець, оскільки я перевірив усі дані та вихідні дані програміста, і Я бачив насічки ще до того, як додав програміста.

Отже, "виїмки" повинні бути створені під час циклу отримання опкоду. Хто вони?

У мене є кілька гіпотез:

1. У цьому немає нічого поганого, це просто спричинено поганою цілісністю сигналу макетів, і він автоматично зникне у добре розробленій та добре відокремленій друкованій платі . На макетній панелі є всілякі проблеми з цілісністю сигналу: невідповідність імпедансу, відбиття, паразитична ємність, перехресна розмова, EMI / RFI. Довгі дроти шини, що проходять через плати, швидше за все, погіршують проблему на ступінь масштабу.

   Якщо це правда, чи можете ви пояснити природу "висічок"? Чи має це явище назву в ЕЕ? Раніше я бачив багато прострілів та дзвінків, але жодного разу не бачив "виїмок". І чому я бачу це лише на деяких логічних рівнях?

2. Хронометраж. Чи можливо, що короткий "час розрахунку" виходу EEPROM або інших логічних схем спричиняє цей дивний ефект на шині?

3. Вентилятор. Можливо, довга шина притягує багато струму і має високу ємність, тому на виході EEPROM було важко керувати шиною? І, мабуть, зонд осцилографа також завантажує шину?

4. Суперечка шини або інші логічні помилки, які спричинили щось для витягування шини даних. Навряд чи я думаю? Інші компоненти шини є ізольованими, і мені не вдалося зрозуміти, як може зробити це єдиний AT28C256 EEPROM або засувка. Але я здогадуюсь, що це все-таки можливо через помилку проводки або прихований внутрішній шорт у макетних дошках.

Оновлення: з самого початку я вже використовував конденсатори для роз'єднання та фільтрації плати. Я використав досить багато конденсаторів для роз'єднання 0,1 мкФ у платах, а для процесора навіть є конденсатори 0,1 мкФ та 0,01 мкФ для роз'єднання. Поточна система має 8 дощок, на кожній дошці є два алюмінієві конденсатори 4,7 мкФ на обох рейках для локальної фільтрації. Крім того, потужність, отримана від розробника, має конденсатор танталового конденсатора потужністю 200 мкФ. Але, як я вже сказав, проблема тут.

Я не впевнений, чи достатньо це, особливо враховуючи складність розміщення 104 конденсаторів біля мікросхем на дошці. Можливо, додавання більше може виправити це?

Мене цікавить, що є першопричиною проблеми, якщо вона може бути підтверджена просто невідповідними проблемами неадекватної розв’язки або поганої цілісності сигналу на макеті, я можу перестати намагатися витрачати час на усунення несправностей або турбуватися про неї з моменту остаточним дизайном буде друкована плата. Але я не впевнений.

Спасибі.

Update2: На мій погляд, я вважаю, що коментар Брюса Абботта дав правильну відповідь і проблема вирішена! Хоча я не можу перевірити його до завтра. Винуватець - оновлення DRAM Z80, детальну інформацію див. У власній відповіді. Наразі нова відповідь не потрібна, і я прийму власну відповідь, коли підтвердив рішення. Якщо це не працює, я оновлю питання. Дякуємо за допомогу усім.

Дякуємо за допомогу усім. Я вважаю, що Брюс Абботт дав правильну відповідь.Я відправляю повідомлення з мого ліжка, і не можу перевірити його до завтра, алеАналіз нижче підтверджується, коли він згадав слово «оновити», я думаю, що проблема вже вирішена. Я знав, як Z80 освіжає пам’ять, але повністю забув про це в попередні дні.

... ще два 74HCT573 в протилежних напрямках, керованих RD, а не RD як двосторонній буфер шини даних. "- можливо це? Будь ласка, надайте схему, що показує керуючі сигнали.

Я підозрюю, що це викликано оновленням наприкінці кожного циклу M1 (опкод). Потрібно точно зрозуміти, як ви створюєте CS та буфер шини даних.

- Брюс Абботт

Двонаправленим буфером даних керує, RDа NOT RDякщо RDактивний низький, буфер передає дані в ЦП, інакше, якщо RDвін високий, це означає запис / вихід, буфер приводить шину.

Тим не менш, Z80 виконує зчитування пам'яті для оновлення DRAM відразу після вибору опкоду. На цей раз, RDце , HIGHнезважаючи на це операція читання, в результаті чого буфера перевернути напрямок і їхати на автобусі, в результаті автобус розбрат. Тож дивні "виїмки" завжди з'являтимуться під час циклу оновлення DRAM, але не звичайна пам'ять читає / пише чи вводить / виводить. Це пояснює, чому "виїмка" завжди з'явиться, але лише для деяких, і не всіх логічних 1.

Крім того, SRAM не потрібно оновлювати, щоб оновлення DRAM було абсолютно марним у моїй системі, і це твердження шини не зіпсувало б ніяких інструкцій чи даних, завдяки чому система здається повністю функціональною.

Рішення: реалізувати (RD AND REFRESH)та (NOT (RD AND REFRESH). У наступній редакції я також повинен перевірити, BUSACKщоб переконатися, що буфер даних не керує шиною також під час роботи з DMA.

Оновлення: я можу підтвердити проблему та рішення. Використовуючи WRта NOT WRзамість цього усунувши проблему, як показано в нових схемах( не робіть цього! Це також неправильно, див. Оновлення 2 ).

Форма хвилі зараз виглядає нормально!

Update2: Схеми, наведені вище, також порушені, якщо ви читач цієї відповіді, не використовуйте її! Якщо припустити, що шина є, WRколи RDсигнал неактивний, досить погано, припускати, що шина, RDколи WRнеактивна, ще гірша. Я використовував попередню програму для початкового тестування, тому система, здається, працює, але вона пропустила критичну проблему.

Під час циклу запису в пам'ять процесор Z80 почне приводити шину до того, як WR активізується низький рівень; в цей час буфер даних все ще спрямовував дані до процесора, ой, створюючи сутичку шини.

Брюс Абботт правильний: краще завжди використовувати RDта WRподавати сигнал незалежно, щоб керувати кожним буфером, а не перевертати один.

Наприклад,

Він прекрасно працює зараз.

І нарешті, знову ж таки, наведені вище схеми є спрощенням, також слід перевірити, BUSACKщоб переконатися, що буфер даних не керує шиною також під час роботи з DMA.

Переконайтеся, що у вас є належні конденсатори для роз'єднання всіх ваших ІС. 100nF кераміка від потужності до землі на кожному ІС, зберігаючи її відводи якомога коротше, а електролітичний низький показник ESR, наприклад, 100uF на дошці через силові рейки.

Тут я бачу дві можливості:

1) D0 тристалізований

Що б не було за рухом, D0 переходить до тристату (режим високого імпедансу), і тоді витягнутий кудись у сітку D0 повільно знижує напругу (константа часу, що визначається опором, що спадає, та паразитичними ємностями ІС та слідами). Експонентний характер форми хвилі є яскравим свідченням того, що лінію рухає не щось сильне, а скоріше відносно слабке пониження.

Спробуйте додати до лінії ще один висувний резистор і перевірте, чи швидше експоненціальна форма хвилі переходить на нуль.

Майте на увазі, що це не обов'язково проблема, і ваш автобус може працювати з цим ідеально.

2) Суперечка

Ваша гіпотеза №4. Можливо також, що D0 буде короткий до іншої логічної лінії. Я вважаю це малоймовірним, оскільки в цьому випадку ви б не бачили експоненціальну форму хвилі з відносно тривалою постійною часом, як ви бачите зараз. Ви можете зондувати інші мережі у своїй схемі в пошуках іншої ідентичної форми хвилі, що означає, що у вас короткий.

Удачі!

PS - це не проблема цілісності сигналу, ширина імпульсу занадто довга для цього