Привет всем!
Есть двунаправленная шина ввода-вывода для FPGA типа FLEX10KA, с декларацией на Verilog как:
inout [31:0] IO;
MAX+plus II запретил применить следующую запись (выдача DATA единицей на OE):
assign IO = OE ? DATA : {32{1'bz}};
а вместо неё рекомендовал применить примитив TRI (с тремя состояниями) или OPNDRN (открытый коллектор).
Тогда, следуя рекомендациям, и используя TRI, получил:
TRI aaa(DATA, OE, IO);
Однако, на выходах IO почему-то всегда нули, хотя код на DATA есть, что проверил контрольным считыванием по центру сигнала OE (его длительность 30нс), во вспомогательные регистры R1 и R2:
always @ (posedge CLK) R1<=DATA;
always @ (posedge CLK) R2<=IO;

Аналогичная ситуация с использованием OPNDRN, с конструкцией:
assign DATAx = OE ? DATA : {32{1'b1}};
OPNDRN bbb(DATAx, IO);
При этом была установлена опция "Automatic Open-Drain Pins"

Вопрос: Кто сталкивался с подобным, почему так происходит, почему не выдается информация в шину?

MAX+plus II запретил применить следующую запись (выдача DATA единицей на OE):
assign IO = OE ? DATA : {32{1'bz}};
а вместо неё рекомендовал применить примитив TRI (с тремя состояниями) или OPNDRN (открытый коллектор).
/////////////////////////////////////////////////////
Мах ничего не может запретить. Или укажет на ошибку или выдаст рекомендации.
И так как с ему все равно, как Вы опишете примитив tri, скорее всего он говорит что где то по его мнению не хватает буфера tri.
что касается примитивов tri и opndrn. Не у всех кристаллов есть открытый сток. Где его нет, он имитируется на том же примитиве tri (при наличии внешнего резистора). при этом могут быть только два состояния: 0 и z
assign out = in ? 1'bz : 1'b0;

Что-то не могу разобраться с документацией на FLEX 10KA, написано как-то заумно.
Во FLEX 10KA нет традиционных буферов с тремя состояниями, а есть только активизируемые пользователем буферы с открытым стоком?
То есть без подтягивающих на плюс резисторов здесь не обойтись?
А все внешние шины реализуются по схеме монтажного ИЛИ?

У всех кристаллов ест буфера по третьему состоянию. Мало кристаллов. у которых есть открытый сток. если память не изменяет это например семейство 7000 (CPLD). Что Вам нужно, то и реализуйте.
И то и другое должно работать. У Вас есть предупреждение. Устраните его и все заработает.
module ap6 (da, db, oe_n, dir);
inout [7:0] da;
inout [7:0] db;
input oe_n;
input dir;


assign db = (dir & !oe_n) ? da : 8'hzz;
assign da = (!dir & !oe_n) ? db : 8'hzz;

endmodule

Спасибо за ответ!
Я восстанавливаю программу для FLEX 10KA, написанную N-цать лет назад. На плате, FPGA связана шиной данных с Cache-RAM 32к*32 (IDT71V432), и на шине нет pull-up резисторов. Если FLEX 10KA имеет буферы с тремя состояниями, то явно промах мой, а если только буферы с открытым стоком - то разработчика этой платы. Если есть обе возможности, то не ясно, как переходить от одной к другой, опять же в документации на этом не акцентировали.
Я выдаю в шину код данных и проверяю его в этот момент контрольным считыванием во вспомогательный регистр, который потом просматриваю. Но пока получается, что на шине только нули.

Контекстная помощь для MAX+ дает такие разъяснения:
Help -> Verilog HDL -> Primitive -> TRI:
In ACEX 1K, FLEX 10K, and MAX 7000S projects, some configurations of TRI primitives and other logic are automatically converted into OPNDRN buffers.

Help -> Verilog HDL -> Primitive -> OPNDRN:
The OPNDRN primitive is supported only for the ACEX 1K, FLEX 10K , MAX 3000A, MAX 7000A, MAX 7000B, MAX 7000AE, and MAX 7000S device families; it is converted to an equivalent TRI primitive for other devices.

Из которых не ясно, присутствуют ли в FLEX 10KA оба типа буферов или только один.

Нет у Вас никаких ошибок по схеме соединения FPGA c памятью. Потому что Вы не посчитали нужным подтягивать шины адреса и данных в этой связке. У вас заложено третье состояние. И Вы его реализуете. Если бы вы заложили на плате физически открытый сток, то заложили бы и внешние резисторы (если их нет внутри fpga).
теперь есть указания компилятору по умолчанию. Типа Auto Open-Drain Pins logic option
вот в хелпе квартуса (A logic option that directs the Compiler to automatically convert a tri-state buffer with a strong low data input into the equivalent open-drain buffer).
Я это понимаю так:
ВЫ сами описывете выходной буфер как Вам надо в соответствии с внешней схемой. Как буфер по третьему состоянию и открытый сток. Это только Ваш выбор.
assign out = in ? 1'bz : 1'b0; - это описания примитива открытоко стока. Поведенчески. "Сильный" 0, а единца делается из z состояния с помощью резистора. (Работайте в квартсусе. Смотрите RTL просмотрщик. Такое описание имитируется на буфере tri. Вход сигна подается на вход oe буфера. На входе буфера ноль.
Так вот при включенном указании компилятору этот буфер tri в open-drain buffer, если он есть. Я это так понимаю.
Мне кажется у Вас есть ошибка. Вы хотите внешнюю шину по третьему состоянию. Вы это делаете.
assign db = (dir & !oe_n) ? da : 8'hzz;
Такое описание не подходит по моему мнению к Auto Open-Drain Pins logic option
Потому что Вы требуете три состояния на шине 0,1, z.
Потому что еще раз повторюсь на выходном буфере кристалла можно получить выход, который будет имитровать три состояния, а можно чтобы было только два. Это ВЫ САМИ для себя выбираете.
Все начилось с того что Вы получили предупреждения где фигурировали понятия tri и open-drain
такие предупреждения стандартно выдаются при использования примитива bidir, если компилятор не находит при этом необходимые с его точки зрения буфера по третьему состоянию или открытый сток.
У Вас есть возможность промоделировать проект. Получите при моделировании все возможные состояния на шине. И все. ищите ошибку в проекте.

ОЗУ имеет буфер с тремя состояниями, считаю, что FPGA должен ему выдавать 0, 1, z.
Я изменял опцию Assign-> Global Project Logic Synthesis -> Automatic Open-Drain Pins, но это ничего не меняло.

Но появилось новое обстоятельство. Мой проект выполнен в *.gdf, и включает sim-элемент PCI-ядра и sym-элемент с собственной логикой управления на Verilog (он управляет в том числе и ОЗУ). При этом все выводы FPGA были подключены к обоим эти элементам. Я удалил из sym-элемента управления примитив TRI aaa(DATA, OE, IO), который формирует шину данных IO для ОЗУ, а эту, и только эту функцию шины данных реализовал на отдельном графическом примитиве tri из библиотеки c:\maxplus2\max2lib\prim. В итоге все заработало, почти так как надо, т.е. в теперь ОЗУ записываются и считываются разные массивы информации из PCI интерфейса компьютера.
Выходит, что на HDL уровне не проходило, а в графике идет. Конечно, можно было бы подняться на Quartis II, но там, что-то это PCI-ядро компилится с ошибками. Вынужден пока работать в МАХ+.
Вопросы о двух типах буферов в одном FPGA еще остались. Не ясно как переходить от одного буфера к другому и обратно, не понятно почему запрещено assign db = (dir & !oe_n) ? da : 8'hzz; вроде как общепринятая в Verilog конструкция. Жаль, микросхема старовата, на ней сейчас видно уже мало кто работает.

У меня такое ощущение, что я вас окончательно запутал. Нет никакой разницы, каким образом вы описываете проект, в графике или текстом. Как я понял FPGA сидит на шине PCI. Озу сидит на локальной шине, сформированной в FPGA. Ну какие тут могут быть пробемы. перенос описания шины взаимодействия ОЗУ с FPGA (это двунаправленный порт и буфер по третьему состоянию) из вашего сима на верхний уровень иерархии может говорить только о том, что на локальной шине вместе с ОЗУ еще кто то сидит. При таком раскладе управление шиной делают на верхнем уровне проекта.
Еще раз повторю. Синтезатор ничего никому не запрещает. Он может что то выкинуть, если считает, что это что то не имеет смысла (ведь у Вас по умолчанию включена оптимизация проекта). или указать, что чего то не хватает. И тоже скажет об этом.
Не надо вам думать о том как переходить от одного буфера к другому. Все опции в синтезаторе имеют совсем другой смысл.
Итак у вас есть память на которой присутствуют состояния 0,1,Z. Вы описываете как общепринято. Если что то не получилось это Ваша ошибка. потому что синтезатор не ошибается.
(Что касается Я изменял опцию Assign-> Global Project Logic Synthesis -> Automatic Open-Drain Pins, но это ничего не меняло. При Вашем описании шины и не должно было что то меняться. Еще раз повторю. Это опция относиться только к пинам, которые Вы хотите описать как пин с открытым стоком. Такое описание автоматом будет реализоваться на примитиве открытого стока. А если такой примитив нельзя реализовать в кристалле, он будет имтитроваться на притиве tri. И все равно Вы получите открытый сток. )
В Вашем случае нет описания открытого стока . Значит и физически его не будет. Нет смысла что то смотреть осциллографом. (Кстати все эти Ваши нули при исследовании вполне могут оказаться Z состоянием. У МОП структур этот уровень ближе к нулю и отличен от уровней ТТЛ структур.)
Все это должно моделироваться. А результаты моделирования получите в железе однозначно. Нет понятия старая микросхема. И пакет MAX+ тоже не причем. Все проходили pci шину в MAX+

Спасибо, sazh, за ответы.
Но есть еще вопрос по inout-шинам, понимаю, что он узко-специфичен, но может, кто-то в курсе дела...
Как уже писал, восстанавливается программа для существующей платы, там FLEX 10K30A связана с тремя независимыми RAM. Две из RAM уже работают, а вот третья - для нее уже не было обычных выводов, по этому были задействованы выводы двойного назначения. Это так называемые Dual-Purpose Configuration Pins: nWR, nRS, nCS. CS, RDYnBUSY and CLKUSR. Они здесь нужны как выводы с тремя состояниями, под шину данных RAM.
Программирую и вижу, что там трех состояний нет, а только 0,z (при контрольных считываниях всегда нули). Уточнил в Help MAX+Plus II, а там в “Help->FLEX 10K and ACEX 1K Global Project Device Options Dialog Box”, написано, что если установить опцию Tri-State в ON для данного типа выводов, то данный вывод не используется, что дословно так: "if the Tri-State option is turned ON “the pin is not used as an I/O pin in during user mode”. То есть, как бы есть, и как бы нет этого Tri-State. Как с этими выводами управиться, именно в режиме Tri-State?

Что касается пинов двойного назначения.
Здесь надо рассматривать по моему мнению временные интервалы конфигурации (для различных режимов конфигурирования кристалла) и пользовательский режим.
Если стандартные контакты i/o в интервале конфигурации все в состоянии z (у кого есть подтягивающие резисторы, у кого нет), то для контактов двойного назначения состояния z автоматом не предусмотрено. И не понятно в каком состоянии они будут в интервале конфигурации (вход, неподключен)
Как я понимаю предлагается самому выбрать, что делать с таким пином.
Наверно max+ говорит, что если такому пину задать опцию tri (он будет как вход tri), но уже в пользовательском режиме этот пин уже нельзя будет использовать как i/o пин.
Поэтому если галочек не ставить и меньше знать, то в пользовательском режиме по умолчанию такой пин станет i/o. А значит к нему можно подключить двунаправленную шину, которая без буфера по состоянию z работать не будет по определению. (А вот какие уровни на этих пинах будут в интервале конфигурации, не вступят ли они в конфликт с памятью в этом интервале. Например первое включение, ПЗУ пусто, вы находитесь в интервале конфигурация долгое время.)
Еще раз повторюсь, что касается пользовательского режима (с глобальными установками по умолчанию) эти пины должны конфигурироваться как i/o и обмен с памятью должен моделироваться со всеми состояниями 0,1,z

Мне, видно, придется сделать заставку из этих слов на своем рабочем столе.
Нашел я причину своих мытарств, опять же на основе симуляции частей схемы в MAX+. Вся причина во временных задержках FPGA, они иногда были достаточно велики для PCI-шины. А tri-state есть, как ему и положено на всех выводах.
sazh, спасибо за помощь и приношу извинения, что отвлекал.