В каких случаях надо использовать синхронный, а в каких асинхронный сброс?

Мда. Ответ на него приходит, когда начинаешь чувствовать, как твоя схема должна работать, т.е. представлять схему в простейших элементах (тригер, счетчик, компаратор....).

А вообще ничего сложного - если у тебя тактирование постоянное (а выбираешь нужные фронты сигналами enable или условными конструкциями), то конечно лучше поставь тактируемый сброс. Почему тактируемый сброс лучше? Ну хотя бы потому, что обычно на цифровой плате ужасный дребезг стоит, а на многослойности платы часто экономят (имеются ввиду слои заливки gnd или vcc).
С другой стороны нужно не перемудрить - что бы не возникло такой ситуации, что ресет подал, а клока нет и сброс не произошел (ну это может быть только в тех случаях, если тактирование не постоянное, чего я бы не рекомендовал).

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

Не совсем правда. Например, в Xilinx FPGA есть триггеры и с синхронными очисткой/предустановкой. Совершенно отдельные входы.

Я бы Вам рекомендовал пользоваться синхронным ВСЕМ (не только ресет).
Даже в случаях когда это занимает больше места.
Если весь модуль синхронен - невероятное благо, т.к. достаточно только одного констрейна. В противном случае прийдется затягивать все асинхронные пути, чтобы быть увереным в том что после PAR "родилось" то что надо.

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

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

Что-то я в конце дня плохо соображаю... Можно поподробнее?

У меня был проект на Xilinx Virtex-II с 9-ю тактовыми доменами, из них четыре синхронных, остальные асинхронные. Сброс был как внешний (источники питания + кнопка), так и внутренний (программный регистр, выходы lock блоков DLL). Использовалось три блока DLL. Делал управление энергопотреблением путем снятия тактовых сигналов или переключения на более низкую частоту с помощью элементов BUFGMUX.

Во всем проекте использовал асинхронный сброс. Сбросом каждого блока SoC управлял контроллер сброса, который формировал для каждого блока свой сигнал сброса и в нужной последовательности. Снятие каждого локального сигнала сброса происходило синхронно к соответствующему тактовому домену (это важно!). Также важна последовательность снятия локальных сигналов сброса для тех блоков, где есть переходы между тактовыми доменами.

Чтобы при анализе времен не было путаницы, объявляю все сигналы сброса как falsepath, при этом эти пути не рассматриваются при анализе времен.

Вообщем, все прекрасно работало + некоторая экономия ресурсов.

Вывод: все зависит от задачи, оба типа схемы сброса имеют право на жизнь.

PS: на Xilinx были материалы на тему организации сброса, смотрите

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

Имелось в виду следующее: есть некая логика, которая служит для реализации требуемой функциональности. Сама логика, ессно, реализуется в LUT'ах. Чем она сложнее - больше сигналов входных - тем дленнее получаются цепочки - в одну LUT не влезло - начинает каскдировать, времяка ухудшается. Если туда же еще заводить сигнал начального сброса/преустановки, то это еще один вход, еще доп. "нагрузка". А ведь он используется-то только один раз при старте. Поэтому логично этот начальный сброс/предустановку завести на свободные ноги set/reset триггеров.

Сегодня некоторые современные ПЛИС имеют триггеры с отдельными синхронными входами сброса/установки, но это уже отдельная история.

Кто нибудь может мне объяснить почему когда я переделываю асинхронный сброс на синхронный то увеличивается тактовая частота?

Хмм а как вы оцениваете частоту ?

И вопрос гуру: допустимо ли использование обоих видов сброса? асинхронный для первоначальной синхронизации и синхронный при работе?

Может это и не правильно но я сначало синтезирую в Synplify а затем размещаю с помощью Квартуса
Значения длительности(предельной частоты) тактовых сигналов смотрю в Квартусе

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

Понял спасибо.

Было
if RST='0' then
--код сброса
elsif CLK='1' and CLK'event then
--код
end if;

Стало
if CLK='1' and CLK'event then
if RST='0' then
--код сброса
else
--код
end if;
end if;

Второй вариан быстрее.

Я не спец по VHDL, но, имхо, этот код неполный. На Верилоге про код:

нельзя сказать, синхронный тут сброс или асинхронный. Все зависит от списка чувствительностей. Если там always @(posedge clk), то сброс будет синхронный, если always @(posedge clk, posedge rst), то сброс будет асинхронный. А код внутри один и тот же.

А что по етому поводу могут сказать знающие VHDL.

В Quartus-e ессесно после PAR. Из опыта - значение предельной частоты после синтеза в Synplify обычно гораздо ниже (процентов на 20-30), уж не знаю почему, но что есть .

А теперь дублирую свое же послание в Telesys:
Static timing analisys врет всегда и притом в одну сторону: используется так называемый pessimistic approach, т.е. расчет ведется на "самый плохой случай" по всем возможным переменным - флуктуации напряжения питания, температура,... Практически из опыта это значение процентов 10 (не уверен, что всегда, но это то, что я имел - так, когда Quartus выдал граничную частоту в 92MHz, я протестировал кристал л на полном диапозоне температру и при вариациях питания(ий) на частоте до 103MHz работал без проблем, дальше появились глюки).

