Было
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". И синтезатор, если делать по Вашему, поставит инвертор. Где тогда тут устойчивость к наводкам? "
Все выше сказанное скорее относится к внешним по отношению к ПЛИС сигналам на печатной плате. Действительно от кристалла к кристаллу желательно иметь сигналы ресет и управления активными в нуле.
Внутри кристалла что ноль, что единица, лично я по опыту разницы не заметил.

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

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

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