используя синхронную логику создать счетчик в помехозащищенном коде грея с асинхронным сбросом
Язык описания аппаратуры Verilog HDL
Давайте подумаем, как на языке Verilog можно описать счетчик в коде Грея (Gray code). Такой счетчик может нам понадобиться для реализации асинхронного FIFO. В кодах Грея соседние значения меняются только в одном бите. Это делает возможным безопасную передачу последовательно меняющихся значений кодов из одного клокового домена в другой. Напомню, что в асинхронном FIFO указатели на голову/хвост очереди пересекают clock domain именно в кодах Грея.
Поскольку последовательность чисел в коде Грея нам известна (0,1,3,2,6,7,5. ), то первое, что приходит на ум – это написать вот такой код: module gray_cnt_v1(
input wire clk,
input wire nreset,
output reg [3:0]q
);
always @( posedge clk or negedge nreset)
if (
nreset)
q else
case (q)
4’b0000: q endcase
endmodule Это описание счетчика Грея вполне работоспособно, но оно далеко не самое удачное. Недостаток такого решения – его трудно написать и легко ошибиться при наборе этих двоичных чисел. Второе – код не параметризован. Что если придется писать, скажем, 64-х битный или 128-ми битный счетчик?
Мы знаем, что код Грея можно преобразовать в двоичный код с помощью «Исключающего ИЛИ». Так же и наоборот, двоичный код можно преобразовать в код Грея с использованием этой же операции и операции сдвига. Значит можно написать второй вариант «программы». Попробуем сделать обычный двоичный счетчик, и его выходные значения будем преобразовывать в код Грея:
module gray_cnt_v2(
input wire clk,
input wire nreset,
output wire [3:0]q
);
reg [3:0]bc; //bin counter
always @( posedge clk or negedge nreset)
if (
nreset)
bc else
bc //convert bin to gray
assign q = < bc[3], ^bc[3:2], ^bc[2:1], ^bc[1:0] >;
endmodule
Код стал компактнее, но стал ли он от этого лучше? Я бы сказал, что этот вариант даже хуже. В первом варианте gray_cnt_v1 на выходе нашего счетчика стоит регистр, фиксирующий выходное значение по фронту тактовой частоты. В этом легко убедиться, откомпилировав модуль в cреде Altera Quartus II и посмотрев результат в RTLViewer:
Во втором варианте gray_cnt_v2 выходы – это комбинационная логика, что очень плохо именно для счетчика Грея:
Мы не должны допускать формирование разных бит «счетчика» Грея в разное время, но именно это и может происходить в случае комбинационной логики на выходе нашего модуля, ведь путь формирования сигналов каждого из битов может оказаться разный.
При функциональной симуляции обоих модулей gray_cnt_v1 и gray_cnt_v2 мы увидим абсолютно одинаковый результат. Но это не значит, что все хорошо. Лучше отказаться от такого gray_cnt_v2 по указанной выше причине.
Следующий «правильный» метод может выглядеть не очень компактно, зато здесь все правильно:
module gray_cnt_v3(
input wire clk,
input wire nreset,
output wire [SIZE-1:0]q
);
parameter SIZE = 4;
integer i;
reg [SIZE-1:0]gray_cnt;
reg [SIZE-1:0]bin;
reg [SIZE-1:0]next_gray_cnt;
always @*
begin
//convert gray-to-bin
for (i=0; i >i);
//increment binary
bin=bin+1;
//convert bin-to-gray
next_gray_cnt = (bin>>1)^bin;
end
always @( posedge clk or negedge nreset)
if (
nreset)
gray_cnt else
gray_cnt assign q=gray_cnt;
По каждому клоку тактовой частоты записываем в регистр счетчика следующее предвычисленное значение next_gray_cnt. А вычисляем мы его в 3 этапа:
Откомпилируем теперь этот модуль в Altera Quartus II и посмотрим как выглядит все это в схематике RTLViewer:
Теперь можно просимулировать поведение счетчиков из примера 1 и 3. Напишем вот такой тестбенч на Verilog:
reg clk;
initial clk=0;
always
#10 clk=
reg nreset;
wire [3:0]cnt_value;
gray_cnt_v3 my_gray_cnt(
.clk(clk),
.nreset(nreset),
.q(cnt_value)
);
/*
gray_cnt_v1 my_gray_cnt(
.clk(clk),
.nreset(nreset),
.q(cnt_value)
);
*/
initial
begin
$dumpfile(«out.vcd»);
$dumpvars(-1, test);
nreset=0;
@( posedge clk); #0;
nreset=1;
Симулируем с помощью Icarus Verilog и смотрим как считает наш счетчик:
Дата: 21.05.2021 10:13
Оглавление
*О найденных опечатках и замечаниях просим сообщить admin@fpga-systems.ru
Доступно в PDF
Аннотация
1.0 Введение
2.0 Предназначение сброса
3.0 Общие примечания по стилю кодирования триггеров
4.0 Синхронный сброс
По мере проведения исследований для этой статьи был собран и рассмотрен сборник статей ESNUG и SOLV-IT. Около 80% собранных статей были посвящены вопросам синхронного сброса. Во многих статьях из SNUG утверждалось что-то вроде: “Мы все знаем, что лучший способ выполнить сброс в ASIC – это строго использовать синхронные сбросы”, или, возможно, “асинхронные сбросы плохи, и их следует избегать”. Тем не менее, было представлено мало доказательств, подтверждающих эти заявления. Использование синхронных или асинхронных сбросов имеет как преимущества, так и недостатки. Дизайнер / разработчик должен использовать подход, соответствующий определенному дизайну / проекту.
Синхронные сбросы основаны на предположении, что сигнал сброса будет влиять на состояние триггера (сбрасывать его) только при активном фронте тактового сигнала. Сброс может быть применен к триггеру как часть комбинационной логики, формирующей сигнал на D-входе триггера. Если это так, то стиль кодирования для описания сброса должен быть описан с помощью приоритетного if/else со сбросом в условии if и всей другой комбинационной логикой в ветке else. Если этот стиль не соблюдается строго, могут возникнуть две возможные проблемы. Во-первых, в некоторых симуляторах, основанных на логических уравнениях, логика может блокировать сброс и он не достигнет триггера. Однако, это проблема моделирования, а не аппаратная проблема, но помните, что одна из главных целей сброса – привести ASIC в известное состояние для выполнения моделирования. Во-вторых, сброс может “запаздывать” относительно тактового сигнала из-за высокого ветвления цепей сброса. Даже если сброс будет буферизован с помощью специального буфера (буфера сброса), разумно ограничить объем логики, которая должна быть сброшена. Этот стиль описания синхронного сброса можно использовать с любой логикой или библиотекой. В примере 3 показана реализация синхронного сброса как части счетчика с загрузкой данных с функцией переноса (carry out).
4.1 Стиль кодирования и пример схемы
Код Verilog в примере 4a и код VHDL в примере 4б показывают правильный способ описания триггеров с синхронным сбросом. Обратите внимание, что сброс не является частью списка чувствительности. Для Verilog исключение сброса из списка чувствительности – это то, что делает сброс синхронным. Для VHDL удаление сброса из списка чувствительности и проверка сброса после оператора “if clk’event и clk =» 1” делает сброс синхронным. Также обратите внимание, что сброс имеет приоритет над любым другим присвоением при использовании стиля кодирования «if-else.
Одна из проблем с синхронными сбросами заключается в том, что синтезатор не может просто взять и отличить сигнал сброса от любого другого сигнала данных. Рассмотрим код из примера 3, который приводит к схеме на рис. 3. В качестве альтернативы синтезатор мог бы создать схему, показанную на рис. 4.
1. Прим. пер.: подробнее про X-пессимизм:
Synopsys предоставляет директиву компилятора sync_set_reset, которая сообщает синтезатору, что данный сигнал является синхронным сбросом (или сигналом установки (set)). Синтезатор “подтянет” этот сигнал как можно ближе к триггеру, чтобы предотвратить возникновение этой проблемы. Директива может быть использована путем добавления следующей строки где-то внутри модуля:
// synopsys sync_set_reset «rst_n»
В общем, мы рекомендуем использовать атрибуты и директивы Synopsys только тогда, когда они необходимы и имеют значение; однако директива sync_set_reset не влияет на логическое поведение проекта, она влияет только на его функциональную реализацию. Опытный инженер предпочел бы избежать повторного синтеза на поздней стадии разработки проект и добавил бы директиву sync_set_reset ко всему RTL-коду на ранней стадии. Поскольку объявление ранее упомянутой директивы требуется только один раз, рекомендуется добавлять ее в каждый модуль с синхронными сбросами.
В качестве альтернативы решение можно использовать переменную синтеза hdlin_ff_always_sync_set_reset, значение которой следует установить в true, что даст тот же результат, не требуя вставки каких-либо директив в самом коде.
Несколько лет назад другой участник SNUG рекомендовал добавить переменную compile_preserve_sync_resets =» «true» [15]. Хотя эта переменная могла быть полезна несколько лет назад, она была удалена Synopsys, начиная с версии 3.4 b [38].
4.2 Преимущества синхронного сброса
Логика синхронного сброса будет синтезироваться в более компактные триггеры, особенно если сброс совмещается с логикой, генерирующей D-вход. Но в таком случае увеличивается число комбинационных логических элементов, поэтому общая экономия может быть не столь значительной. Однако, если дизайн микросхемы достаточно плотный, то экономия площади в один или два логических вентиля на триггер может повлиять на возможность размещения ASIC на подложке. Однако, при современных технологических нормах и больших размерах подложки экономия одного или двух логических вентилей на триггер, как правило, не играет важной роли и не будет существенным фактором того, уместится ли дизайн на подложке.
Использование синхронных сбросов обычно гарантирует, что схема на 100% синхронна.
Использование синхронных сбросов гарантирует, что сброс может произойти только на активном фронте тактового сигнала. Тактовый сигнал работает как фильтр при небольших глитчах сброса; однако, если эти сбои происходят вблизи активного фронта тактового сигнала, триггер может перейти в метастабильное состояние. Такое поведение ничем не отличается от любого другого ввода данных в триггер; любой сигнал, нарушающий требования по времени установления (setup), может привести к метастабильности.
В некоторых проектах сброс должен быть вызван набором внутренних условий. Для таких проектов рекомендуется использование синхронного сброса, поскольку он будет фильтровать глитчи, вызванные логикой формирования сброса (прим. пер. эффектом гонок в комбинационных схемах) между тактовыми сигналами
4.2 Недостатки синхронного сброса
Не все библиотеки ASIC имеют триггеры со встроенными синхронными сбросами. Однако, поскольку синхронный сброс – это просто еще один вход данных, вам действительно не нужен специальный триггер. Логика сброса может быть легко синтезирована вне самого триггера.
Для синхронных сбросов может потребоваться «удлинитель» импульсов, чтобы гарантировать достаточную длительность импульса сброса для обеспечения его наличия во время активного фронта тактового сигнала [16]. Это вопрос, который важно учитывать при работе с несколькими тактовыми доменами. Можно использовать небольшой счетчик, который будет обеспечивать достаточную длительность сигнала сброса.
Дизайнер должен уметь работать с проблемами симулятора. Потенциальная проблема существует, если сброс генерируется комбинационной логикой в ASIC или если сброс должен проходить через множество уровней локальной комбинационной логики. Во время моделирования, в зависимости от того, как генерируется сброс или как данные подаются на функциональный блок, сброс может быть замаскирован неопределенным состоянием X. Большое количество SNUG статей посвящено этому вопросу. Большинство симуляторов не смогут разрешить некоторые условия X-логики и, следовательно, заблокируют синхронный сброс [7] [8] [9] [10] [11] [12] [13] [14] [15] [34]. Обратите внимание, что это также может быть проблемой и с асинхронными сбросами. Проблема не столько в том, какой тип сброса вы используете, сколько в том, легко ли сигнал сброса управляется внешним выводом.
По своей природе синхронный сброс требует тактового сигнала для сброса схемы. Для одних проектов использование синхронного сброса является приемлемым, но для некоторых дизайнов может стать большой проблемой. Например, если у вас есть схема управления тактовой частотой, позволяющей включать и отключать тактовый сигнал для экономии энергопотребления (прим. пер. т.н. gated clock или clock gating), тактовый сигнал может быть отключен одновременно со сбросом. В этой ситуации будет работать только асинхронный сброс.
Требование к наличию тактового сигнала для осуществления сброса, является существенным, если ASIC/FPGA имеет внутреннюю tristate шину. Чтобы предотвратить конфликт на внутренней шине tristate при включении микросхемы, микросхема должна иметь асинхронный сброс питания (см. рис. 5). Можно использовать синхронный сброс, однако вы должны напрямую перевести сигнал разрешения tristate (сигнал ое) в неактивное состояние с помощью сигнала сброса (см. рис. 6). Этот синхронный метод имеет преимущество при более простом временном анализе для пути reset-to-HiZ.
Рисунок 5 – Асинхронный сброс для сигнала разрешения выхода
Рисунок 6 – Синхронный сброс для сигнала разрешения выхода
Дата: 20.05.2021 11:56
Оглавление
*О найденных опечатках и замечаниях просим сообщить admin@fpga-systems.ru
Перевод доступен в PDF
Аннотация
В этой статье будут рассмотрены плюсы и минусы синхронных и асинхронных сбросов. Мы рассмотрим использование каждого типа сброса, за которыми последуют рекомендации по правильному использованию каждого из них.
1.0 Введение
Тема дизайна сброса удивительно сложна и плохо освещена. Инженерные школы, как правило, не дают полной картины по детализации подводных камней неправильного проектирования сброса. Основываясь на нашем отраслевом и консалтинговом опыте, мы собрали наше текущее понимание вопросов, связанных с дизайном сброса, и для этой статьи добавили опыт нашего коллеги Стива Голсона, который проделал очень инновационную работу по дизайну сброса. Мы приветствуем любые отзывы коллег, связанные с этим важным вопросом.
Мы представили наш первый доклад по проблемам и методам сброса на конференции SNUG в марте 2002 года[4] и впоследствии получили многочисленные отзывы по электронной почте и вопросы, связанные с проблемами проектирования сброса.
Очевидно, мы не смогли адекватно объяснить все проблемы, связанные со схемой синхронизатора асинхронного сброса, потому что во многих из полученных нами электронных писем нас спрашивали, есть ли проблемы с метастабильностью, связанные с описанной схемой. Ответ на этот вопрос заключается в том, что нет никаких проблем с метастабильностью, связанных с этой схемой, и технический анализ и объяснение теперь подробно описаны в разделе 7.1 этой статьи.
В первой статье Дон и Клифф поддержали и рекомендовали использовать асинхронные сбросы в проектах и изложили наши причины выбора этого метода. С помощью Стива Голсона мы провели дополнительный анализ по этому вопросу и стали более нейтральны в отношении правильного выбора реализации сброса.
Очевидно, что существуют явные преимущества и недостатки использования синхронных или асинхронных сбросов, и любой метод может быть эффективно использован в реальных проектах. При выборе стиля сброса очень важно учитывать вопросы, связанные с выбранным стилем, чтобы принять обоснованное дизайнерское решение.
В этой статье представлены обновленные методы и соображения, связанные как с синхронным, так и с асинхронным сбросом. Эта версия документа включает обновленные порты модулей, описанные в стиле ANSI Verilog-2001 во всех примерах Verilog.
Первая версия статьи включала интересный метод синхронизации сброса нескольких ASIC в высокоскоростных приложениях. Данный материал был удален из этой статьи поэтому заинтересованным читателям стоит ознакомиться с первой версией, если эта тема представляет интерес.
2.0 Предназначение сброса
В любом случае, зачем беспокоиться об этих раздражающих маленьких сбросах? Зачем посвящать целую статью такой тривиальной теме? Любой, кто использовал компьютер с ОС, знает, что аппаратный сброс очень удобен. Он вернет компьютер в известное рабочее состояние (по крайней мере, временно), применив сброс системы к каждому чипу в системе, который имеет или требует сброса.
Для отдельных ASIC основной целью сброса является принудительное приведение дизайна ASIC (поведенческого, RTL или структурного) в известное состояние. После того, как ASIC спроектирован, необходимость в его сбросе определяется системой, применением ASIC и конструкцией ASIC. Например, многие ASIC, применяемые для передачи данных, предназначены для синхронизации со входным потоком данных, обработки данных и их последующей выдачи. Если синхронизация в какой либо момент теряется, ASIC проходит процедуру повторного получения сигнала синхронизации. Если этот тип ASIC спроектирован правильно, так что все неиспользуемые состояния указывают на состояние “начать синхронизацию”, он может нормально функционировать в системе без сброса. Сброс системы потребовался бы при включении питания для такого ASIC, если бы конечные автоматы в ASIC использовали преимущество логического сокращения “все равно” (don’tcare) на этапе синтеза.
Мы считаем, что, как правило, каждый триггер в ASIC должен быть сброшен независимо от того, требуется это системой или нет. В некоторых случаях, когда конвейерные триггеры (триггеры сдвигового регистра) используются в высокоскоростных приложениях, сброс может быть исключен из некоторых триггеров для достижения более высокой производительности. Такой вариант реализации требует заданного количества импульсов тактового сигнала в течение активного периода сброса, чтобы перевести ASIC в известное состояние.
Многие вопросы проектирования должны быть рассмотрены перед выбором стратегии сброса для проектирования ASIC. Например, следует ли использовать синхронные или асинхронные сбросы, будет ли каждый триггер получать сброс, как будет размещено и буферизовано дерево сброса, как проверить синхронизацию дерева сброса, как функционально протестировать сброс с помощью векторов тестового сканирования и как применить сброс через несколько тактовых логических доменов.
3.0 Общие примечания по стилю кодирования триггеров
3.1 Триггеры с синхронным сбросом с подключёнными триггерами без сброса
В коде Verilog примера 1а и коде VHDL примера 1б первый триггер используется для захвата данных, а затем его выход подключается к следующему триггеру. Первый этап этой конструкции – сброс, выполняемый синхронно. Второй этап описывает приёмный триггер, который не сбрасывается, но поскольку два триггера были описаны в одном и том же процедурном блоке/процессе, сигнал сброса rst_n будет использоваться в качестве источника данных для второго триггера. Этот стиль кодирования будет генерировать постороннюю логику, как показано на рис.1.
Пример 1а – Плохой стиль описания отличающихся триггеров на Verilog (git)
Пример 1б – Плохой стиль описания отличающихся триггеров на VHDL (git)
Правильный способ описания принимающего триггера – использовать два процедурных блока Verilog, как показано в примере 2a, или два процесса VHDL, как показано в примере 2б. Эти стили кодирования будут генерировать логику, показанную на рис. 2
Пример 2а – Хороший стиль описания отличающихся триггеров на Verilog-2001 (git)
Пример 2б – Хороший стиль описания отличающихся триггеров на VHDL (git)
Рисунок 2 – Два разных триггера, один с синхронным сбросом, второй без
Следует отметить, что посторонняя логика, генерируемая кодом в примере 1a и примере 1б, является только результатом использования синхронного сброса. Если бы использовался подход асинхронного сброса, то оба стиля кодирования синтезировались бы в одном и том же дизайне без какой-либо дополнительной комбинационной логики. Генерация различных стилей триггеров в значительной степени зависит от списков чувствительности и операторов if-else, которые используются в коде HDL. Более подробная информация о списке чувствительности и стилях кодирования if-else приведена в разделе 4.1
3.2 Стили описания триггера
Не следует описывать каждый триггер в своем собственном процедурном блоке/процессе. С точки зрения стиля, все триггеры, выполняющие одну функцию или даже группу функций, должны быть описаны с использованием одного процедурного блока/процесса. Для описания больших последовательных блоков в рамках данного модуля/архитектуры следует использовать несколько процедурных блоков/процессов. Исключение из этого правила составляют последовательные триггеры, как описано в разделе 3.1, где для корректного описания требуется несколько процедурных блоков/процессов.
3.3 Рекомендации по оператору присваивания
В Verilog все назначения, выполняемые внутри блока always, описывающего триггер (последовательная логика), должны выполняться с неблокирующими операторами назначения[3]. Аналогично, для VHDL триггеры должны быть описаны с использованием оператора присваивания сигналов.
4.0 Синхронный сброс
О синхронном сбросе читайте во второй части
Используя синхронную логику создать счетчик в помехозащищенном коде грея с асинхронным сбросом
Источники питания электронной аппаратуры, импульсные и линейные регуляторы. Топологии AC-DC, DC-DC преобразователей (Forward, Flyback, Buck, Boost, Push-Pull, SEPIC, Cuk, Full-Bridge, Half-Bridge). Драйвера ключевых элементов, динамика, алгоритмы управления, защита. Синхронное выпрямление, коррекция коэффициента мощности (PFC)
Обратная Связь, Стабилизация, Регулирование, Компенсация
Организация обратных связей в цепях регулирования, выбор топологии, обеспечение стабильности, схемотехника, расчёт
Первичные и Вторичные Химические Источники Питания
Li-ion, Li-pol, литиевые, Ni-MH, Ni-Cd, свинцово-кислотные аккумуляторы. Солевые, щелочные (алкалиновые), литиевые первичные элементы. Применение, зарядные устройства, методы и алгоритмы заряда, условия эксплуатации. Системы бесперебойного и резервного питания
Высоковольтные выпрямители, умножители напряжения, делители напряжения, высоковольтная развязка, изоляция, электрическая прочность. Высоковольтная наносекундная импульсная техника
Электрические машины, Электропривод и Управление
Электропривод постоянного тока, асинхронный электропривод, шаговый электропривод, сервопривод. Синхронные, асинхронные, вентильные электродвигатели, генераторы
Технологии, теория и практика индукционного нагрева
Системы Охлаждения, Тепловой Расчет – Cooling Systems
Охлаждение компонентов, систем, корпусов, расчёт параметров охладителей
Моделирование и Анализ Силовых Устройств – Power Supply Simulation
Моделирование силовых устройств в популярных САПР, самостоятельных симуляторах и специализированных программах. Анализ устойчивости источников питания, непрерывные модели устройств, модели компонентов
Силовые полупроводниковые приборы (MOSFET, BJT, IGBT, SCR, GTO, диоды). Силовые трансформаторы, дроссели, фильтры (проектирование, экранирование, изготовление), конденсаторы, разъемы, электромеханические изделия, датчики, микросхемы для ИП. Электротехнические и изоляционные материалы.
Интерфейсы
Форумы по интерфейсам
все интерфейсы здесь
Поставщики компонентов для электроники
Поставщики всего остального
от транзисторов до проводов
Компоненты
Закачка тех. документации, обмен опытом, прочие вопросы.
Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир
Обсуждение Майнеров, их поставки и производства
наблюдается очень большой спрос на данные устройства.
Встречи и поздравления
Предложения встретиться, поздравления участников форума и обсуждение мест и поводов для встреч.
Ищу работу
Предлагаю работу
нужен постоянный работник, разовое предложение, совместные проекты, кто возьмется за работу, нужно сделать.
Куплю
микросхему; устройство; то, что предложишь ты 🙂
Продам
Объявления пользователей
Тренинги, семинары, анонсы и прочие события
Общение заказчиков и потребителей электронных разработок
Обсуждение проектов, исполнителей и конкурсов