[justontime 0]

В процессе выяснения причин сбоев моей схемы на 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 - кажется мне, что здесь что-то намного проще...

 

[SM 0]

Проблема, скорее всего, в том, что FPGA слишком шустрая, и снимает данные очень быстро. По времянкам, мы имеем, что:

1) TCLDX = 10 ns (min) - это означает, что после фронта T3 данные на шине должны быть стабильны минимум 10 нс.

2) TCLMH = 10 ns (min) - это означает, что MRDC может сняться через 10 нс после T3.

3) эти сигналы формируют разные микросхемы, поэтому между ними имеется некий перекос клока. Я его могу оценить по косвенным признакам на 4..5 нс (MAX) (разная длина разводки, разная емкость входов, разброс порогов).

 

таким образом, если у нас TCLDX и TCLMH на минимуме (ну или совсем около минимума, вплоть до 3 нс), а clock skew на максимуме, причем не в пользу ситуации, то имеем: FPGA снимает данные, допустим, за 2 нс, то есть, Tpd (mrdc->D) = 2 нс. Итого получаем проблему: TCLMH(10ns)-skew(5нс)+Tpd_fpga(2ns)-TCLDX(10 нс) = -3нс - отрицательный запас, что означает нарушение. Если бы там стояла не FPGA, а их древнючий 8286, у которого Output Disable Time не 2 нс, а больше, чем 10 нс, то этого Вы бы и не заметили.

 

Что делать? А очень просто:

1) по MRDC/IORC защелкивать в FPGA нужное данное от нужного источника, а буфером управлять от DT/R - это абсолютно железобетонно

или

2) разрешить bus holder-ы на шине у FPGA - они будут хранить при помощи слабой подтяжки данное после переходе в 3-е состояние - это среднесопливо

или

3) констрейнами попробовать заставить сделать Tpd(mrdc->D) не менее, чем 10 нс, если, конечно, среда разработки смогет. XILINX, например, не умеет холды констрейнить, нарывался уже. Это тоже железобетонно, но, только, если среда позволяет.

 

И, совершенно не ясно, на кой Вам понадобилась 74373, это тоже в FPGA надо по идее делать.

[justontime 0]

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

 

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

 

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

 

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

[SM 0]

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 0]

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

 

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

 

 

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

 

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

 

и все.

 

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

 

[SM 0]

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

 

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

 

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

 

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

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

DT/R специально для этого придуман, для управления буферами.

[justontime 0]

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

DT/R специально для этого придуман, для управления буферами.

 

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

 

 

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

 

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

Изменено 17 декабря, 2014 пользователем justontime

[SM 0]

Пожалуй, Вы правы, не все так просто, когда буфера быстрые...

 

надо управлять направлением по логике DEN & !DT_R, но подзадержанной через констрейн в FPGA так, чтобы не нарушать времянку TCLDX с учетом перекоса клоков между 8088 и 8288 и шустростью буферов. А сигнал OE у буфера оставить всегда разрешенным - чтобы он передавал данные в FPGA всегда, когда процессор не читает данное.

 

Не, INTA не надо, там DT/R активен и так

[justontime 0]

На данный момент решил все-таки просто задержать MRDCn до ближайшего положительного фронта тактового сигнала, и использовать этот задержанный сигнал для управления буфером SRAM'а. Проведу эксперимент вечером...

 

Если вдруг случится чудо и все заработает, то пока оставлю так, а тем временем займусь изучением time constrains и т.п. вещей в FPGA...

 

 

[SM 0]

Только смотрите, чтобы уже TRHAV не нарушить - если буфер запретить слишком поздно, то может возникнуть конфликт.

 

 

И не забудьте, в таком случае, ОБЯЗАТЕЛЬНО описать констрейны типа set_input_delay для MRDC относительно клока!!!!! А то, имеете шанс еще и с метастабильностью пободаться.

[justontime 0]

Только смотрите, чтобы уже TRHAV не нарушить - если буфер запретить слишком поздно, то может возникнуть конфликт.

 

Позволю не согласиться - на мой взгляд, если буфер будет открыт до средины T4 (положительный фронт тактового сигнала, которым собираюсь сбрасывать разрешение буфера), то процессору от этого ни холодно, ни жарко. Тем более, DT/R снимается после этого фронта, так что, по моему мнению, все должно быть нормально. Теоретически :)

 

 

И не забудьте, в таком случае, ОБЯЗАТЕЛЬНО описать констрейны типа set_input_delay для MRDC относительно клока!!!!! А то, имеете шанс еще и с метастабильностью пободаться.

 

