Триггеры с несколькими часами

Предположим, у меня есть 2 триггера FF1 и FF2, которые управляются с использованием нескольких часов. С какими возможными нарушениями мы столкнемся? Меня спросили об этом в интервью, в котором я ответил, что разница в перекосе или часах вызовет нарушения синхронизации и метастабильности, а также объяснил, как решить нарушения времени установки/удержания. Но, в конце концов, интервьюер сказал, что эти проблемы проявляются только тогда, когда мы используем одиночные часы с перекосом / задержкой между входами часов двух триггеров. Поэтому мне было интересно, может ли кто-нибудь сказать мне, что происходит, когда я использую несколько часов

схематический

смоделируйте эту схему - схема, созданная с помощью CircuitLab

Вау, я не знаю о редакторе схем! Интересный!
Если часы значительно различаются, может возникнуть своего рода алиасинг - это применимо, когда clk 2 меньше, чем clk1.
Интервьюер нарисовал их как триггеры FF с краем или уровнем? Он пытался заставить вас обсудить, как многофазные схемы синхронизации уменьшают/устраняют проблему перекоса и обеспечивают более надежное решение по сравнению с однофазной схемой, запускаемой по фронту.
Нет, это было телефонное интервью, и его FF были на грани. Знаете ли вы какую-либо ссылку, описывающую использование нескольких часов, а также его проблемы или преимущества?
@ Rancho CLK1 будет синхронизировать данные через логику с приличной скоростью, и если CLK2 работает медленнее, чем CLK1, он может «пропустить» жизненно важные изменения в выходе логики - почти так же, как вы слишком медленно сэмплируете сигнал - вы можете получить эффекты сглаживания, которые делают беспорядок вещей. Посмотрите псевдонимы
Разве это не означает метастабильность? Результатом будет непредсказуемое значение, поскольку данные из FF1 могут не быть захвачены в FF2 и могут иметь неправильное значение? Хорошо, я буду копаться в алиасинге

Ответы (2)

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

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

