D-триггер c входами С и ENA., Где бы найти логическую схему? Опции

[Serhiy_UA]

Может, у кого есть схема с логическими элементами внутри D-триггера c входами С и ENA (Clock Enable), то просьба поделиться, а то не могу никак найти.
Ситуация с переключениями на входе С при постоянных уровнях 0 или 1 на входе ENA понятна по определению самих этих входов.
Но интересует такая вещь. Как будет вести себя D-триггер при переключениях на входе ENA, при постоянных уровнях 0 или 1 на входе С…
Провожу небольшой курс по синтезу цифровых автоматов, вот и запнулся…

[Lerk]

Вообще для gated-clock есть совершенно "безопасный" дизайн, поэтому не вижу причин его не использовать. Картинка из Титце Шенка.


Ну и все таки 'clock enable' это одно, а mux на входе - совсем другое. И собственно изменение данных на выходе mux'a в момент фронта тактового импульса может привести к самым разным последствиям.

[Krys]

Вообще для gated-clock есть совершенно "безопасный" дизайн, поэтому не вижу причин его не использовать

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

Ну и все таки 'clock enable' это одно, а mux на входе - совсем другое

По какому параметру совсем другое? Понятно, что буквы названия другие. А по потреблению ресурсов - примерно та же байда ))

И собственно изменение данных на выходе mux'a в момент фронта тактового импульса может привести к самым разным последствиям.

Дак по идеологии синхронного дизайна не надо так делать (в момент фронта). Либо ставьте на сигнал управления мультиплексором такой же синхронизатор, как на Вашей картинке.

[Lerk]

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


По какому параметру совсем другое? Понятно, что буквы названия другие. А по потреблению ресурсов - примерно та же байда ))


Дак по идеологии синхронного дизайна не надо так делать (в момент фронта). Либо ставьте на сигнал управления мультиплексором такой же синхронизатор, как на Вашей картинке.

Не надо сравнивать ПЛИС с ASIC'ами. У ПЛИС много плюсов, но не надо ориентироваться на применяемые там решения, как на парадигму.

Совсем другое оно по смыслу. У вас от этого клока может быть целый блок затактирован, и гораздо проще(и выгоднее) управлять одним клоком блока, чем всеми входами этого блока, не находите?

Что касается синхронного дизайна, то автор о нем не упоминал. А я же скажу так: всякий инструмент нужен к месту.

[Krys]

Не надо сравнивать ПЛИС с ASIC'ами

А в асиках не так как в плисах? Насколько я знаю, логика для асиков сначала отлаживается на плис, следовательно, применяются все те же методологии, в т.ч. и синхронного дизайна.

Совсем другое оно по смыслу. У вас от этого клока может быть целый блок затактирован, и гораздо проще(и выгоднее) управлять одним клоком блока, чем всеми входами этого блока, не находите?

Выгоднее, но в доках от производителей плис рекомендуется всё же обходиться без gated clock. А там где это действительно требуется - существует специальный элемент типа BUFGCE, который обеспечивает примерно то же, что на Вашей картинке. Тем более речь идёт об одном триггере, о его схеме с CE.

Что касается синхронного дизайна, то автор о нем не упоминал.

Я так думаю, если не упоминал - то это хуже. Скорее всего, для него это открытие )) Зато я упоминал, что асинхронщина устарела. А не устарел - синхронный дизайн.

[Lerk]

А в асиках не так как в плисах? Насколько я знаю, логика для асиков сначала отлаживается на плис, следовательно, применяются все те же методологии, в т.ч. и синхронного дизайна.

Не надо мешать в кучу логику и схемотехнику.

Выгоднее, но в доках от производителей плис рекомендуется всё же обходиться без gated clock. А там где это действительно требуется - существует специальный элемент типа BUFGCE, который обеспечивает примерно то же, что на Вашей картинке. Тем более речь идёт об одном триггере, о его схеме с CE.

Да мне, в общем, не важно, что там рекомендуют производители плис: у самого голова на плечах есть.

Я так думаю, если не упоминал - то это хуже. Скорее всего, для него это открытие )) Зато я упоминал, что асинхронщина устарела. А не устарел - синхронный дизайн.

Вы слишком категоричны. Асинхронный дизайн может быть в десятки раз компактнее, чем синхронный, и при этом не проигрывать по скорости. Просто это сложнее и менее предсказуемо. Вот только когда вы ограничены сверху по емкости кристалла, как в случае с БМК, то вы сразу наплюёте на свои убеждения о асинхронном дизайне. Потому что работа должна быть сделана, и в конечном итоге роляет только одно: деньги. И если можно на маленьком и дешевом БМК сделать то же самое, что на большом и дорогом, то выбор вполне очевиден. Разве что вы сами себе начальник и можете себе позволить тратить лишние бабки на угоду своим убеждениям.

