Некоторые ПЛИС-разработчики используют в своих проектах инверсную логику для внутренних сигналов ПЛИС (например, для сигналов разрешения, сброса и т.п.). Хочется услышать мнение сообщества по вопросу какие у данного подхода есть плюсы. Просто супер будет, если есть какие-либо практические данные по улучшению помехозащищенности или еще какие осязаемые профиты.

В поиске с ходу не нашлось, поэтому если баян, прошу прощения. Тогда ткните носом в тему где это обсуждалось.

Хотелось устранить пробел в знаниях и узнать, а что такое прамая или неинверсная логика для сброса или разрешения? Я всегда считал, что про сигналы сброса пишут "active low" или "active high" и нет никакой ложки. Есть конкретная микросхема, в которой либо имеется возможность применять оба вида сброса, либо есть только один.

Кстати, вот вспомнился кошмар под названием FPSLIC http://uchcom.botik.ru/boris/fpslic/errors/
Я этот текст написал по следам борьбы с ним. Посмотрите самое начало.

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

Как уже сказали, синтезатор сделает так как ему удобно.
Поэтому вопрос правильнее перевести в плоскость стилей написания и оформления модулей.
IMHO: выработыйте единые правила для себя (для фирмы) и их придерживайтесь,
когда всего намешано - труднее понимать чужой код.

Что касается помехозащищенности, то инверсные сигналы сброса и разрешения более помехоустойчивы. Если ваша ПЛИС работает вблизи мощной силовой электроники, то помехи бывают такие, что модули с прямой логикой сброса будут часто сбоить (сам с таким сталкивался).

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

А вот при проектировании ASIC полярность сигналов желательно выбирать в соответствии с конкретными библиотеками производителя. Если библиотечный триггер имеет active-high сигналы разрешения и сброса, то лучше в проекте их такими и делать. Кстати, добросовестный производитель кристаллов вам об этом скажет, когда вы будете сдавать ему проект в производство.

В общем, выбирайте инверсную логику, не ошибетесь. Большинство ПЛИС и библиотечных элементов работают как раз в ней.

Ну а теперь по жизни.
Если у Вас такая система: "Сделал проект и выкинул", то тогда можно делать как угодно, это на результате не отразится...
Но если Вы делаете изделие, которое будет жить несколько лет, то кому-то его придется сопровождать. Возможно даже и не Вам лично...
Так вот, этот кто-то и будет потом разбираться, что и как там наворочено, где ноль и где единица... Ошибок набьет кучу... Вас вспомнит тихим словом. Так что лучше не увеличивать вероятность возникновения ошибок, а все делать в положительной логике, благо компилятору это все равно...
А если Вы уже начали делать большие проекты, то тогда дело несколько другое...
Выбирите стандартную внутрикристальную шину, например Авалон, для Альтер или что-то в этом духе из распространенных шин из открытых проектов. И все сигналы интерфейса подгоняйте под стандарт такой шины. Сделайте файл соглашения о названии сигналов. Я об это
писал в "Кратком Курсе HDL". Вот теперь, если понадобится подключить Ваш проект к шине, или ввести в проект микроконтроллерное ядро, то Вам уже не понадобится никаких переделок... Да и тестбенчи можно будет использовать многократно... И такой порядок должен быть во все Вашей группе разработчиков.
Удачи!

с чего это вдруг?


ссылку на документы где "большинство ПЛИС" работают в инверсной логике.

ПЛИС, насколько я знаю, глубоко по барабану какая там логика в ней.

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

Коллеги, спасибо всем за ответы.

Не, выкидывать ничего не собираюсь. Кто знает, что тебя в будущем ждет, лучше все на совесть делать.

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

Еще в первом посте хотел написать, что не хотел бы разжигать очередную религиозную войну, так что давайте от ожесточенных споров постараемся воздержаться. Хотя ПМСМ применение инверсной логики для сигналов на плате (межэлементных) оправдано, примером чему могут служить хотя бы шины ISA и PCI.

P.S. Тему не закрываю.

О применении сигналов низкого уровня:
1. для сброса, который идет по плате/устройству. Здесь низкий уровень определяется тем, что во время подъема напряжения питания правильную лог.1 взять просто неоткуда... Поэтому открытый коллектор "давит" сброс до окончания переходного процесса. Тут вроде все понятно.
2. Дадее. По интерфейсу DEC-овских машин шины строились на компонентах с ОК. При работе инверсной логикой получали хороший передний фронт, от которого все и синхронизировались.
при переходе шин на ТТЛ-логику с 3-мя состояниями, стало все равно. Хотя уровень нуля и здесь был более мощный. А при КМОП схемах так и вовсе все равно, какая логика в шинах данных (Про сброс я уже сказал особо).

хочу дополнить - некоторые производители (Lattice) в своих IP используют как "положительную", так и "отрицательную" логику
это очень печально...

Практикуют ли это производители "железных" IP/библиотек (artisan, viragelogic, cadence, synopsys)? Или стараются придерживаться положительной логики? (Сам порвериьт не могу, все кругом confidential )

Сообщение отредактировал zverek - Aug 14 2009, 12:47

не стал бы на это расчитывать. стандарта или договоренности не существует, ну или я не знаю об этом.

Стандарта тут и правда нет. Например у MIPSа reset active high, в IP Synopsys - active low...

Вопрос как оказалось очень важный. Cell Libraries для TSMC надеюсь у всех одинаковые (h__p://w_w.synopsys.com/dw/tsmc.php h__p://w_w.cadence.com/Alliances/ip_program/Pages/tsmc_lib.aspx h__p://w_w.arm.com/products/physicalip/designstart.html)? А точнее, физически они active low? Если так, значит glock17 прав.

P.S. Если что, можно в личку

Сообщение отредактировал zverek - Aug 16 2009, 13:57

ИМНО: это проблема гонок, а не уровня (говорим о внутренних синалах), не сталкивался с подобными вещами в устройствах работающих в жестких условиях


позвольте не согласиться,
Посмотрите спецификации AVALON и WISHBONE(на них ложиться большая нагрузка по коммутации сигналов в плис), они разработанные разными производителями, а логика и там и там - прямая.