Почему я вижу странную метку на линии данных для некоторых логических единиц?

Я пытаюсь создать домашний компьютер Z80 для развлечения ретро-компьютеров и научить себя основам электронного дизайна. Для подтверждения концепции, я уже собрал базовую систему на макетах в предыдущие недели.

Текущий прототип чрезвычайно прост. Я использовал кристалл 4 МГц, управляемый генератором 74HCT04 Пирса, в качестве системных часов, два защелки 74HCT573 в прозрачном режиме ( LEвысокий) в качестве буфера для 16-битной адресной шины, еще два 74HCT573 в противоположных направлениях, управляемых RDи NOT RDв качестве двунаправленных данных буфер шины. Я подключил к системной шине 100-нс ЭСППЗУ AT28C256 (декодируется только 16-КиБ) и два 150 -нм чипа 8-Кбайт SRAM. Я использовал 74HCT42 для генерации CSсигнала и подключил OEEEPROM к низкому, 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, но я не думаю, что это виновник, так как я обработал все данные и адресный вывод программиста, и Я видел метки еще до того, как добавил программиста.

Таким образом, «метки» должны быть созданы во время цикла выборки кода операции. Кто они такие?

У меня есть несколько гипотез:

1. В этом нет ничего плохого, это просто вызвано плохой целостностью сигнала на макетах, и оно автоматически исчезнет в хорошо спроектированной и хорошо отсоединенной печатной плате . Макет имеет все виды проблем целостности сигнала: рассогласование импеданса, отражения, паразитная емкость, перекрестные помехи, EMI / RFI. Длинные шинные провода, которые проходят через платы, вероятно, на определенную величину ухудшают проблему.

   Если это правда, можете ли вы объяснить природу «насечек»? У этого явления есть имя в EE? Я видел много промахов и звонков раньше, но никогда не видел "зазубрин". И почему я вижу это только для некоторых логических уровней?

2. Timing. Возможно ли, что короткое «время установления» выхода EEPROM или других логических схем вызывает этот странный эффект на шине?

3. Вентилятор-аут. Возможно, длинная шина потребляет много тока и имеет высокую емкость, поэтому выходной сигнал ЭСППЗУ испытывал трудности с увеличением шины? И, возможно, зонд осциллографа также загружает шину?

4. Конфликт шины или другие логические ошибки, из-за которых что-то вытягивало шину данных. Вряд ли я думаю? Другие компоненты в шине изолированы, и я не смог понять, как это может сделать одна EEPROM AT28C256 или защелка. Но я думаю, что это все еще возможно из-за ошибки проводки или скрытого внутреннего короткого замыкания в макетах.

Обновление: с самого начала я уже использовал разъединяющие и фильтрующие конденсаторы на плате. Я использовал довольно много развязывающих конденсаторов по 0,1 мкФ на всех платах, и у CPU даже есть конденсаторы как 0,1 мкФ, так и 0,01 мкФ для развязки. Текущая система имеет 8 плат, каждая макет имеет два алюминиевых конденсатора по 4,7 мкФ на обеих направляющих для локальной фильтрации. Кроме того, мощность, получаемая от девборда, имеет танталовый конденсатор емкостью 200 мкФ. Но, как я уже сказал, проблема здесь.

Я не уверен, что это достаточно, особенно учитывая сложность размещения 104 конденсаторов рядом с чипами на макете. Возможно добавление большего количества может исправить это?

Что меня интересует, так это основная причина проблемы: если можно доказать, что это просто внутренние проблемы неадекватного разделения или плохой целостности сигнала на макете, я могу перестать пытаться тратить время на устранение неполадок или беспокоиться об этом, так как Окончательный дизайн будет печатной платой. Но я не уверен.

Благодарю.

Обновление 2: Я думаю, что комментарий Брюса Эбботта дал правильный ответ, и проблема решена! Хотя я не могу проверить это до завтра. Виновником является обновление DRAM в Z80, подробности см. В моем собственном ответе. В настоящее время новый ответ не требуется, и я приму свой собственный ответ, когда я подтвердил решение. Если это не сработает, я обновлю вопрос. Спасибо всем за помощь.

Спасибо всем за помощь. Я считаю, что Брюс Эбботт дал правильный ответ.Я пишу из своей кровати и пока не могу проверить это до завтра, ноАнализ ниже подтверждается, когда он упомянул слово «обновить», я думаю, что проблема уже решена. Я знал, как Z80 освежает память, но совершенно забыл об этом в предыдущие дни.

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

Я подозреваю, что это вызвано обновлением в конце каждого цикла M1 (выборки кода операции). Нужно точно увидеть, как вы генерируете CS и разрешает буфер данных.

- Брюс Эбботт

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

Тем не менее, Z80 выполняет чтение памяти для обновления DRAM сразу после выборки кода операции. На этот раз, RDэто , HIGHнесмотря на это операция чтения, в результате чего буфера перевернуть направление и ехать на автобусе, в результате автобус раздор. Таким образом, странные «метки» всегда будут появляться во время цикла обновления DRAM, но не обычные операции чтения / записи памяти или ввода-вывода. Это объясняет, почему метка всегда появляется, но только для некоторых, а не для всех логических единиц.

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

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

Обновление: я могу подтвердить проблему и решение. Используя WRи NOT WRвместо этого исправил проблему, как показано в новой схеме ( не делайте этого! Это также неправильно, см. обновление 2 ).

Форма волны теперь выглядит нормально!

Обновление 2: Схема выше также нарушена, если вы читаете этот ответ, не используйте его! Если предположить, что автобусWR когда RDсигнал неактивен, достаточно плохо, предположить, что шина находится в состоянии, RDкогда WRнеактивен, еще хуже. Я использовал предыдущую программу для первоначального тестирования, поэтому система, казалось, работала, но пропустила критическую проблему.

Во время цикла записи в память ЦПУ Z80 начинает приводить шину в движение до того, как она WR становится активной на низком уровне, в это время буфер данных все еще направляет данные к ЦП, упс, создавая конфликт шины.

Брюс Эбботт прав: лучше всегда использовать RD и WRсигнализировать независимо для управления каждым буфером, а не инвертировать один.

Например,

Теперь работает отлично.

И, наконец, опять же, приведенная выше схема является упрощением, следует также проверить, BUSACKчтобы убедиться, что буфер данных не управляет шиной во время операции DMA.

Убедитесь, что у вас есть адекватные развязывающие конденсаторы на всех ваших микросхемах. Керамика мощностью 100 нФ от питания до земли на каждой микросхеме обеспечивает максимально короткие выводы, а электролитический электролит с низким ЭПР, скажем, 100 мкФ на макетной плате через силовые шины.

Я вижу две возможности здесь:

1) D0 накачан

Что бы ни управляло, D0 переходит в трехстороннее состояние (режим с высоким импедансом), а затем понижение напряжения где-то в сети D0 медленно понижает напряжение (постоянная времени, определяемая сопротивлением опусканию и паразитными емкостями микросхем и трасс). Экспоненциальный характер формы сигнала является убедительным свидетельством того, что линия движется не чем-то сильным, а относительно слабым понижением.

Попробуйте добавить еще один понижающий резистор к линии и проверьте, не идет ли экспоненциальный сигнал быстрее к нулю.

Имейте в виду, что это не обязательно проблема, и ваш автобус может отлично с этим работать.

2) Разногласия

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

Удачи!

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