Демистификация сбросов: синхронные, асинхронные и другие соображения по проектированию... Часть 1
Оглавление
- Вступление
- Необходимость сбросов и планирование сброса
- Сброс и влияние на питание системы / чипа
- Что сбрасывать в дизайне и как долго должен быть активен сброс
- Синхронные и Асинхронные сбросы
- Список литературы
Скачать статью в формате PDF
Вступление
Современные проекты действительно сложны из-за множества доменов синхронизации, встроенных процессоров, IP, сложных конечных автоматов и иногда даже RTL, генерируемого инструментом HLS из языков высокого уровня, таких как C / C++. Эта сложность усугубляется многими типами сбросов - сбросами процессора, системы, ядра, программного обеспечения и IP. Дальнейшим усложнением архитектуры сброса является выбор синхронных и асинхронных сбросов, активных высоких и активных низких сбросов, что также усложняет стиль кодирования RTL. К сожалению, архитектура сброса не продумывается на ранней стадии цикла проектирования, что приводит к тому, что каждый разработчик решает судьбу сброса в своих блоках, в результате чего стратегия сброса является плохо спланированной и реализованной, что приводит к множеству итераций, отладке, а иногда даже отзыву продукта.
Общая рекомендация - использовать синхронные сбросы как можно чаще. Асинхронные сбросы вполне приемлемы до тех пор, пока вы осведомлены об ограничениях. На самом деле асинхронные сбросы особенно полезны, если стабильность тактовой частоты не может быть гарантирована. Конечно, при таких обстоятельствах в системе, где стабильная синхронизация не может быть гарантирована, синхронный сброс может удерживаться в активном значении до тех пор, пока PLL или MMCM не будут захвачены.
В этой заметке я попытаюсь демистифицировать сбросы, применимо к проектам на ПЛИС Xilinx. В части 1 я рассмотрю несколько конструктивных соображений, влияющих на архитектуру сброса, влияние на потребляемую мощность и стили кодирования для синхронных сбросов, а также способы синхронизации асинхронного сброса.
Необходимость сбросов и планирование сброса
Преимущество сброса в системе заключается в том, что он приводит систему в известное состояние для моделирования или гарантирует, что каждый модуль в системе находится в известном состоянии после включения питания.
Архитектура сброса должна быть действительно хорошо спланирована на ранней стадии проектирования. Раннее планирование сброса позволяет избежать неожиданностей в распределенных командах, разные части которой могут быть разбросаны по всему миру. Часто команды формируются по отдельным направлениям, ответственными за проектирование RTL, верификацию, синтез, валидацию дизайна, генерацию файлов конфигурации и др. Если не заняться планированием сбросов должным образом, то проблемы с перезагрузкой могут проявиться спустя долгое время после запуска продукта в производство. Например, у меня есть умный холодильник от ведущего производителя. Предположим, в этом умном холодильнике ЖК-панель откажется реагировать на прикосновение пользователя, и единственный способ заставить ее реагировать — это жесткая перезагрузка, как на ПК с Windows прошлых лет. Позвонив на завод, вы получите то же самое решение - Включили ли вы питание холодильника? Включение питания холодильника - болезненный процесс каждый раз, когда я хочу изменить настройки, установленные по молчанию. Вы согласны? Иногда ЖК‑дисплей не реагирует даже после включения питания. Я подозреваю проблему с архитектурой сброса. Я уверен, что есть и другие примеры.
Первым шагом процесса планирования является принятие решения о том, нужна ли вообще перезагрузка. ПЛИС Xilinx имеют глобальный сброс, который сбрасывает все в устройстве. Возможно, стоит исключить сброс настроек в вашем дизайне и вместо этого использовать глобальный сброс. Удаление сбросов - нелегкое решение, поскольку это не только приводит к проблемам с кодированием (обсуждаемым позже в этой заметке), но и к устранению сбросов в устаревшем коде RTL и IP сторонних производителей, что зачастую является непростой задачей. Если есть возможность избавиться от сбросов, которые относятся к вашей части IP, и подключить сбросы сторонних IP- к глобальному сбросу, то это была бы идеальная ситуация.
Как только будет решено, что система или архитектура дизайна/чипа абсолютно точно требуют наличие сброса, следующие шаги – это решить, что сбрасывать, а что нет, как обращаться с синхронными и асинхронными сбросами, использовать ли сброс active‑high или active-low и, наконец, как быть с синхронизацией сбросов, в случае пересечения тактовых доменов
Сброс и влияние на питание системы / чипа
Сброс оказывает огромное влияние на потребляемую мощность, и это можно объяснить двумя основными факторами. Во-первых, чрезмерное использование сброса обычно создает на 3-5% больше логики (FFs и LUT), следовательно, потребляемая мощность будет на 3-5% больше (может быть и больше). Во-вторых, сброс обычно имеет тенденцию к более высокому разветвлению и более критичен по времени. В результате он часто может потреблять более ценные ресурсы маршрутизации, оставляя менее важные по времени пути передачи данных для использования менее оптимальных маршрутов. Поскольку в целом сброс выполняется не так часто, независимо от того, существует ли он на коротком маршруте или на длинном, мощность практически одинакова, поскольку динамическая мощность определяется частотой переключения. Однако пути передачи данных, очевидно, переключаются, и если они имеют большую длину проводов, даже если они соответствуют времени, они будут потреблять больше энергии. Таким образом, если длина провода увеличится, скажем, на 15%, то мощность сигнала увеличится на ту же величину. Сокращение сбросов в вашем дизайне также приведет к экономии потребляемой энергии.
Что сбрасывать в дизайне и как долго должен быть активен сброс
Одно из решений, которое необходимо принять на этапе планирования, — решить, что будет сброшено, а что нет в проекте. Но, как правило, сброса конечных автоматов и указателей чтения и записи FIFO должно быть достаточно. Пути данных редко нуждаются в сбросе, если конечный автомат, управляющий ими, спроектирован правильно. В большинстве случаев требуется сбросить только первый этап конвейера. Остальные этапы конвейера будут сброшены в последующие такты.
Еще одним фактором, который следует учитывать при сбросах, является длительность импульса сброса. В идеале сброс должен быть активен достаточно долго, чтобы все регистры конвейера были очищены до того, как действительные данные смогут пройти через проект. Импульс сброса должен быть достаточно длинным, обычно 20-50 тактов или до нескольких тактов после захвата PLL или MMCM, в зависимости от количества сбрасываемых элементов – чем больше регистров (или триггеров) сбрасывается, тем длиннее импульс сброса. Это обеспечит соблюдение времени recovery и removal для регистров, расположенных далеко от регистра сброса.
Общепринятой практикой является использование сигнала захвата (locked) от PLL или MMCM и его комбинирование (через И/ИЛИ LUT) со сбросом системы, ЦП или ядра перед сбросом всех триггеров в проекте. Имейте в виду, что сигнал захвата является асинхронным сигналом, и наличие логики в виде LUT (ИЛИ/И) в пути может привести к сбою. Такой ложный сбой может привести к нежелательным результатам. Рекомендуется синхронизировать (подключить к триггеру) выход LUT, а затем использовать выход регистра для сброса схемы. Идея здесь в том, что вы не хотите, чтобы управляющий LUT сбрасывал все элемент проекта, поскольку это может привести к ложному сбросу из-за сбоя. Рекомендация такова: источником сброса должен быть выход триггера, а не выход LUT или комбинаторного блока. Синхронизация выхода LUT позволяет среде проектирования сделать его репликацию в случае очень высокого разветвления (fanaout).
Синхронные и Асинхронные сбросы
Еще одно архитектурное решение, которое необходимо принять на очень ранней стадии процесса проектирования – это решить, использовать ли синхронный сброс или асинхронный сброс. Рекомендация Xilinx заключалась бы в том, чтобы использовать синхронные сбросы по всему вашему дизайну. Асинхронные сбросы очень распространены в современных сложных SoC. Если в вашем проекте есть какие-либо асинхронные сбросы, рекомендуется синхронизировать асинхронный сброс. Xilinx также рекомендует использовать модули XPM CDC для всех топологий CDC (clock domain crossing – пересечение тактовых доменов), включая асинхронные сбросы. Модули XPM CDC имеют правильную конструкцию и поставляются с временными ограничениями. Синхронизатор асинхронного сброса позволяет принимать сигнал сброса асинхронно, но снятие сброса будет синхронным.
На рис. 1 показан синхронизатор асинхронного сброса с активным высоким уровнем. Когда сигнал сброса равен 1'b1, выходы Q элементов синхронизатора становятся высокими и остаются высокими до тех пор, пока сброс не будет снят (станет низким). Как только сброс снят, в следующем такте фиксируется значение 1'b0 на выводе D первого триггера, а в следующем такте (два такта спустя) выходной сигнал второго триггера в синхронизаторе становится низким. Если в цепочке синхронизатора будет больше триггеров (больше, чем 2 триггера, показанных на рис. 1), то потребуется еще несколько тактов, прежде чем сброс будет снят на последнем триггере цепочки синхронизатора.
Рисунок 1. Синхронизатор асинхронного сброса
Список литературы
|
Мотивировать автора |
Поддержать проект FPGA-Systems.ru |
Скачать статью в формате PDF