Можно в каком-то смысле «думать» о них, но существует множество реальных ситуаций, в которых природа по крайней мере одного источника тактового сигнала гарантирует, что два входа никогда не будут тактироваться где-либо рядом друг с другом, поэтому «мысли ", возможно, не придется распространяться ни на что, кроме "Эти входы всегда будут переключаться с интервалом не менее 10 мкс; время s/h на второй защелке составляет 2 нс и 5 нс. Поскольку 10 мкс больше, чем 5 нс, проблем нет".
@supercat: Если вы можете так сказать, то вы имеете дело с часами, которые находятся в одном домене, и мои комментарии к вам не относятся.
Возможно, я не совсем понимаю, что подразумевается под «доменом»? Предположим, что два независимых тактовых сигнала на частотах 3,00 МГц и 3,14159 МГц проходят через T-защелки, входы которых дважды синхронизированы с сигналами «включения», и устройство, управляющее сигналами включения, отключит одну защелку не менее чем на 1 мкс, прежде чем активировать другую. Если бы выходы этих T-защелок использовались в качестве часов, считались бы они принадлежащими одному домену или разным доменам?
@supercat: Хорошо, с прерывистыми часами вы вообще не говорите о методах синхронного проектирования, и вы должны применять полные правила асинхронного проектирования. Очевидно, что в этой конкретной ситуации вы можете придумать некоторые основные правила, которые избегают метастабильности, но вам, по крайней мере, нужно было «подумать» об этом, чтобы добиться этого.
Под разными доменами CLK он имел в виду независимые часы. Мы привыкли видеть, что один и тот же clk подается на все FF (синхронные конструкции) в наших курсах. Итак, из того, что я узнал, я мог думать только о мета-стабильности и нарушениях тайминга. Я сомневаюсь, что под несколькими доменами он имел в виду, что часы были немного разнесены. Я предполагаю что-то вроде 2 и 4 МГц или 5 и 10 МГц (может быть, это не реальные примеры). Я не задаю много вопросов, так как не хочу показывать, что ничего не знаю о нескольких часах. Так что я просто ответил, что я знал! Спасибо за ответы. Я буду; сделать больше исследований по этому вопросу.
@Rancho: Любопытно, что интервьюер предположил, что метастабильность является проблемой только при наличии одного источника тактового сигнала; если одни часы настолько быстрее других, что время высокого и низкого уровня медленных часов равно как минимум двум периодам быстрых, можно довольно легко избежать метастабильности, синхронизировав медленные часы с быстрыми. Все становится намного сложнее, если известно, что ни один из часов не идет намного медленнее другого.
@DaveTweed: Насколько сложно сочетать синхронную и асинхронную логику в дизайне? Я заметил, что многие контроллеры на базе ARM либо действительно минимизируют количество асинхронной логики, либо добавляют раздражающую логику синхронизации между ней и всем, что связано с ядром; с практической точки зрения, в программном обеспечении может быть проще справиться с тем фактом, что установка сигнала «пробуждения» на асинхронном счетчике 32 768 Гц в момент его увеличения может привести к ложному событию, чем ждать два 30 мкс после запроса. сигнал тревоги, прежде чем его можно будет изменить. Если программное обеспечение отключает прерывание до...
... записывает время будильника, сбрасывает флаг прерывания, а затем проверяет, что часы не продвинулись вперед, прежде чем он активирует флаг прерывания (если это так, повторите всю процедуру), возможно, что флаг прерывания ушел метастабильным, но программное обеспечение никогда не включит его в любой ситуации, когда он может быть метастабильным. Будут ли инструменты проектирования препятствовать любой попытке создать такую ​​конструкцию (поскольку инструменты увидят, что защелка может стать метастабильной, но не будут знать, что программное обеспечение предвидит такое состояние и гарантирует, что оно на самом деле не вызовет проблемы)?
@supercat: В чем логика синхронизации более «раздражает», чем реализация сложного программного протокола, который вы описали? В общем, инструменты дизайна будут делать то, что вы им скажете; в лучшем случае вы получите предупреждения о возможных нарушениях времени установки/удержания. Кроме того, у большинства инструментов есть способы подавить эти предупреждения на определенных путях, для которых вы приняли другие меры.
@DaveTweed: Каждый раз, когда кто-то устанавливает будильник на то, что должно быть в будущем, рекомендуется проверить - после установки будильника - убедиться, что это все еще будущее. Если единственной защелкой, связанной с синхронизацией, является флаг «совпадения», который делит часы со счетчиком и получает асинхронно сгенерированный результат сравнения, то, если счетчик не перемещался во время установки будильника, можно узнать, что он установлен. правильно. Если запрограммированное значение сигнала тревоги совпадает со значением счета, пробуждение произойдет в следующем цикле счета. Если регистр тревог дважды синхронизирован...
... самый ранний будильник, который можно установить, будет через два цикла 32 кГц в будущем. Хуже того, на ряде процессоров с такими функциями пробуждения, если установить будильник на какое-то отдаленное время в будущем, лечь спать и почти сразу же проснуться от какого-либо внешнего раздражителя, нельзя будет начать установку будильника на определенное время. более близкое время, пока более ранний запрос полностью не распространится через синхронизатор. Таким образом, становится необходимым обрабатывать события пробуждения, которые должны произойти в течение следующих четырех тактов, иначе, чем события для более отдаленных периодов времени.
@DaveTweed: Одна вещь, которую многие люди, занимающиеся аппаратным обеспечением, не осознают, заключается в том, что в программном обеспечении часто не сложнее сделать что-то и повторить попытку, если это не удалось, чем ждать, пока что-то можно будет сделать, и сделать это; если операция занимает, например, 50 циклов и почти всегда завершается успешно со второй попытки, если не с первой, тратить до 100 циклов намного лучше, чем тратить до 2000-3000.
@supercat: Я согласен, похоже, что в этом случае разработчики оборудования не учли должным образом проблемы системного уровня. На самом деле нет необходимости дважды синхронизировать регистр сигналов тревоги, когда все, о чем вы действительно заботитесь, это выход компаратора сигналов тревоги. Другая аппаратная реализация была бы гораздо более удобной для программного обеспечения.
@DaveTweed: Я не знаю, почему существует так много различных дизайнов «часов реального времени с будильником», враждебных программистам. Казалось бы, должно быть просто спроектировать 47-битный счетчик с 32-битным компаратором, который позволил бы установить сигнал тревоги для любого будущего полупериода тактовой частоты 32 кГц и немедленно вступить в силу; код, который хочет установить сигнал тревоги или прочитать полное 48-битное значение, должен будет выполнить попытку/тестирование/повторную попытку, но такая логика была бы хорошей идеей в надежных системах даже без проблем с метастабильностью. Кстати, у RTC одного процессора есть любопытная особенность: ...
... регистр, который может указать компаратору аварийных сигналов игнорировать младшие 0-7 бит счетчика. Предположительно это уменьшит энергопотребление, но я не уверен, почему это должно быть; если каждый бит счетчика, начинающийся со старшего разряда, формирует "match = (upper_bits_match & Cnt0 & Comp0) или (upper_bits_match & !Cnt0 & !Comp0)", младшие биты счетчика не вызовут срабатывания каких-либо транзисторов в компараторе. переключайтесь до тех пор, пока верхние биты не совпадут, поэтому динамическое потребление тока должно быть практически нулевым. Возможно, не нужно требовать, чтобы сравнение колебалось по всем 32 битам, но...
... генерация сигнала «совпадения» для старших 24 бит, а затем подача его в цепочку для нижних 8 бит все равно должна работать, чтобы минимизировать динамическое потребление тока.

