[TRILLER 0]

Здравствуйте.

Кто может уверенно сказать, можно ли делать так, как показано на схеме 2.

Кристалл V6. Использован вход синхронного ресета.

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

[vetal 0]

Синхронный сброс - по факту является маской по И входных данных.

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

http://ens.ewi.tudelft.nl/Education/course...ston_Resets.pdf

[Beby 5]

Да и вообще, есть ли какая либо разница на железном уровне между синхронным и асинхронным входами ресета?

Эээ... а вход-то в Slice - один... а способ его использования (синхронный/асинхронный) задаётся атрибутом - можете всё сами разглядеть при помощи FPGA Editor'a.

 

А т.к. вход один на весь Slice, то он заходит на все триггеры в Slice. Соответственно, если в схеме нет триггеров, которым нужен такой набор управляющих сигналов (CLK, CE, RST), то тогда неиспользованные в этом Slice триггеры не смогут быть использованы. Поэтому уникальные наборы управляющих сигналов необходимо использовать с умом.

[TRILLER 0]

Синхронный сброс - по факту является маской по И входных данных.

Этот факт реализован непосредственно в самом триггере? Ни на один из входов лата этот сигнал не поподает.

 

Эээ... а вход-то в Slice - один... а способ его использования (синхронный/асинхронный) задаётся атрибутом - можете всё сами разглядеть при помощи FPGA Editor'a.

Вход в слайс то один, а вот в триггеры уже 2, стало быть между ними есть какая-то разница.

 

В общем, пришёл к выводу, что схему 2 использовать можно, так как Симплифай(провёл эксперимент) сам заводит выход лата на синхронный ресет, для уменьшения слоёв логики. А люди, его делавшие, скорее всего разобрались с этим вопросом..

 

[Beby 5]

Этот факт реализован непосредственно в самом триггере? Ни на один из входов лата этот сигнал не поподает.

Ответы находятся в FPGA Editor'е, которым я настоятельно рекомендовал посмотреть Ваш кристалл, чтобы Вы не писали ахинею:

Вход в слайс то один, а вот в триггеры уже 2, стало быть между ними есть какая-то разница.

Ну вот расскажите мне: где тут "второй вход сброса в триггер" ? Я его, почему-то в упор не вижу...

Зато вижу тут атрибут RESET TYPE: SYNC/ASYNC, о котором и писал ренее.

[Bad0512 2]

Почитайте вот эту, ставшую уже классикой, статью Кена Чапмена о вреде и пользе разных типов ресета.

[TRILLER 0]

Ну вот расскажите мне: где тут "второй вход сброса в триггер" ? Я его, почему-то в упор не вижу...

Да, я был не прав..

Почитайте вот эту, ставшую уже классикой, статью Кена Чапмена о вреде и пользе разных типов ресета.

Полезная статья. Вот только ни в одном примере на вход SR триггера он не заводит выход лата. Меня конкретно это интересовало. Но, поверю симплифаю и попробую это сделать)

 

[Bad0512 2]

Полезная статья. Вот только ни в одном примере на вход SR триггера он не заводит выход лата. Меня конкретно это интересовало. Но, поверю симплифаю и попробую это сделать)

А зачем заводить выход LUTа? Это наверняка отрицательно скажется на тайминге. Правильно выход LUTa защёлкнуть в триггере, а потом уже подавать на SR.

Это приведёт к задержке на 1 такт, но в большинстве случаев это некритично.

 

 

[Beby 5]

Вот только ни в одном примере на вход SR триггера он не заводит выход лата. Меня конкретно это интересовало.

Да, можно подавать данные с выхода LUT на синхронный вход SR триггеров. Но только на синхронный SR, если не хотите поиметь кучу проблем с асинхронщиной.

Более того, при синтезе сложных логических функций синтезаторы периодически сами синтезируют схемы в которых используются D, CE и SR, на которые подаются сигналы с выходов LUT'ов.

 

А зачем заводить выход LUTа? Это наверняка отрицательно скажется на тайминге. Правильно выход LUTa защёлкнуть в триггере, а потом уже подавать на SR.

Это приведёт к задержке на 1 такт, но в большинстве случаев это некритично.

Да, скажется, но практически незаметно. Но зато может позволить реализовать очень вычурную логическую функцию с Logic Level = 1.

 

Единственным существенным (для Xilinx V-5/S-6 и более новых) является наличие уникального набора CE, SR, CLK, что с большой долей вероятности приводит к невозможности использования остальных триггеров в Slice. Но, иногда, даже такие жертвы - оправданы.

[TRILLER 0]