А вот это, честно говоря, вообще не понял... Просто пока не понимаю смысл :(

 

Вообще собирался делать простейшим триггером:

 

process (MRDCn, CLK)

begin

if (MRDCn = '0') then

RAMOn <= '0';

elsif (rising_edge(CLK)) then

RAMOn <= '1';

end if;

end process;

 

RAMOn - сигнал разрешения буфера SRAM с низким активным уровнем.

 

[SM 0]

Я предполагал, что все у Вас обойдется более простой реализацией:

 

if (rising_edge(CLK)) then

RAMOn <= MRDCn;

end if;

 

то есть, просто задержка на 1 такт. Для этого следует указать set_input_delay по MRDCn, чтобы разводчик FPGA корректно все внутри сделал так, чтобы setup/hold у внутреннего триггера был выдержан.

 

А вот в Вашем случае, теоретически, может быть нарушение тайминга типа "Removal" или "Recovery" (на внутреннем триггере FPGA, на асинхронный сброс которого Вы заводите MRDCn) - поэтому, нужен констрейн на них (скорее всего, это задается тем же set_input_delay для MRDCn, но я тут не уверен).

 

 

Позволю не согласиться - на мой взгляд,

А тут не с чем соглашаться, или нет, я не считал, сколько там это TCLCL-40нс, я просто предупредил.

[justontime 0]

Я предполагал, что все у Вас обойдется более простой реализацией:

 

if (rising_edge(CLK)) then

RAMOn <= MRDCn;

end if;

 

то есть, просто задержка на 1 такт. Для этого следует указать set_input_delay по MRDCn, чтобы разводчик FPGA корректно все внутри сделал так, чтобы setup/hold у внутреннего триггера был выдержан.

 

А вот в Вашем случае, теоретически, может быть нарушение тайминга типа "Removal" или "Recovery" (на внутреннем триггере FPGA, на асинхронный сброс которого Вы заводите MRDCn) - поэтому, нужен констрейн на них (скорее всего, это задается тем же set_input_delay для MRDCn, но я тут не уверен).

 

Да сколько же простейших вещей я не знаю ! :( Такая наглядная картинка - и как я раньше об этом не задумывался ??? Причем ведь не только FPGA проблема, но и вообще...

 

Да, верно - Ваш способ формировать управление буфером должен сработать без Removal или Recovery проблем, а то, что сигнал появится чуть позже (по положительному фронту Т2) вроде не должно ни на что повлиять.

 

P.S. Случайно не знаете ничего, что можно почитать насчет FPGA таймингов, но без особой заумности (на русском или английском), где разъясняются, в т.ч., базовые вещи ?

Изменено 17 декабря, 2014 пользователем justontime

[SM 0]

P.S. Случайно не знаете ничего, что можно почитать насчет FPGA таймингов, но без особой заумности (на русском или английском), где разъясняются, в т.ч., базовые вещи ?

Не надо читать (и даже искать) про "FPGA тайминги". Они ничем не отличаются от таймингов прочей цифровой техники - поэтому, следует изучить литературу по проектированию схем на цифровых микросхемах, такой просто немерено, а, касаемо FPGA, лишь изучить, как задавать эти ограничения применительно к конкретной среде разработки, для этого достаточно встроенного help-а. Проектируя FPGA, Вы проектируете точно такую же цифровую схему, собранную из набора базовых элементов, описывая эти соединения на языке описания аппаратуры, разница лишь в том, что соединяете их не пайкой, а управлением матрицей соединений внутри микросхемы.

 

Сейчас, кстати, очень мало, кто начинает работу с FPGA с этой, с правильной стороны. Большинство некорректно считают, что они ее "программируют", а не формируют цифровую схему, от чего огребают проблем по полной.

[justontime 0]

Хотя я в (далеком) прошлом программист, мне очень сложно утрясти в голове VHDL (и прочее подобное). Намного проще на бумажке набросать хотя бы приблизительную схему, и уже по ней пытаться что-то сделать. Я бы вообще делал бы большую часть схемным дизайном, но тот же Quartus не очень под это дело заточен...

 

Только вот Вы правы насчет необходимости знания общих основ проектирования - а у меня этих основ просто нет. Все, что есть - самостоятельные "исследования", причем элементы схемы для меня идеальны, без задержек и кривых сигналов. Соответственно, как только столкнулся с реальной жизнью, как это сразу и вылезло...