Вопрос задается сбивчиво, что, возможно, и было его смыслом, поскольку он смешивает некоторые концепции из разных аспектов того, что известно как «синхронная синхронизация с разомкнутым циклом». Возможно, он искал вас, чтобы прояснить несколько ключевых понятий. Открытый цикл в этом контексте означает, что задержки/фаза не контролируются. Вот краткий обзор, чтобы указать направление с большим упрощением.

1) Глобальные часы, запуск по фронту. Что большинство людей думают о синхронной логике. Наиболее популярен для низкоуровневого логического проектирования, потому что FF с запуском по фронту дает простую модель последовательного проектирования, во-вторых, FF с запуском по фронту обычно происходит от TTL, CMOS и стандартных библиотек ячеек, которые их заменили, и в-третьих, большинство курсов по логическому проектированию охватывают только конструкции с краевым срабатыванием. - недостатком является то, что есть два ограничения: максимальная задержка логики должна быть меньше предела, чтобы схема работала с заданным временем цикла. Минимальная задержка должна быть больше предела, связанного с рассогласованием тактовых импульсов, чтобы схема могла работать на любой тактовой частоте.

Минимальная задержка по логике:

т г , л о г я с т с к е ш + т час о л г т п р о п , с > Вопрос

Минимальное ограничение цикла:

т с у т г , л о г я с + т с к е ш + т с е т ты п + т п р о п , с > Вопрос

2) чувствительный к уровню, двухфазный тактовый сигнал. Является, пожалуй, самым объемным режимом проектирования. потому что это то, что используется в процессорах и более сложных устройствах. Конечно, есть много вариантов этого, здесь мы просто рассмотрим версию часов без перекрытия. Логика разделена на ведущий и подчиненный FF, а минимальное время цикла ограничено только временем работы каждого логического блока и часами -> Q FF. Поворот часов (с ограничениями) не фигурирует в этих конструкциях, и в результате они более надежны, быстрее и меньше. Мне непонятно, почему этому не учат так часто.

т с у т г , л о г я с 1 + т г , л о г я с 1 + 2 т п р о п , с > Вопрос

Этот второй случай, когда нет часов OL, и нет второго логического блока, возвращается к первому случаю.

3) Сроки конвейера: которые мы не будем здесь обсуждать.