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

Проблема, скорее всего, в том, что 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 надо по идее делать.

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

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

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

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

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


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



и все.

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




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

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

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


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

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


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

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

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

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

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

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

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

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


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

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




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

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

process (MRDCn, CLK)
begin
if (MRDCn = '0') then
RAMOn <= '0';
elsif (rising_edge(CLK)) then
RAMOn <= '1';
end if;
end process;

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

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

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нс, я просто предупредил.

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

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

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

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

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

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

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

а уписать 8088 в циклон не получится? и освободиться вообще от этой платы

Есть еще вариант - взять мой нынешний компьютер на фиг знает каком жутко крутом процессоре, и вообще не мучиться

Вообще весь смысл затеи в том, чтобы сделать что-то типа XT совместимого компьютера, но с настоящим процессором (и некоторыми другими основными микросхемами обвязки). Т.е. с утилитарной точки зрения смысла, естественно, нет никакого

А так есть куча проектов, где полностью внутри FPGA не то, что XT, а нормальные AT сделаны...

Это, на самом деле, абсолютно нормально. Для начала, так и надо делать - начинать со схем, а потом вникать, как ту, или иную схемотехническую конструкцию, описать на HDL. А уже потом уходить в какие-то более абстрактные абстракции возможностей описания аппаратуры.
Вот Вам в помощь документик полезный. Он, хоть, и не про альтеру, и не про VHDL (на него сами перенесете с верилога), но, начиная со стр.6-10 там очень подробно расписано, какие языковые конструкции синтезируются в какие схемотехнические элементы (к сожалению, по VHDL я такого не знаю):

Во, я такой документ (правда, по VHDL) как раз искал, спасибо !

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

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

Пока думаю над тем, как поточнее локализовать причину, или хотя бы добиться большей регулярности сбоя.

Значит, она не совсем там. Однозначно, на этом пути: память->FPGA->транслятор->проц, но она может быть на любом из этих участков... Нет там никаких случайных помех, с вероятностью 99%

Вряд ли кому это реально интересно, но для полноты картины...

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

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

И после этого все заработало ! Пока нет особого желания разбираться в самых корнях проблемы, но навскидку ничего не вижу - вроде адрес и так должен держаться процессором с большим запасом (младшие 8 и старшие 4 линии я и так, естественно, защелкивал). Пока устраивает, что заработало, и ладно.