Работа шины процессора 8088 Опции

[justontime]

В процессе выяснения причин сбоев моей схемы на 8088 процессоре все более отчетливо начало появляться подозрение, что проблема не в помехах, а в неправильных времянках самой схемы.

К сожалению, публиковать здесь схему нет особого смысла - вряд ли кто захочет тратить время на разбирательство с дикой смесью VHDL и схемного дизайна в Quartus'е, поэтому пока на словах:

Процессор работает в максимальном режиме с использованием 8288. На моей платке установлены 8088, 8284, 8288 и 74373 (защелка младших адресов по ALE). Далее все это уходит в отладочную плату FPGA, на которой, в частности, есть SRAM, используемая процессором.

Память подключена очень просто, без какого-либо дополнительного контроллера памяти. На /CS подается сигнал от дешифратора адреса, на /OE - /MRDC, на /WE - /AMWC. И еще по сигналу /MRDC шина данных памяти подключается к шине данных процессора (естественно, все происходит внутри FPGA).

Так вот, при анализе всей имеющейся информации по сбоям у меня появилась мысль попробовать удлинить время, на которое шина данных памяти подключена к процессору. Для этого я вместо сигнала /MRDC использовал сигнал DT/R.
И вот после этого схема проработала без сбоев всю ночь.

К сожалению, есть две проблемы:

1. При таком подходе не понятно, как отделить чтение памяти от чтения ввода-вывода, если адреса портов совпадают с адресным пространством памяти. Но даже это не проблема, проблема вот:
2. А почему это все-таки происходит ??? Первоначальная схема, по идее, правильная (даже, скажем, классическая). Процессор защелкивает данные при чтении по окончании T3, а сигнал /MRDC снимается заметно позже, т.е. проблемы изначально быть не должно. Конечно, могу подержать данные из памяти на шине на пол такта дольше, но это какой-то странный костыль получается...

Как уже мне неоднократно советовали в предыдущей теме, можно посмотреть на констрейны FPGA. Только с этим тоже есть пара проблем:

1. Исключительно по внутренним ощущениям, не должны имеющиеся цепи вносить такие задержки, что это так критично сказывается на вроде совершенно некритичном месте...
2. Ну не умею я работать с констрейнами, весь мой опыт с FPGA - десятка полтора часов в общей сложности И опять таки, смотри п.1 - кажется мне, что здесь что-то намного проще...

[justontime]

SM - спасибо за участие !

1. Попробую - хотя тоже на костыль похоже. Правда, слегка поэлегантнее

2. Быстро погуглил - не понял, о чем речь. Не можете пальцем ткнуть, если не очень сложно (у меня FPGA - Altera) ?

3. Могу отмазаться красиво, но честно скажу причину - быстро не придумал, как понять направление шины адреса/данных в каждый отдельно взятый момент (а именно - как переключить пины FPGA на прием для чтения адреса с AD0-7 именно на нужное время, чтобы этот адрес защелкнуть внутри FPGA). Если же адресную составляющую убираем, то все становится очень просто.

[SM]

2. Быстро погуглил - не понял, о чем речь. Не можете пальцем ткнуть, если не очень сложно (у меня FPGA - Altera) ?

Это про что? Про bus holder? Или про констрейн? Альтера (более-менее современная) умеет и то, и это.

3. Могу отмазаться красиво, но честно скажу причину - быстро не придумал, как понять направление шины адреса/данных в каждый отдельно взятый момент (а именно - как переключить пины FPGA на прием для чтения адреса с AD0-7 именно на нужное время, чтобы этот адрес защелкнуть внутри FPGA). Если же адресную составляющую убираем, то все становится очень просто.

Дык они всегда на приеме (кроме, как Вы их по DT/R или MRDC на передачу переключаете). Так что их не надо дополнительно переключать.

Код

always @(posedge ale)
  if (ale)
      addr[7:0] <= ad[7:0]

и все.

[justontime]

Это про что? Про bus holder? Или про констрейн? Альтера (более-менее современная) умеет и то, и это.

Пока только насчет bus holder - с констрейнами, думаю, так просто не разобраться... У меня Cyclone IV E

Дык они всегда на приеме. Их не надо переключать.

Код

always @(posedge ale)
  if (ale)
      addr[7:0] <= ad[7:0]

и все.

Извините - ввел в заблуждение. Естественно, не пины FPGA, а согласователи уровней 8T245 на моей плате - им нужно в явном виде сказать направление передачи. До этого пробовал согласователи с автоматическим выбором направления TXB0108, но с ними как-то странно работало.

[SM]

Пока только насчет bus holder - с констрейнами, думаю, так просто не разобраться... У меня Cyclone IV E

Там же, где и pull up / pull down, в описании I/O пинов, где и по ногам сигналы раскидывали.

А констрейны не сложнее, один set_min_delay

Извините - ввел в заблуждение. Естественно, не пины FPGA, а согласователи уровней 8T245 на моей плате - им нужно в явном виде сказать направление передачи. До этого пробовал согласователи с автоматическим выбором направления TXB0108, но с ними как-то странно работало.

Так тем же DT/R, вместе c INTA, и переключать. Это единственные два случая, когда данные идут в процессор.
DT/R специально для этого придуман, для управления буферами.

[justontime]

Так тем же DT/R, вместе c INTA, и переключать. Это единственные два случая, когда данные идут в процессор.
DT/R специально для этого придуман, для управления буферами.

Естественно, с самого начала я об этом и подумал. Но потом не понял взаимоотношение TCHLL и TCHDTL. Просто у TCHDTL не указано минимальное время (смотрел datasheet 8288). Поэтому у меня возникло опасение, что DT/R может сняться раньше, чем ALE.


Кстати, не совсем понял насчет INTA - разве его нужно учитывать для управления буфером ??? Я был уверен, что одного DT/R для управления буфером вполне достаточно (если не рассматривать мои заморочки с ALE), т.е. при цикле INTA процессор сам выставит DT/R в правильное состояние.

Конкретно в моей плате направление согласователей уровня на шине AD управляется только сигналом DT/R, при этом прерывания нормально работают. Или я как-то не так понял Ваши слова ?

Сообщение отредактировал justontime - Dec 17 2014, 11:16