Инверсная логика сигналов внутри ПЛИС, Насколько это полезно? Опции

[BSV]

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

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

[Shtirlits]

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

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

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

[SFx]

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

[Builder]

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

[glock17]

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

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

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

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

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

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

[iosifk]

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

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

[Mahagam]

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

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

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

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

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

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

[BSV]

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

Ну а теперь по жизни.
Если у Вас такая система: "Сделал проект и выкинул", то тогда можно делать как угодно, это на результате не отразится...
Но если Вы делаете изделие, которое будет жить несколько лет, то кому-то его придется сопровождать. Возможно даже и не Вам лично...

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

Так вот, этот кто-то и будет потом разбираться, что и как там наворочено, где ноль и где единица... Ошибок набьет кучу... Вас вспомнит тихим словом. Так что лучше не увеличивать вероятность возникновения ошибок, а все делать в положительной логике, благо компилятору это все равно...

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

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

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

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

[iosifk]

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

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

[yes]

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

[zverek]

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

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

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

[yes]

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

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

[ArMouReR]

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

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

[zverek]

в 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

[yura-w]

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

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

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

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

[Victor®]

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


Посмотрите спецификации AVALON и WISHBONE, они разработанные разными производителями, а логика и там и там - прямая.

Не в тему... но какое-то печальное это название - Avalon :-)
http://ru.wikipedia.org/wiki/Авалон

[SM]

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

Ничего святого у них нет. У того жу артизана, как и у синопсиса, только у одних мемори компилеров можно найти в одном блоке прямой чипселект и инверсный WE. На мой взгляд - если инверсная логика позволяет сэкономить на паре транзюков в блоке или микроватт по питанию - то нужно юзать ее. Если нет - нет. В общем дело сугубо личное, только не забыть какой нибудь понятный для себя принцип именования цепей для той или иной логики. И внимательно читать доки на IP. Остальное сделает синтезатор за вас.

Вопрос как оказалось очень важный. Cell Libraries для TSMC надеюсь у всех одинаковые

У меня для TSMC есть штук 8 разных либов разных разработчиков. И артизаны, и авант, и кажется aspec. так там хватает и триггеров с инверсными сетами-резетами, и с прямыми. Имеется в виду именно физически. Опять ничего святого Все на откуп синтезу. Где-то ему выгодно воткнуть триггер с инверсным резетом, а где-то инвертор и пять триггеров с прямым

[Mahagam]

2 SM:
речь про ПЛИС. а им, насколько я помню, абсолютно параллельно какая логика.

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

[SM]

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

Да??? Про ПЛИС??? А зачем тогда про либы TSMC спрашивали? Какое они к ПЛИС отношение имеют? А для ПЛИС, кстати, инвертированность сигналов играет некую роль, так как часть сигналов идет кроме входов других LUT еще и на клоки, асинхронные сбросы, разрешения, и т.п., которые имеют фиксированную полярность, разрешения клоков, как правило, в положительной логике, асинхронные сигналы (сброс, предустановка) в отрицательной. Как и у блоков памяти логика управляющих сигналов фиксирована. Так что изредка синтезатору приходится либо втыкать лишний LUT, либо делать "NOT gate push-back", перенося инвертор с выхода триггера на его вход, если нет возможности включить инвертор по выходу регистра, о чем аж варнинг скажут (ну и подпоганивание в части различия поведения регистра при симуляции до синтеза и после разводки).

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

Мне кажется, что "правила хорошего тона" это обуза для проектировщика, выдуманная злобным начальником. Лучшие правила хорошего тона те, с которыми проектировщик сам решает задачу быстрее, все остальное, включая поддержку, надумано. Если разработчику привычнее, что резет нулем, то пусть так и будет.

PS. Офф. А если разработчик уходит, то он по хорошему и должен какое-то время поддерживать свои "произведения", пока в них не освоятся те, кто идет ему на смену. А если есть "правила хорошего тона" - то это заранее означает то, что и "правила увольнения пинком под зад", причем реально и нередко применяемые, тоже есть.