Одна из самых разочаровывающих ошибок, возникших после вывода полупроводниковой ленты, заключается в следующем:Симуляция функций идеальна, Silicon Bring-up работает большую часть времени, но "иногда" он ведет себя нестабильно. Когда я пытаюсь воспроизвести ее перед профессором, она работает отлично..... Отладочные журналы также слабы из-за отсутствия воспроизводимости. Если вы копнете достаточно глубоко, то часто придете к одному и тому же выводу:
- "Где-то нарушен тайминг."
- Это "где-то" часто является глобальным элементом управления, таким как Clock/Reset.
- В частности, очень тонкий импульс (глюк) в точке Clock to MUX.
Глюки в тактовом канале - это другой класс глюков, чем глюки в канале данных. Глюки в тракте данных обычно устраняются в комбинационной логике.
С другой стороны, глюки в тактовом генераторе могут восприниматься флип-флопом как "лишний фронт тактового импульса", и с этого момента один аномальный фронт может исказить состояние всей системы. Именно поэтому классическим решением является Glitch-Free Clock MUX (GFCM).
1) Почему возникает глюк в обычном мультиплексоре (MUX)
Простейшие 2:1 Логика MUX чиста.
out = (~S & A) | (S & B)В RTL это выглядит так, как будто при переходе sel из 0→1 происходит смена A на B.
На уровне гейтов все иначе.
- (~S & A) и (S & B) пути имеют различную задержку ячейки / задержку провода.
- Сигнал распространения не приходит на оба пути одновременно.
- В этом коротком промежутке входная комбинация ИЛИ кратковременно изменяется, вызывая переключение сигнала на короткое время. (статическая опасность / динамическая опасность)
В тактовом MUX, A и B обычно являются асинхронными часами. Поскольку фазовые соотношения между A и B не фиксированы, вероятность того, что переход sel будет пойман в "неудачный момент", выше, чем ожидалось, что приводит к появлению кремниевой ошибки, которая "иногда" дает сбой.
2) Зачем нужен Clock Glitch
- Ширина импульса может быть распознана FF как тактовая, даже если она короткая
Сдвиг/порог в дереве тактовых импульсов, В зависимости от внутренней фильтрации импульсов в библиотеке FF, "нежелательные фронты" могут быть действительными. - Легко нарушить setup/hold одновременно
Если глитч подключается непосредственно перед нормальным фронтом, он нарушает hold, если сразу после, то нарушает setup. В любом случае результат будет случайным. - В эпоху DVFS/Fail-over/Power domain переключение тактовых импульсов - обычное дело.
3) Glitch-Free의 핵심 정의: "Уплотнение условий перехода", а не "Глюк 0"
Ключ к безглючному Clock MUX прост.
Ни один фронт тактового генератора не проходит при изменении выходного тактового генератора
Сигнал выбора (Enable) изменяется только во время стабильной части тактового генератора.
Однако важно отметить следующее:
GFCM часто представляют собой схемы с паузой, а не бесшовные схемы.
Это означает, что ценой отсутствия глюков может быть пропуск одного или двух тактов. Это должно быть оговорено в техническом задании на проектирование". Если целью является "безглючное" переключение, то оно не должно сводиться к замене MUX, а должно быть реализовано на уровне архитектуры PLL/clocking.
4) 가장 널리 쓰이는 구조(정석): "Взаимоисключение + безопасное обновление окна"
Если глюк находится слишком близко к старому тактовому генератору, это приведет к нарушению синхронизации.
Чтобы избежать этого, нам нужна логика, которая приостановит переключение тактового генератора на некоторое время.
Если посмотреть на переднюю и заднюю части, то это та же структура, что и у MUX,
- Внутри находится двухступенчатый синхронизатор,
- Там есть петля обратной связи, которая синхронизируется с противоположным тактовым генератором при изменении сигнала SELECT.
В итоге, это делает следующее.
- разрешение1 и разрешение2 никогда не переходят в 1 одновременно (взаимное исключение)
- выключение одной стороны перед включением другой (break-before-make)
Мы ненадолго останавливаем часы во время перехода, и открываем другую сторону только на безопасной стороне.
Эта "пауза" - издержки и надежность Glitch-Free.
На канале Electronicspedia есть очень хороший пример глитча, поэтому я его прикрепил:
5) "Glitch vs Glitch-Free" в форме волны (только ядро)
(1) наивный MUX (возможен глюк)
Как показано на рисунке,
когда Sel равен 0, выводится CLK1, а когда Sel равен 1, выводится CLK2.
Такое переключение тактовых импульсов, которое выводится как пунктирная часть CLK Out, чего не хотел дизайнер, называется глюком:
6) В анализе SDC и CDC:
Выход Clock MUX - это "и CLK1, и CLK2". Поэтому принято определять два генерируемых такта для выходного вывода, и исключительно, что оба генерируемых такта не могут быть активными одновременно.
- Синхронизация FF внутри GFCM является CDC, поэтому проверяйте функциональную безопасность отдельно с помощью инструмента CDC (SpyGlass-CDC и т. д.).
7) CTS/PnR 인사이트: GFCM не являются "логическими блоками", это "устройства Clock Root"
GFCM имеют различное качество в зависимости от их размещения. Это особенно актуально для современных узлов:
- По возможности ближе к источнику тактовых импульсов (PLL/OSC): Более длинные тактовые сети до и после MUX увеличивают влияние SI/EM/IR-drop и затрудняют управление перекосами:
- Выбор/управление - это управление, а не данные: По мере роста fanout безглючные структуры увеличивают "задержку перехода". Если провести анализ этого пути с помощью set_case_analysis, то при моделировании на уровне затворов можно обнаружить огромное нарушение. Этим необходимо управлять, чтобы можно было наложить ограничения:
- Разделение ролей с CTS: Истинное дерево тактовых импульсов находится после выхода GFCM:
- Цикл работы / целостность импульсов: Простое стробирование AND/OR может создать искажение цикла работы. Предпочтительнее использовать ячейки, сертифицированные литейной компанией, а не просто создавать GFCM в RTL.
Вкратце:
GFCM должны рассматриваться как часть архитектуры тактирования и "защищаться" в PnR.
8) DFx(Scan/ATPG/Bring-up) 관점: GFCM - это "дверь в тестирование"
Сканирование обычно имеет различные требования к смене тактов и захвату тактов, а тесты на скорости более требовательны. Вот как плохо спроектированный GFCM нарушает DFx:
- сканирование останавливается, потому что переключение часов в тестовом режиме запрещено
- паузы в секции захвата, что нарушает шаблон
- глюки в переходе reset/test_en, что приводит к сбою
Таким образом, рабочий шаблон обычно выглядит так.
- Непосредственно шунтировать test_clk с test_en (как RTL выше)
- Или иметь отдельный clock mux для сканирования, отдельный от function clock mux
Есть специалисты, которые делают только безглючные clock mux'ы, как этот!
Описание Glitch-Free Clock MUX как "безглючного мукса" слишком тонкое.В современных SoC GFCM - это инфраструктура синхронизации, которая проходит через DVFS/Fail-over/Power domain/DFx.
Этот небольшой блок показывает степень зрелости проекта:
- Студенческие проекты смотрят на "имеет ли RTL смысл?"
- Младшие проекты смотрят на "проходит ли STA?"
- Старшие проекты смотрят на "может ли это быть серийно произведено?"
.