Я пытаюсь создать домашний компьютер Z80 для развлечения ретро-компьютеров и научить себя основам электронного дизайна. Для подтверждения концепции, я уже собрал базовую систему на макетах в предыдущие недели.
Текущий прототип чрезвычайно прост. Я использовал кристалл 4 МГц, управляемый генератором 74HCT04 Пирса, в качестве системных часов, два защелки 74HCT573 в прозрачном режиме ( LE
высокий) в качестве буфера для 16-битной адресной шины, еще два 74HCT573 в противоположных направлениях, управляемых RD
и NOT RD
в качестве двунаправленных данных буфер шины. Я подключил к системной шине 100-нс ЭСППЗУ AT28C256 (декодируется только 16-КиБ) и два 150 -нм чипа 8-Кбайт SRAM. Я использовал 74HCT42 для генерации CS
сигнала и подключил OE
EEPROM к низкому, WE
высокому, оставив только один CS-сигнал для управления EEPROM.
Все на макетах шумно, но после завершения всех этапов система оказалась полностью работоспособной. Теперь он может извлекать инструкции из EEPROM, считывать и записывать данные из / в SRAM, и он имеет последовательный порт, выполненный из другой защелки 74HCT573, D0
подключен D0
, то LE
есть (NOT (IOREQ NAND WR))
выход поступает из Q1
, другими словами, только одного выходного порта без адресной логики декодирования. Я написал тестовую программу с интенсивным использованием CPU / RAM, и мой компьютер может выдать ожидаемый результат. Memdumps также показали, что Z80 может правильно прочитать все байты из EEPROM, поэтому все работает.
Но когда я попытался проверить D0
контакт шины данных, я увидел странные «зазубрины» для некоторых очевидных логических выходов 1.
и они, кажется, всегда появляются в течение некоторых логических 1 с вскоре после того, как CS
сигнал EEPROM становится активным, например, вот захват странной выемки, наложенной на синий сигнал CS EEPROM.
Я попытался изолировать проблему, поэтому я подключил все выводы CS SRAM к HIGH, эффективно удаляя их из системы, и я написал простую тестовую программу, которая не имеет доступа к памяти.
.org 0x00
di
xor a
loop:
out (0x00), a
inc a
jp loop
Но проблема остается неизменной, странные «зазубрины» все еще всегда появляются для некоторых логических единиц, сразу после MEMRQ
и / или (так как теперь это, по сути, одна фишка) CS
(синий) становится низким.
Все выводы CS SRAM являются ВЫСОКИМИ, поэтому система в основном имеет только микросхему EEPROM AT28C256 в качестве памяти и защелку в качестве выходного порта. Система также имеет внутрисистемного программиста, сделанного из Atmega328p, для перепрограммирования EEPROM на лету во время запроса DMA, но я не думаю, что это виновник, так как я обработал все данные и адресный вывод программиста, и Я видел метки еще до того, как добавил программиста.
Таким образом, «метки» должны быть созданы во время цикла выборки кода операции. Кто они такие?
У меня есть несколько гипотез:
В этом нет ничего плохого, это просто вызвано плохой целостностью сигнала на макетах, и оно автоматически исчезнет в хорошо спроектированной и хорошо отсоединенной печатной плате . Макет имеет все виды проблем целостности сигнала: рассогласование импеданса, отражения, паразитная емкость, перекрестные помехи, EMI / RFI. Длинные шинные провода, которые проходят через платы, вероятно, на определенную величину ухудшают проблему.
Если это правда, можете ли вы объяснить природу «насечек»? У этого явления есть имя в EE? Я видел много промахов и звонков раньше, но никогда не видел "зазубрин". И почему я вижу это только для некоторых логических уровней?
Timing. Возможно ли, что короткое «время установления» выхода EEPROM или других логических схем вызывает этот странный эффект на шине?
Вентилятор-аут. Возможно, длинная шина потребляет много тока и имеет высокую емкость, поэтому выходной сигнал ЭСППЗУ испытывал трудности с увеличением шины? И, возможно, зонд осциллографа также загружает шину?
Конфликт шины или другие логические ошибки, из-за которых что-то вытягивало шину данных. Вряд ли я думаю? Другие компоненты в шине изолированы, и я не смог понять, как это может сделать одна EEPROM AT28C256 или защелка. Но я думаю, что это все еще возможно из-за ошибки проводки или скрытого внутреннего короткого замыкания в макетах.
Обновление: с самого начала я уже использовал разъединяющие и фильтрующие конденсаторы на плате. Я использовал довольно много развязывающих конденсаторов по 0,1 мкФ на всех платах, и у CPU даже есть конденсаторы как 0,1 мкФ, так и 0,01 мкФ для развязки. Текущая система имеет 8 плат, каждая макет имеет два алюминиевых конденсатора по 4,7 мкФ на обеих направляющих для локальной фильтрации. Кроме того, мощность, получаемая от девборда, имеет танталовый конденсатор емкостью 200 мкФ. Но, как я уже сказал, проблема здесь.
Я не уверен, что это достаточно, особенно учитывая сложность размещения 104 конденсаторов рядом с чипами на макете. Возможно добавление большего количества может исправить это?
Что меня интересует, так это основная причина проблемы: если можно доказать, что это просто внутренние проблемы неадекватного разделения или плохой целостности сигнала на макете, я могу перестать пытаться тратить время на устранение неполадок или беспокоиться об этом, так как Окончательный дизайн будет печатной платой. Но я не уверен.
Благодарю.
Обновление 2: Я думаю, что комментарий Брюса Эбботта дал правильный ответ, и проблема решена! Хотя я не могу проверить это до завтра. Виновником является обновление DRAM в Z80, подробности см. В моем собственном ответе. В настоящее время новый ответ не требуется, и я приму свой собственный ответ, когда я подтвердил решение. Если это не сработает, я обновлю вопрос. Спасибо всем за помощь.