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

[BSV]

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

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

[yes]

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

[zverek]

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

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

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

[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. Офф. А если разработчик уходит, то он по хорошему и должен какое-то время поддерживать свои "произведения", пока в них не освоятся те, кто идет ему на смену. А если есть "правила хорошего тона" - то это заранее означает то, что и "правила увольнения пинком под зад", причем реально и нередко применяемые, тоже есть.