Внедрение асинхронной логики сброса в Vhdl для надежных проектов

Многобитный регистр с асинхронным сбросом

Для более сложных конструкций с участием многобитных регистров или машин состояний применяется тот же принцип, но с дополнительными сигналами для управления. Вот пример 8-битного регистра с асинхронным сбросом:

library IEEE;
use IEEE.std_logic_1164.all;

entity register_async is
 port(
 clk : in std_logic;
 reset : in std_logic;
 d_in : in std_logic_vector(7 downto 0);
 q_out : out std_logic_vector(7 downto 0)
 );
end register_async;

architecture behavioral of register_async is
begin
 process(clk, reset)
 begin
 if reset = '1' then
 q_out <= (others => '0');
 elsif rising_edge(clk) then
 q_out <= d_in;
 end if;
 end process;
end behavioral;

Конструкция (другие => '0]] обеспечивает удобный способ инициализации всех битов вектора до нуля, обеспечивая полное покрытие сброса по всей ширине регистра.

Контрреализация с асинхронной перезагрузкой

Счетчики являются общими строительными блоками в цифровых конструкциях и значительно выигрывают от правильной реализации сброса. Вот исчерпывающий пример счетчика с асинхронным сбросом:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

entity counter_async is
 port(
 clk : in std_logic;
 reset : in std_logic;
 enable : in std_logic;
 count : out std_logic_vector(7 downto 0)
 );
end counter_async;

architecture behavioral of counter_async is
 signal count_reg : unsigned(7 downto 0);
begin
 process(clk, reset)
 begin
 if reset = '1' then
 count_reg <= (others => '0');
 elsif rising_edge(clk) then
 if enable = '1' then
 count_reg <= count_reg + 1;
 end if;
 end if;
 end process;

 count <= std_logic_vector(count_reg);
end behavioral;

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

Государственная машина с асинхронным сбросом

Машины с конечным состоянием (FSM) являются критически важными компонентами в цифровых системах, и правильная реализация сброса гарантирует, что они всегда начинаются в известном безопасном состоянии. Вот пример простого FSM с асинхронным сбросом:

library IEEE;
use IEEE.std_logic_1164.all;

entity fsm_async is
 port(
 clk : in std_logic;
 reset : in std_logic;
 input : in std_logic;
 output: out std_logic
 );
end fsm_async;

architecture behavioral of fsm_async is
 type state_type is (IDLE, ACTIVE, DONE);
 signal current_state, next_state : state_type;
begin
 -- State register with asynchronous reset
 process(clk, reset)
 begin
 if reset = '1' then
 current_state <= IDLE;
 elsif rising_edge(clk) then
 current_state <= next_state;
 end if;
 end process;

 -- Next state logic
 process(current_state, input)
 begin
 case current_state is
 when IDLE =>
 if input = '1' then
 next_state <= ACTIVE;
 else
 next_state <= IDLE;
 end if;
 when ACTIVE =>
 next_state <= DONE;
 when DONE =>
 next_state <= IDLE;
 end case;
 end process;

 -- Output logic
 output <= '1' when current_state = ACTIVE else '0';
end behavioral;

Эта реализация FSM отделяет государственный регистр (с асинхронным сбросом) от комбинационной логики следующего состояния, следуя лучшим практикам для проектирования государственных машин. Сброс гарантирует, что FSM всегда начинается в состоянии IDLE, обеспечивая предсказуемое поведение инициализации.

Критические вызовы с асинхронной перезагрузкой

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

Метастабильность и деассерция сброса

Наиболее значительная проблема с асинхронными сбросами возникает во время деассерации сброса (релиза). Асинхронные сбросы, однако, имеют одну серьезную проблему - деассерция сброса не гарантируется на одном и том же краю часов для всех синхронных примитивов в конструкции. Это означает, что разные части конструкции могут выходить из сброса в разное время, нет контроля последовательности сброса.

Однако, когда сброс дезассертируется и не проходит проверку времени восстановления (μtSU) или удаления (μtH) (анализ восстановления и удаления с помощью анализа синхронизации синхронизации проверяет оба раза), край, как говорят, упал в зону метастабильности. Дополнительное время требуется для определения правильного состояния, и задержка может привести к тому, что время установки не будет зарегистрировано ниже по течению, что приведет к сбою системы. Эта проблема метастабильности может вызвать периодические сбои, которые трудно отладить и воспроизвести.

Распределение сброса и время

Проблема усугубляется, когда рассматриваются большие многочасовые проекты доменов. Помимо проблем с синхронизацией, распределение асинхронного сброса до миллионов шлепаний является сложной задачей, требующей методов, аналогичных CTS (синтез часового дерева) и требующих аналогичных ресурсов области и маршрутизации. Это делает распределение сброса критической проблемой в современных, сложных FPGA и ASIC-проектах.

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

чувствительность Glitch

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

Методы синхронизации Reset

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

Асинхронный ассерт, синхронный десерт

Мы можем утверждать сброс синхронно и деасинхронно. Такая схема называется синхронизатором сброса. Такой подход, часто называемый «асинхронным утверждением, синхронным деассертом», обеспечивает лучшее из обоих миров: возможность немедленного сброса, когда это необходимо, с контролируемым, синхронизированным выпуском, чтобы избежать проблем метастабильности.

Вот реализация VHDL синхронизатора сброса:

library IEEE;
use IEEE.std_logic_1164.all;

entity reset_synchronizer is
 port(
 clk : in std_logic;
 async_reset: in std_logic;
 sync_reset : out std_logic
 );
end reset_synchronizer;

architecture behavioral of reset_synchronizer is
 signal reset_sync_reg : std_logic_vector(1 downto 0);
 attribute ASYNC_REG : string;
 attribute ASYNC_REG of reset_sync_reg : signal is "TRUE";
begin
 process(clk, async_reset)
 begin
 if async_reset = '1' then
 reset_sync_reg <= (others => '1');
 elsif rising_edge(clk) then
 reset_sync_reg <= reset_sync_reg(0) & '0';
 end if;
 end process;

 sync_reset <= reset_sync_reg(1);
end behavioral;

Этот синхронизатор использует двухступенчатый регистр сдвига для синхронизации деассерации сброса. Когда асинхронный сброс утверждается, обе стадии сразу переходят в «1». Когда сброс высвобождается, нули синхронно перемещаются через регистр с часами, гарантируя, что окончательный синхронизированный сигнал сброса очищается на краю часов.

Это гарантирует, что синхронные элементы в пределах каждого отдельного домена часов выходят из сброса одновременно (т.е. на одном краю часов). Атрибут ASYNC REG помогает синтезу и инструментам определения места и маршрута понять, что эти регистры образуют цепочку синхронизации и должны быть размещены близко друг к другу, чтобы минимизировать риски метастабильности.

Многоступенчатая синхронизация

Чтобы этого избежать, добавьте несколько регистров после регистра с асинхронным сбросом и используйте выход этих регистров в дизайне.Число этапов синхронизации зависит от конкретных требований и целевых показателей MTBF (среднее время между отказами) для вашего дизайна.

Для критически важных приложений может быть целесообразным трехступенчатый синхронизатор:

library IEEE;
use IEEE.std_logic_1164.all;

entity reset_sync_3stage is
 port(
 clk : in std_logic;
 async_reset: in std_logic;
 sync_reset : out std_logic
 );
end reset_sync_3stage;

architecture behavioral of reset_sync_3stage is
 signal sync_chain : std_logic_vector(2 downto 0);
 attribute ASYNC_REG : string;
 attribute ASYNC_REG of sync_chain : signal is "TRUE";
begin
 process(clk, async_reset)
 begin
 if async_reset = '1' then
 sync_chain <= (others => '1');
 elsif rising_edge(clk) then
 sync_chain <= sync_chain(1 downto 0) & '0';
 end if;
 end process;

 sync_reset <= sync_chain(2);
end behavioral;

Каждый дополнительный этап в цепи синхронизации снижает вероятность распространения метастабильности до логики проектирования за счет дополнительной задержки в дезассере сброса.

Синхронизация с перезагрузкой в одночасье

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

Вот пример архитектуры для двухчасовой системы домена:

library IEEE;
use IEEE.std_logic_1164.all;

entity multi_clock_reset is
 port(
 clk_a : in std_logic;
 clk_b : in std_logic;
 async_reset : in std_logic;
 reset_a : out std_logic;
 reset_b : out std_logic
 );
end multi_clock_reset;

architecture behavioral of multi_clock_reset is
 component reset_synchronizer is
 port(
 clk : in std_logic;
 async_reset: in std_logic;
 sync_reset : out std_logic
 );
 end component;
begin
 -- Reset synchronizer for clock domain A
 sync_a: reset_synchronizer
 port map(
 clk => clk_a,
 async_reset => async_reset,
 sync_reset => reset_a
 );

 -- Reset synchronizer for clock domain B
 sync_b: reset_synchronizer
 port map(
 clk => clk_b,
 async_reset => async_reset,
 sync_reset => reset_b
 );
end behavioral;

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

Лучшие практики для асинхронного перезагрузки

Успешное внедрение асинхронной логики сброса требует соблюдения установленных передовой практики, которая была усовершенствована за годы опыта работы в отрасли и уроков, извлеченных из неудач проектирования.

Последовательное восстановление полярности

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

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

Полное покрытие Signal Reset

Так что лучшая практика такова: если синхронный процесс имеет сброс, обязательно сбросьте все сигналы, записанные в процессе. Этот принцип одинаково применим к реализациям асинхронного сброса. Неполное покрытие сброса может привести к непредсказуемому поведению и трудно отлаженным проблемам инициализации.

Вот пример, показывающий правильное полное покрытие сброса:

-- GOOD: All signals reset
process(clk, reset)
begin
 if reset = '1' then
 signal_a <= '0';
 signal_b <= '0';
 signal_c <= (others => '0');
 elsif rising_edge(clk) then
 signal_a <= input_a;
 signal_b <= input_b;
 signal_c <= input_c;
 end if;
end process;

-- BAD: Incomplete reset
process(clk, reset)
begin
 if reset = '1' then
 signal_a <= '0';
 -- signal_b and signal_c not reset!
 elsif rising_edge(clk) then
 signal_a <= input_a;
 signal_b <= input_b;
 signal_c <= input_c;
 end if;
end process;

Синхронизация перезагрузки обязательна

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

Синхронизированный подход к сбросу дает несколько преимуществ:

• Устранение рисков метастабильности во время десертации сброса
• Обеспечивает все флип-флопы в сбрасывании выхода из часового домена одновременно
• Предсказуемая инициализация машины состояния
• Упрощает анализ времени и закрытие
• Уменьшает вероятность периодических сбоев

Правильный менеджмент списка чувствительности

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

-- CORRECT: Both clk and reset in sensitivity list
process(clk, reset)
begin
 if reset = '1' then
 q <= '0';
 elsif rising_edge(clk) then
 q <= d;
 end if;
end process;

-- INCORRECT: Missing reset in sensitivity list
process(clk) -- WRONG!
begin
 if reset = '1' then
 q <= '0';
 elsif rising_edge(clk) then
 q <= d;
 end if;
end process;

Перезагрузка маршрутизации и распределения сигналов

Обратите пристальное внимание на маршрутизацию сигналов сброса, особенно в больших конструкциях. Используйте выделенные глобальные ресурсы сброса, когда они доступны в вашей целевой FPGA. Эти ресурсы специально разработаны для распределения сигналов управления с низким перекосом, таких как сброс.

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

Избегайте смешивания типов сброса

Большая проблема, которую делают многие дизайнеры, заключается в том, что они смешивают свои синхронные и асинхронные сбросы вместе, чтобы управлять портом сброса асинхронизации на FF. Эта практика создает сложные сценарии синхронизации и может привести к трудно диагностируемым проблемам.

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

Контрольная сетка

Включите комплексное тестирование сброса в ваши тестбенши. Проверьте, что:

• Утверждение сброса правильно инициализирует все элементы состояния
• Сброс может быть осуществлен в любое время во время операции.
• Дизайн восстанавливается правильно от сброса
• Замедление сброса не вызывает метастабильности или нарушений сроков
• Несколько циклов сброса/выпуска работают правильно

Вот шаблон Testbench, который включает тщательное тестирование сброса:

library IEEE;
use IEEE.std_logic_1164.all;

entity tb_reset_test is
end tb_reset_test;

architecture testbench of tb_reset_test is
 signal clk : std_logic := '0';
 signal reset : std_logic := '1';
 signal data : std_logic := '0';
 signal q : std_logic;

 constant CLK_PERIOD : time := 10 ns;
begin
 -- Clock generation
 clk <= not clk after CLK_PERIOD/2;

 -- DUT instantiation
 dut: entity work.dff_async_reset
 port map(
 clk => clk,
 reset => reset,
 d => data,
 q => q
 );

 -- Test process
 process
 begin
 -- Test 1: Initial reset
 reset <= '1';
 wait for 50 ns;
 assert q = '0' report "Reset failed" severity error;

 -- Test 2: Release reset and verify operation
 reset <= '0';
 wait for 20 ns;
 data <= '1';
 wait until rising_edge(clk);
 wait for 1 ns;
 assert q = '1' report "Normal operation failed" severity error;

 -- Test 3: Asynchronous reset during operation
 wait for 30 ns;
 reset <= '1';
 wait for 1 ns;
 assert q = '0' report "Async reset failed" severity error;

 -- Test 4: Reset release at various clock phases
 reset <= '0';
 wait for 3 ns; -- Release at arbitrary time
 wait until rising_edge(clk);
 wait for 50 ns;

 -- Test 5: Multiple reset cycles
 for i in 1 to 5 loop
 reset <= '1';
 wait for 15 ns;
 reset <= '0';
 wait for 25 ns;
 end loop;

 report "All tests passed" severity note;
 wait;
 end process;
end testbench;

Асинхронная и синхронная перезагрузка: выбор

Выбор между синхронной или асинхронной перезагрузкой зависит от характера логики перезагрузки и требований проекта. Понимание компромиссов между этими подходами имеет важное значение для принятия обоснованных проектных решений.

Преимущества асинхронного сброса

Асинхронные сбросы предлагают несколько неоспоримых преимуществ:

• Часовая независимая операция: Схема может быть сброшена даже тогда, когда часы не работают или нестабильны.
• Немедленный ответ: Перезагрузка вступает в силу мгновенно, не дожидаясь момента, когда часы начнут работать.
• Силовая инициализация: Включает надежную инициализацию во время последовательностей включения перед стабилизацией часов
• Простой путь передачи данных: В отличие от синхронного сброса, асинхронный сброс не вставляется в путь передачи данных и не оказывает негативного влияния на время поступления данных между регистрами.
• Эффективность аппаратного обеспечения: Использует выделенные штифты сброса на флип-флопсах, а не потребляет логические ресурсы

Преимущества синхронной перезагрузки

Синхронные сбросы также обеспечивают значительные преимущества:

• Предсказуемое время: Синхронные сбросы предсказуемы (на краю часов) Синхронные сбросы надежны a.o. против сбоев
• Никаких проблем с метастабильностью: При синхронизации сигнала сброса с часами разработчики могут гарантировать, что операция сброса происходит в известной и стабильной точке времени системы, снижая риск непредсказуемого поведения.
• Лучше для синтеза FPGA: Инструменты синтеза могут объединять синхронный сигнал сброса в логику для траектории передачи данных (т.е. LUT, которые приводят в движение ввод D флип-флоп). Это уменьшает вентиляцию на сигнале сброса, а также количество наборов управления, что, в свою очередь, улучшает упаковку устройства.
• Праймитивная совместимость: Если вы полагаетесь на инструменты для вывода определенных примитивов, таких как DPS48 или BRAM, это возможно только в том случае, если вы закодировали синхронный сброс — эти примитивы не поддерживают асинхронные сбросы.

Отраслевая практика и рекомендации

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

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

Если нет, то предпочтите синхронный сброс. Используйте асинхронные сбросы только с логическими элементами, которые явно требуют этого (в частности, сложные примитивы FPGA и IP-ядра, например, приемопередатчики и контроллеры шины), и даже при этом попробуйте использовать сигнал синхронного сброса, если это возможно.

Передовые методы сброса и шаблоны

Помимо базовой реализации сброса, несколько передовых методов могут повысить надежность и функциональность логики сброса в сложных проектах.

Power-On Reset Generation

Многие конструкции FPGA требуют сброса питания, который автоматически утверждается во время конфигурации устройства и высвобождается после стабилизации часов. Вот образец для создания надежного сброса питания:

library IEEE;
use IEEE.std_logic_1164.all;

entity power_on_reset is
 generic(
 RESET_CYCLES : integer := 16 -- Number of clock cycles to hold reset
 );
 port(
 clk : in std_logic;
 por_reset : out std_logic
 );
end power_on_reset;

architecture behavioral of power_on_reset is
 signal reset_counter : integer range 0 to RESET_CYCLES := RESET_CYCLES;
 signal reset_reg : std_logic := '1';
begin
 process(clk)
 begin
 if rising_edge(clk) then
 if reset_counter > 0 then
 reset_counter <= reset_counter - 1;
 reset_reg <= '1';
 else
 reset_reg <= '0';
 end if;
 end if;
 end process;

 por_reset <= reset_reg;
end behavioral;

Этот генератор перезагрузки с включенным питанием использует возможности инициализации FPGA для запуска счетчика при его максимальном значении, обеспечивая, чтобы сброс утверждался сразу после настройки.Сброс остается заявленным для программируемого количества тактовых циклов, обеспечивая время стабилизации PLL и других схем.

Условная перезагрузка

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

architecture behavioral of mixed_reset is
 signal control_state : state_type;
 signal data_pipeline : std_logic_vector(31 downto 0);
begin
 -- Control logic: MUST have reset
 control_proc: process(clk, reset)
 begin
 if reset = '1' then
 control_state <= IDLE;
 elsif rising_edge(clk) then
 -- state machine logic
 end if;
 end process;

 -- Data pipeline: No reset needed if always loaded before use
 data_proc: process(clk)
 begin
 if rising_edge(clk) then
 if data_valid = '1' then
 data_pipeline <= input_data;
 end if;
 end if;
 end process;
end behavioral;

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

Перезагрузка приоритета и иерархии

В проектах с несколькими источниками сброса (power-on reset, внешняя кнопка сброса, сброс сторожевого таймера и т.д.) устанавливают четкую иерархию приоритетов:

library IEEE;
use IEEE.std_logic_1164.all;

entity reset_manager is
 port(
 clk : in std_logic;
 por_reset : in std_logic; -- Power-on reset (highest priority)
 external_reset: in std_logic; -- External reset button
 watchdog_reset: in std_logic; -- Watchdog timer reset
 system_reset : out std_logic -- Combined system reset
 );
end reset_manager;

architecture behavioral of reset_manager is
 signal combined_reset : std_logic;
 signal sync_reset : std_logic;
begin
 -- Combine all reset sources (OR logic)
 combined_reset <= por_reset or external_reset or watchdog_reset;

 -- Synchronize the combined reset
 sync_proc: process(clk, combined_reset)
 variable sync_chain : std_logic_vector(1 downto 0) := (others => '1');
 begin
 if combined_reset = '1' then
 sync_chain := (others => '1');
 elsif rising_edge(clk) then
 sync_chain := sync_chain(0) & '0';
 end if;
 sync_reset <= sync_chain(1);
 end process;

 system_reset <= sync_reset;
end behavioral;

Этот менеджер сброса объединяет несколько источников сброса и обеспечивает один синхронизированный выход сброса для остальной части дизайна, упрощая распределение сброса и обеспечивая последовательное поведение.

Сроки ограничения и анализ для асинхронного сброса

Правильные временные ограничения необходимы для обеспечения того, чтобы асинхронные схемы сброса соответствовали их требованиям времени и работали надежно.

Восстановление и удаление времени

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

Время восстановления аналогично времени установки - минимальное время сброса должно быть обезврежено до активного кромки часов. Время удаления аналогично времени удержания - минимальное время сброса должно оставаться обезвреженным после активного кромки часов.

SDC ограничения для пути сброса

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

# Set false path for asynchronous reset assertion
# (Reset assertion is asynchronous and doesn't need timing analysis)
set_false_path -from [get_ports async_reset] -to [all_registers] -setup

# Constrain reset recovery/removal timing
# (Reset deassertion must meet timing)
set_max_delay -from [get_ports async_reset] -to [all_registers] 5.0

# For reset synchronizer chains, preserve registers
set_preserve_register [get_cells reset_sync_reg*]

# Mark synchronizer registers with ASYNC_REG property
set_property ASYNC_REG TRUE [get_cells reset_sync_reg*]

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

Сроки распределения сброса

В больших конструкциях распределение сигнала сброса может стать узким местом во времени. Рассмотрим эти стратегии:

• Используйте выделенные глобальные сети сброса, предоставляемые FPGA
• Внедрение региональных синхронизаторов сброса для уменьшения отключения
• Сигналы сброса трубопровода для очень больших конструкций
• Использование размещения синхронизаторов с учетом времени для сбрасывания цепей

Обычные подводные камни и как их избежать

Понимание распространенных ошибок в реализации асинхронного сброса помогает дизайнерам избежать дорогостоящих сеансов отладки и потенциальных полевых сбоев.

Подводный камень 1: Забывание синхронизации сброса

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

Решение: Всегда используйте синхронизатор сброса для асинхронного деассерационного сброса.Сделай это стандартной практикой в своей методологии проектирования.

Подводный камень 2: Неполные списки чувствительности

Отказ от сигнала сброса из списка чувствительности процесса создает несоответствие синтез-симуляция. Моделирование будет рассматривать сброс как синхронный (только проверенный на краю часов), в то время как синтез будет правильно реализовывать асинхронный сброс.

Решение: Всегда включайте в список чувствительности для асинхронных процессов сброса как часы, так и сброс. Используйте VHDL-2008, если ваши инструменты поддерживают его, или будьте дотошны в отношении списков чувствительности.

Pitfall 3: Смешивание стилей сброса

Сочетание синхронной и асинхронной логики сброса или использование различных полярностей сброса в разных частях конструкции создает путаницу и увеличивает вероятность ошибок.

Решение: Установите и задокументируйте последовательную стратегию сброса для всего вашего проекта. Используйте шаблоны кодирования и обзоры дизайна для обеспечения согласованности.

Pitfall 4: Недостаточная пульсация

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

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

Pitfall 5: Игнорирование сброса в тестбенчах

Многие тестбенчи неадекватно тестируют функциональность сброса, упустив потенциальные проблемы, которые проявляются только во время последовательностей сброса.

Решение: Включает комплексное тестирование сброса: начальный сброс, сброс во время работы, несколько циклов сброса и сброс на различных тактовых фазах.

FPGA-специфические соображения

Различные поставщики и семьи FPGA имеют конкретные характеристики и рекомендации по внедрению сброса, которые дизайнеры должны понимать.

Xilinx FPGA

Xilinx FPGA имеют встроенные возможности инициализации, которые устанавливают все флип-флопы в известное состояние после конфигурации. Это означает, что для многих проектов явная логика сброса может не потребоваться для инициализации. Однако возможность сброса времени выполнения по-прежнему часто требуется.

Xilinx обычно рекомендует синхронные сбросы для большинства приложений, поскольку они лучше интегрируются с тканью FPGA и не потребляют выделенные ресурсы асинхронного набора / сброса, которые могут использоваться для других целей.

Intel (Altera) FPGA

Регистры в устройствах Altera имеют асинхронные порты сброса, поэтому вы должны написать свой код так, чтобы он их использовал.Оговорка заключается в том, что вам нужно синхронизировать источники сброса с каждым тактовым доменом в вашем FPGA, то есть использовать синхронизатор сброса, размещенный PietervanStar.

Если вы напишете свой код для синхронного сброса, то Quartus создаст логику для реализации вашего синхронного сброса, то есть вы будете без необходимости использовать входы LUT. Так что «стоимость» использования неправильного стиля, это более крупный дизайн и потенциал для увеличения комбинаторного пути в вашем дизайне.

FPGA Initialization vs. Runtime Reset (англ.) (недоступная ссылка).

Вендоры FPGA не рекомендуют использовать асинхронные сбросы для конструкций FPGA. Вместо этого многие современные конструкции FPGA используют встроенную инициализацию устройства для состояния включения питания и используют синхронные сбросы для требований к сбросу во время выполнения.

Такой подход может значительно сократить использование ресурсов при сохранении надежной возможности сброса. Однако он требует тщательного рассмотрения того, какие регистры действительно нуждаются в возможности сброса во время выполнения, а какие только нуждаются в инициализации.

Примеры дизайна и тематические исследования

Изучение примеров полного проектирования помогает укрепить понимание реализации асинхронного сброса в реалистичных контекстах.

Пример 1: приемник UART с асинхронным сбросом

Приемник UART демонстрирует практическое использование асинхронного сброса в периферийном устройстве связи:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

entity uart_rx is
 generic(
 CLKS_PER_BIT : integer := 87 -- For 115200 baud at 10MHz clock
 );
 port(
 clk : in std_logic;
 reset : in std_logic;
 rx_serial : in std_logic;
 rx_data : out std_logic_vector(7 downto 0);
 rx_valid : out std_logic
 );
end uart_rx;

architecture behavioral of uart_rx is
 type state_type is (IDLE, START_BIT, DATA_BITS, STOP_BIT);
 signal state : state_type;
 signal bit_counter : integer range 0 to 7;
 signal clk_counter : integer range 0 to CLKS_PER_BIT-1;
 signal rx_data_reg : std_logic_vector(7 downto 0);
begin
 process(clk, reset)
 begin
 if reset = '1' then
 state <= IDLE;
 bit_counter <= 0;
 clk_counter <= 0;
 rx_data_reg <= (others => '0');
 rx_valid <= '0';
 elsif rising_edge(clk) then
 rx_valid <= '0'; -- Default, pulse for one cycle

 case state is
 when IDLE =>
 if rx_serial = '0' then -- Start bit detected
 state <= START_BIT;
 clk_counter <= 0;
 end if;

 when START_BIT =>
 if clk_counter = CLKS_PER_BIT/2 then
 if rx_serial = '0' then -- Verify start bit
 state <= DATA_BITS;
 clk_counter <= 0;
 bit_counter <= 0;
 else
 state <= IDLE; -- False start
 end if;
 else
 clk_counter <= clk_counter + 1;
 end if;

 when DATA_BITS =>
 if clk_counter = CLKS_PER_BIT-1 then
 clk_counter <= 0;
 rx_data_reg(bit_counter) <= rx_serial;
 if bit_counter = 7 then
 state <= STOP_BIT;
 else
 bit_counter <= bit_counter + 1;
 end if;
 else
 clk_counter <= clk_counter + 1;
 end if;

 when STOP_BIT =>
 if clk_counter = CLKS_PER_BIT-1 then
 if rx_serial = '1' then -- Valid stop bit
 rx_valid <= '1';
 rx_data <= rx_data_reg;
 end if;
 state <= IDLE;
 else
 clk_counter <= clk_counter + 1;
 end if;
 end case;
 end if;
 end process;
end behavioral;

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

Пример 2: Многочасовой FIFO с синхронизацией сброса

Двухчасовой FIFO демонстрирует синхронизацию сброса по часовым доменам:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

entity async_fifo is
 generic(
 DATA_WIDTH : integer := 8;
 ADDR_WIDTH : integer := 4
 );
 port(
 -- Write clock domain
 wr_clk : in std_logic;
 wr_reset : in std_logic;
 wr_en : in std_logic;
 wr_data : in std_logic_vector(DATA_WIDTH-1 downto 0);
 wr_full : out std_logic;

 -- Read clock domain
 rd_clk : in std_logic;
 rd_reset : in std_logic;
 rd_en : in std_logic;
 rd_data : out std_logic_vector(DATA_WIDTH-1 downto 0);
 rd_empty : out std_logic;

 -- Asynchronous reset input
 async_reset : in std_logic
 );
end async_fifo;

architecture behavioral of async_fifo is
 -- Synchronized resets for each domain
 signal wr_reset_sync : std_logic;
 signal rd_reset_sync : std_logic;

 -- FIFO memory and pointers
 type memory_type is array (0 to 2**ADDR_WIDTH-1) of
 std_logic_vector(DATA_WIDTH-1 downto 0);
 signal memory : memory_type;

 signal wr_ptr : unsigned(ADDR_WIDTH downto 0);
 signal rd_ptr : unsigned(ADDR_WIDTH downto 0);
begin
 -- Reset synchronizer for write clock domain
 wr_sync: entity work.reset_synchronizer
 port map(
 clk => wr_clk,
 async_reset => async_reset,
 sync_reset => wr_reset_sync
 );

 -- Reset synchronizer for read clock domain
 rd_sync: entity work.reset_synchronizer
 port map(
 clk => rd_clk,
 async_reset => async_reset,
 sync_reset => rd_reset_sync
 );

 -- Write process
 wr_proc: process(wr_clk, wr_reset_sync)
 begin
 if wr_reset_sync = '1' then
 wr_ptr <= (others => '0');
 elsif rising_edge(wr_clk) then
 if wr_en = '1' and wr_full = '0' then
 memory(to_integer(wr_ptr(ADDR_WIDTH-1 downto 0))) <= wr_data;
 wr_ptr <= wr_ptr + 1;
 end if;
 end if;
 end process;

 -- Read process
 rd_proc: process(rd_clk, rd_reset_sync)
 begin
 if rd_reset_sync = '1' then
 rd_ptr <= (others => '0');
 elsif rising_edge(rd_clk) then
 if rd_en = '1' and rd_empty = '0' then
 rd_data <= memory(to_integer(rd_ptr(ADDR_WIDTH-1 downto 0)));
 rd_ptr <= rd_ptr + 1;
 end if;
 end if;
 end process;

 -- Status flags (simplified - full implementation needs Gray code)
 wr_full <= '1' when (wr_ptr + 1) = rd_ptr else '0';
 rd_empty <= '1' when wr_ptr = rd_ptr else '0';
end behavioral;

Этот FIFO демонстрирует надлежащую синхронизацию сброса для каждого часового домена, гарантируя, что обе стороны записи и чтения выходят из сброса чисто без проблем метастабильности.

Стратегии отладки и проверки

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

Методы моделирования

При моделировании конструкций с асинхронным сбросом обратите особое внимание на:

• Сроки сброса: Утверждение сброса и дезассерация в различных точках тактового цикла
• Множественные домены: Убедитесь, что каждый тактовый домен правильно обрабатывает сброс
• Продолжительность сброса: Обеспечить импульсы сброса достаточно долго для того, чтобы вся логика сбросила
• Поведение после сброса: Проверить правильность работы конструкции после сброса

Статический анализ времени

Используйте инструменты анализа времени для проверки:

• Время восстановления и удаления для всех асинхронных путей сброса
• Правильная синхронизация дезассеции сброса
• Задержки с распределением сброса в больших проектах
• Связи между временем и моментом сбрасывания

Тестирование аппаратного обеспечения

При тестировании на аппаратных средствах:

• Тестирование поведения при сбросе мощности в течение нескольких циклов мощности
• Проверка работы сброса на разных рабочих частотах
• Испытательный сброс при различных условиях температуры и напряжения
• Проведение расширенного стресс-тестирования с частыми циклами сброса
• Мониторинг любых периодических сбоев, которые могут указывать на проблемы метастабильности

Отраслевые стандарты и руководящие принципы

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

Статьи Клиффорда Каммингса о синхронизации сброса широко рассматриваются как авторитетные ссылки в этой области. На веб-сайте Embedded.com размещено множество статей о передовых методах сброса как для ASIC, так и для FPGA-дизайнов.

Для тех, кто работает с конкретными семействами FPGA, документация поставщика предоставляет важную информацию для конкретного устройства. Документация FPGA Intel и Документация AMD Xilinx включают подробные руководящие принципы по сбросу с учетом их соответствующих архитектур.

Краткое содержание и ключевые выводы

Внедрение асинхронной логики сброса в VHDL является критически важным навыком для цифровых дизайнеров, работающих как над проектами FPGA, так и над ASIC. В то время как асинхронные сбросы обеспечивают немедленный отклик и не зависящую от часов работу, они требуют тщательной реализации, чтобы избежать проблем с метастабильностью и временем.

Ключевые принципы для надежной асинхронной реализации сброса включают:

• Всегда синхронизируйте дезассерирование сброса с помощью многоступенчатого синхронизатора
• Включите часы и сброс в список чувствительности процесса
• Сброс всех сигналов, записанных в процессе, для обеспечения полной инициализации
• Внедрение синхронизации сброса синхронизации в многочасовых проектах
• Используйте последовательную полярность сброса во всем вашем дизайне
• Применять надлежащие временные ограничения для анализа восстановления и удаления
• Тщательно протестируйте функциональность сброса в симуляции и оборудовании
• Рассмотрим компромиссы между асинхронным и синхронным сбросом для вашего конкретного приложения.

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

Помните, что выбор между асинхронным и синхронным сбросом зависит от ваших конкретных требований, целевой технологии и ограничений проектирования.Во многих современных конструкциях FPGA гибридный подход асинхронного утверждения с синхронным деассерированием обеспечивает оптимальный баланс возможностей немедленного сброса и надежной, без метастабильности работы.