Да, можно подавать данные с выхода LUT на синхронный вход SR триггеров. Но только на синхронный SR, если не хотите поиметь кучу проблем с асинхронщиной.

Это именно то, что я хотел узнать - не будет ли проблем)

 

Да, скажется, но практически незаметно.

В DS152 сказано, что

"TITO An – Dn inputs to A – D Q outputs 0.67" для V6-2

в то время, как

"TRQ Delay from SR input to AQ – DQ flip-flops 0.58".

Выходит, что будет даже лучше по времянке. Или я ошибаюсь?

[Beby 5]

В DS152 сказано, что

"TITO An – Dn inputs to A – D Q outputs 0.67" для V6-2

в то время, как

"TRQ Delay from SR input to AQ – DQ flip-flops 0.58".

Выходит, что будет даже лучше по времянке. Или я ошибаюсь?

К сожалению, Вы ошибаетесь: не совсем то сравниваете:

1. TITO (An – Dn inputs to A – D Q outputs) - это задержка от изменения входов LUT до появления устойчивых данных на выходе Slice (актуально для первого LUT'а Вашей схемы). А второй LUT вашей схемы, если я ничего не путаю, описывается TILO (An – Dn LUT address to A = 0.07ns) + TDICK (A – D input to CLK on A – D Flip Flops = 0.36ns), итого 43ns.

2. TRQ (Delay from SR input to AQ – DQ flip-flops) - это задержка реакции триггера на асинхронный Reset (задержка от прихода SR до изменения Q триггера). А Вам нужно TSRCK (SR input to CLK on A – D Flip Flops = 0.44ns) - время предустановки для SR входа.

Т.е. получается, что разницы практически нет... Если я нигде не ошибся.

 

Также необходимо учитывать, что использование LUT -> MUXF7 (или MUXF8) -> D вход триггера может дать более интересный результат.

 

Для каждого семейства ПЛИС необходимо проверять всё это в Timing Analyzer'е, ибо не всё можно рассчитать по данным из Data Sheet, да и он ошибается значительно реже, чем сам разработчик.

[Bad0512 2]

Да, скажется, но практически незаметно. Но зато может позволить реализовать очень вычурную логическую функцию с Logic Level = 1.

Всё не так просто. При использовании триггера задержка будет складываться из трёх частей : 1 Tcko триггера 2 Net delay (цепь внешняя, задержка довольно велика) 3 Trstin того блока, который сбрасываете.

В случае с LUT без триггера задержка будет состоять из 5 частей : 1 Tcko триггера - источника ресета (тот что перед LUT). 2 Net delay (внешняя цепь от источника ресета до LUT) 3 задержка собственно в LUT 4 Net delay (внешняя цепь от LUT до приёмника RESET ) 5 Trstin приёмника ресета.

Итого : во втором случае - 2 внешних цепи и LUT delay - наибольшие задержки. На высоких частотах это может быть проблемой.

 

 

[Beby 5]

Всё не так просто...

Да чего ж тут сложного-то ? Вы всего лишь утверждаете, что с pipelining’ом схема сможет работать на большей частоте. Ну, сможет - и что ? (Этот факт, как раз, никто и не оспаривал) Но у pipelining есть свои недостатки, поэтому он не везде применим. Первичный-то вопрос стоял не в целесообразности применения pipelining'а, а «как сделать так, чтобы было побыстрее, да еще и без pipelining». И, кстати, схемы без pipelining'а, как правило, обладают меньшей латентностью (в нс), чем работающие на большей частоте pipeline схемы. Посему, в каждом конкретном случае приходится выбирать, что критичнее: латентность или частота - универсального ответа - нет.

[Bad0512 2]

Да чего ж тут сложного-то ? Вы всего лишь утверждаете, что с pipelining’ом схема сможет работать на большей частоте. Ну, сможет - и что ? (Этот факт, как раз, никто и не оспаривал) Но у pipelining есть свои недостатки, поэтому он не везде применим. Первичный-то вопрос стоял не в целесообразности применения pipelining'а, а «как сделать так, чтобы было побыстрее, да еще и без pipelining». И, кстати, схемы без pipelining'а, как правило, обладают меньшей латентностью (в нс), чем работающие на большей частоте pipeline схемы. Посему, в каждом конкретном случае приходится выбирать, что критичнее: латентность или частота - универсального ответа - нет.

Ок, видимо я не до конца понял постановку задачи. Я думал надо сделать "быстро", а оказывается надо сделать "_вот_таким_странным_способом_", да вдобавок ещё и "быстро". Тогда встречный вопрос (но уже не к вам, а скорее к ТС) : какой смысл в использовании такой конструкции? Грубо говоря, какая конечная цель?