[Serhiy_UA]

Как обустроен D-триггер для синхронных FSM мне уже понятно: там перед его D-входом двухвходовой коммутатор, управляемый сигналом микрооперации. Понятно и то, что период синхроимпульсов должен быть таким, что бы исключить гонки. При этом синтез FSM на HDL построен так, что пользователь об этом коммутаторе может даже и не знать, все делается за него.
Не понятным остается только вопрос, как распределяется синхросигнал на все синхровходы D-триггеров для больших FSM, ведь там этих триггеров может быть несколько сотен и даже тысяч. А фаза при этом должна быть у всех одинакова. И так для каждой из FSM, работающей на своей частоте, которых в ПЛИС тоже может быть немало.
Понятно, что среда программирования делает все автоматически, но на каких идеях…

[Krys]

Не понятным остается только вопрос, как распределяется синхросигнал на все синхровходы D-триггеров для больших FSM, ведь там этих триггеров может быть несколько сотен и даже тысяч. А фаза при этом должна быть у всех одинакова. И так для каждой из FSM, работающей на своей частоте, которых в ПЛИС тоже может быть немало.
Понятно, что среда программирования делает все автоматически, но на каких идеях…

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

Не надо мешать в кучу логику и схемотехнику.

Ну почему же... это всё очень тесно взаимосвязано. Логика без схемотехники никуда. А схемотехника в принципе одна и та же, что в ПЛИС, что на рассыпухе, что в ASIC.

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

Вот мне стало интересно: Вы теоретик или практик? "Прошивки" для БМК разрабатывали? Спрашиваю не с целью помериться пиписьками. Просто чувствуется у Вас фундаментальный, энциклопедический подход.

Вы слишком категоричны. Асинхронный дизайн может быть в десятки раз компактнее, чем синхронный, и при этом не проигрывать по скорости. Просто это сложнее и менее предсказуемо. Вот только когда вы ограничены сверху по емкости кристалла, как в случае с БМК, то вы сразу наплюёте на свои убеждения о асинхронном дизайне. Потому что работа должна быть сделана, и в конечном итоге роляет только одно: деньги. И если можно на маленьком и дешевом БМК сделать то же самое, что на большом и дорогом, то выбор вполне очевиден. Разве что вы сами себе начальник и можете себе позволить тратить лишние бабки на угоду своим убеждениям.

Честно признаюсь: мало знаком с кухней подготовки ASIC, поэтому вопрос: неужели и вправду делают сейчас такие вот асики на основе асинхронного дизайна? А как же его верифицировать? Есть для этого инструменты?
Я конечно когда-то давно слышал статьи, что вот новая технология асинхронного дизайна - хорошо забытое старое - что мол позволяет выжать всё возможное из логики, работает однозначно быстрее синхронного дизайна. Особенность в этом забытом старом было в том, что для достижения предельного быстродействия и отсутствия сбоев нужно было вводить обратные связи типа "сигнал принят". Но уже много лет прошло, а что-то я так и не заметил адаптации структуры ПЛИС под асинхронные дизайны.

[Lerk]

Ну почему же... это всё очень тесно взаимосвязано. Логика без схемотехники никуда. А схемотехника в принципе одна и та же, что в ПЛИС, что на рассыпухе, что в ASIC.

Связано, да только не совсем. Вот есть базовая для вычислительного asic'а штука: полный сумматор. Логически - строго детерминированная штука. Вариантов реализаций будет за два десятка точно.

Вот мне стало интересно: Вы теоретик или практик? "Прошивки" для БМК разрабатывали? Спрашиваю не с целью помериться пиписьками. Просто чувствуется у Вас фундаментальный, энциклопедический подход.

Практик. Разрабатывал и всё еще.

Честно признаюсь: мало знаком с кухней подготовки ASIC, поэтому вопрос: неужели и вправду делают сейчас такие вот асики на основе асинхронного дизайна? А как же его верифицировать? Есть для этого инструменты?
Я конечно когда-то давно слышал статьи, что вот новая технология асинхронного дизайна - хорошо забытое старое - что мол позволяет выжать всё возможное из логики, работает однозначно быстрее синхронного дизайна. Особенность в этом забытом старом было в том, что для достижения предельного быстродействия и отсутствия сбоев нужно было вводить обратные связи типа "сигнал принят". Но уже много лет прошло, а что-то я так и не заметил адаптации структуры ПЛИС под асинхронные дизайны.

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