В симуляторе задержки практически точно соответствовали померянным на готовом железе, точную погрешность в цифрах не скажу, но она очень мала. При этом на диапозонах в единицы наносекунд трудно сказать погрешность чего больше - осцилографа (лог. анализатора) или симулятора. Я сам в свое время быль приятно удивлен точность расчетных задержек. Кстати, подобные измерения на Актеле (правда много лет назад) отличались гораздо большими разбросами.

Пасибо.
Но всетаки интересно почему синхронный сброс быстрее?
Пока я толком не понял

Если при анализе временных параметров для асинхронного варианта сброса, в анализе участвует сам сигнал асинхронного сброса, то меньшая тактовая частота работы схемы может получаться и по технологическим причинам (временные параметры технологии). Часто при использовании асинхронного сброса его исключают при анализе временных параметров схемы (например, объявляют как falsepath в настройках анализатора времен). Надо внимательно смотреть, чего требуется получить.


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

Реально надо знать на какой частоте заработает железка после прошивки!

Кроме этого, реально надо еще знать чего хотим-то. Например, если имеем асинхронный сброс от источника питания, т. е. достаточной длительности и низкой частоты, то исключаем цепь сброса из временного анализа схемы, получаем более быстродействующую схему, чем в случае использования синхронного сброса. При этом не забываем обеспечить снятие сигнала сброса СИНХРОННО тактовому сигналу (иначе, особенно при относительно высоких рабочих частотах схемы, схема может неправильно запуститься). Если сигнал сброса это внутренний сигнал некоторой схемы, и он влияет на логику работы, а не просто приводит схему в исходное состояние, то предпочтительнее использовать синхронный сброс. В моем понимании сброс - это сигнал приведения схемы в исходное состояние (достаточной длительности и относительно низкой частоты), все остальное - сигналы управления. Не забываем, что сигнал синхронного сброса должен быть именно СИНХРОННЫМ по отношению к тактовому.

P.S.: Реально, железка с асинхронным сбросом должна заработать на большей частоте, чем с синхронным.

прочитал все... могу сказать следующее: когда лет пять назад был на стажировке в германии в фраунгоферском институте как раз мутили там проект на VHDL... что-то типа кодека SOVA... именно там я раз и навсегда запонимнил: сброс должен быть асинхронный и по уровню логического нуля... как говорил мой тамошний руководитель: "никаких синхронных сбросов! никогда!"

немцы не дураки... понимание пришло с годами... да и студентов так же учу (из-за них-то на форуме давно и не был - сессия у них, блин): все просто -логический ноль для того чтоб никакие наводки не влияли на схему сброса... если будет по единице сбрасываться, то любой тычек и микруха в дауне, а вот чтоб единицу до нуля дотянуть - тут токо кз может быть, никакие наводки нипочем... асинхронность - вторая защита от глюков... это у нас с источником генерации, как уж писали, может тож что угодно творится... все остальные неприятности и нестабильность работы ядра после асинхронного сброса из-за кривизны рук только... ихмо <_<
сколько проектов не делал - все было и генерация пропадала, и фонила вся плата, но асинхронный сброс свое дело делал и система быстро и легко возвращалась в рабочее состояние... в общем как в рекламе - все красиво и правильно

"Рылся" на xilinx.com нашел статью
Get Smart About Reset (Think Local, Not Global)
http://www.xilinx.com/xlnx/xweb/xil_tx_dis...eceihdffhdfjf.0

может быть поможет прояснить ситуацию

Можно ли исходя из этого сделать вывод что и сигналы управления должны иметь активный стан логический ноль?

И еще, по поводу наводок понятно, но только,например, тригеры у Xilinx имеют активное состояние сброса "1". И синтезатор, если делать по Вашему, поставит инвертор. Где тогда тут устойчивость к наводкам?

"Можно ли исходя из этого сделать вывод что и сигналы управления должны иметь активный стан логический ноль?

И еще, по поводу наводок понятно, но только,например, тригеры у Xilinx имеют активное состояние сброса "1". И синтезатор, если делать по Вашему, поставит инвертор. Где тогда тут устойчивость к наводкам? "
Все выше сказанное скорее относится к внешним по отношению к ПЛИС сигналам на печатной плате. Действительно от кристалла к кристаллу желательно иметь сигналы ресет и управления активными в нуле.
Внутри кристалла что ноль, что единица, лично я по опыту разницы не заметил.

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

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

"Если используете асинхронный сброс - берегитесь иголок (которые не видны в симуляторе на поведенческом уровне, зато хороше себя проявляют при реальной работе схемы). Я использую асинхронный ресет только для глобальног сброса всего
проекта. "
И зачем это надо. Если говорить о ресете внутри проекта. Какая разница, асинхронный ресет или синхронный по отношению к внутренней частоте кристалла. (Если этот ресет формируется на выходе трггера). Разница только в моменте установления нужного сигнала на временной оси. Тоже самое, если этот ресет внешний. Естественно он должен быть порождением триггера. А вот еслт говорить от согласовании линий связи по печатной плате, то конечно стробирование ресета внутренней частотой кристалла улучшает "устойчивость" реакции на это входное воздействие.