[kyb 0]

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

 

С точки зрения моделирования поведение описаний должно быть разным. Формально, в первом случае Divider12 принимает значения от 0 до 12, однако 12 существует только в течение задержки присвоения Divider12 = #1 4'b0, так как блокирующее присваивания выполняются сразу, последовательность присваиваний прерывается только явными задержками. Во втором случае значение 12 действует в течение такта FastCLK + задержка на смену значения 1.

 

И еще одно мелкое наблюдение - лучше асинхронный сброс добавлять в список чувствительности блока.

[sazh 3]

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

И правильно. что используете синхронный ресет

 

always @(posedge FastCLK)

begin

if (Reset)

Divider <= 4'd0;

else if (Divider == 4'd11)

Divider <= 4'd0;

else

Divider <= Divider + 1'b1;

end

endmodule

 

 

скачайте с сайта xilinx документ xst.pdf (синтез)

[kyb 0]

sazh>>> И правильно. что используете синхронный ресет

 

Спорное утверждение.

[sazh 3]

А что тут спорного. Все синхронное легко укладывается на глобальный клок. С временами установки и удержания данных относительно клока никаких проблем. Никаких констрейнов.

Все в разах глобального клока. Никаких пролетов по времени (один такт ресета, а в другом проекте вдруг два такта ресета при асинхронной установке).

[kyb 0]

В принципе, все зависит от конкретной задачи и стиля описания.

 

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

[sazh 3]

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

Что касается глобального сброса для программированной логики (что синхронного, что асинхронного это разве что для конечных автоматов.) У системы есть время готовности, за которое любой счетчик войдет в синхронизм без всякого сброса (неговоря о том что есть средства установки любого начального состояния по включению. Дался Вам этот 0. Я например люблю цифру 7)

[dxp 34]

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

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

[sazh 3]

Я говорю о том, что при синхронной и асинхронной установке, чтобы добиться одного и того же результата, приходиться реализовывать РАЗНЫЕ схемные решения. Вот два примера для формирования временного интервала. Выбирайте по вкусу.

 

module intervala_scl (global_clk, ce, interval);

 

parameter dlitelnost = 4'd14; // больше или равно 1

parameter width = 4;

 

input global_clk;

input ce; // длитеьностью в один такт глобального клока

output interval;

 

reg [width-1:0] ct;

reg fdse_enable;

 

assign interval = fdse_enable;

 

always @ (posedge global_clk)

begin

if (ce == 1'b1)

ct <= dlitelnost;

else if (fdse_enable == 1'b1)

ct <= ct - 1'b1;

end

 

always @ (posedge global_clk)

begin

if (ce == 1'b1)

fdse_enable <= 1'b1;

else if (ct == 4'd1)

fdse_enable <= 1'b0;

end

 

endmodule

//////////////////////////////////////

module intervala_acl (global_clk, ce, interval);

 

parameter dlitelnost = 4'd14; // больше или 2 (Note Gate Push-Back == OFF)

parameter width = 4;

 

input global_clk;

input ce; // длительностью в один такт глобального клока

output interval;

 

reg [width-1:0] ct;

reg fd_ce;

reg fdpe_enable;

 

assign interval = fdpe_enable;

 

always @ (posedge global_clk)

begin

fd_ce <= ce;

end

 

always @ (posedge global_clk or posedge fd_ce)

begin

if (fd_ce == 1'b1)

ct <= dlitelnost;

else if (fdpe_enable == 1'b1)

ct <= ct - 1'b1;

end

 

always @ (posedge global_clk or posedge fd_ce)

begin

if (fd_ce == 1'b1)

fdpe_enable <= 1'b1;

else if (ct == 4'd2)

fdpe_enable <= 1'b0;

end

 

endmodule

[kyb 0]

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

Ваши примеры могут выглядеть следующим образом

 

module intervala_scl (reset, global_clk, ce, interval);

 

parameter dlitelnost = 4'd14; // больше или равно 1

parameter width = 4;

 

input reset;

input global_clk;

input ce; // длитеьностью в один такт глобального клока

output interval;

 

reg [width-1:0] ct, ct_;

reg fdse_enable, fdse_enable_;

 

assign interval = fdse_enable;

 

always @ ( ce or ct)

if (ce == 1'b1)

ct_ = dlitelnost;

else if (fdse_enable == 1'b1)

ct_ = ct - 1'b1;

 

 

always @ (posedge global_clk or posedge reset)

if ( reset)

ct <= dlitelnost;

else

ct <= ct_;

 

always @ ( ce or ct )

if (ce == 1'b1)

fdse_enable_ = 1'b1;

else if (ct == 4'd1)

fdse_enable_ = 1'b0;

 

always @ (posedge global_clk or posedge reset)

if ( reset)

fdse_enable <= что-то начальное;

else

fdse_enable <= fdse_enable_;

 

endmodule

//////////////////////////////////////

module intervala_acl (global_clk, ce, interval, reset);

 

parameter dlitelnost = 4'd14; // больше или 2 (Note Gate Push-Back == OFF)

parameter width = 4;

 

input reset;

input global_clk;

input ce; // длительностью в один такт глобального клока

output interval;

 

reg [width-1:0] ct, ct_;

reg fd_ce;

reg fdpe_enable;

 

assign interval = fdpe_enable;

 

always @ (posedge global_clk or posedge reset)

if ( reset)

fd_ce <= 0;

else

fd_ce <= ce;

 

always @ ( fd_ce or ct)

if ( fd_ce == 1'b1)

ct_ = dlitelnost;

else if (fdse_enable == 1'b1)

ct_ = ct - 1'b1;

 

 

always @ (posedge global_clk or posedge reset)

if ( reset)

ct <= dlitelnost;

else

ct <= ct_;

 

always @ ( fd_ce or ct )

if (fd_ce == 1'b1)

fdse_enable_ = 1'b1;

else if (ct == 4'd2)

fdse_enable_ = 1'b0;

 

always @ (posedge global_clk or posedge reset)

if ( reset)

fdse_enable <= что-то начальное;

else

fdse_enable <= fdse_enable_;

 

endmodule

 

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

Использование явного глобального сброса это скорее дело вкуса, лично для меня такой стиль более прозрачен.

 

А использование совсем асинхронных сигналов в ПЛМ дело совсен неблагодарное, лучше уж синхронизовать на рассыпухе где-то снаружи, чтобы внутри все было хорошее и синхронное.

[dxp 34]

Я говорю о том, что при синхронной и асинхронной установке, чтобы добиться одного и того же результата, приходиться реализовывать РАЗНЫЕ схемные решения. Вот два примера для формирования временного интервала. Выбирайте по вкусу.

 

module intervala_scl (global_clk, ce, interval);

 

...

Я, простите, не понял, что Вы хотели сказать. То, что при использовании синхронного сброса, который есть просто синхронная загрузка лог. 0, ресурсов логики LE будет использовано больше, нежели в случае с асинхронным сбросом, который выполняется через отдельный аппаратный сброс триггера, сомнению не подлежит. Например, приходит у меня на 4-входовой LUT 4 сигнала. Куда еще загрузку нуля (сброс, то бишь) пихать? Правильно, придется делать на двух LUT'ах с каскадированием, а это есть уменьшение быстродействия схемы. Т.ч. синхронный сброс при достаточной насышенности логики (как, например, в приведенном примере, когда все входы LUT заняты) вносит дополнительные тормоза. И не вижу ничего плохого в том, чтобы делать начальный сброс асинхронным для всей ПЛИС - сам-то сигнал сброса формируется тоже по клоку и синхронен по отношению ко всей логике.

[sazh 3]

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

Я не вижу смысла в асинхронном сбросе всего ПЛИС. Даже представить не могу, где это надо. Что касается быстродействия при синхронном сбросе, 400 мГц мне пока достаточно.

По поводу разбора моего примера - без коментариев.

[dxp 34]

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

Я не вижу смысла в асинхронном сбросе всего ПЛИС. Даже представить не могу, где это надо.

А как сделать начальную установку? Надо ведь привести схему к исходному состоянию в начале работы.

 

Что касается быстродействия при синхронном сбросе, 400 мГц мне пока достаточно.

По поводу разбора моего примера - без коментариев.

Это на каком чипе?

[des00 25]

Я, простите, не понял, что Вы хотели сказать. То, что при использовании синхронного сброса, который есть просто синхронная загрузка лог. 0, ресурсов логики LE будет использовано больше, нежели в случае с асинхронным сбросом, который выполняется через отдельный аппаратный сброс триггера, сомнению не подлежит. Например, приходит у меня на 4-входовой LUT 4 сигнала. Куда еще загрузку нуля (сброс, то бишь) пихать? Правильно, придется делать на двух LUT'ах с каскадированием, а это есть уменьшение быстродействия схемы. Т.ч. синхронный сброс при достаточной насышенности логики (как, например, в приведенном примере, когда все входы LUT заняты) вносит дополнительные тормоза. И не вижу ничего плохого в том, чтобы делать начальный сброс асинхронным для всей ПЛИС - сам-то сигнал сброса формируется тоже по клоку и синхронен по отношению ко всей логике.

 

ИМХО вы не правы, синхронный сброс благо, что особенно явно проявляеться в современных проектах.

НИКАКИЕ ресурсы современных фпга это не жрет, тригер в люте может быть поставлен как с асинхронным сбросм, так и с синхронным. Более того синхронный сброс снимает проблему "гонки" сигнала сброса.

 

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

 

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

 

Насчет 400МГц, семейства виртек4, стратикс2 вполне реально могут работать на частотах до 500МГц, но вот кол-во уровней логики которые можно разложить между такими тригерам, к сожалению очень мало :(.

[dxp 34]

ИМХО вы не правы, синхронный сброс благо, что особенно явно проявляеться в современных проектах.

НИКАКИЕ ресурсы современных фпга это не жрет, тригер в люте может быть поставлен как с асинхронным сбросм, так и с синхронным. Более того синхронный сброс снимает проблему "гонки" сигнала сброса.

Я ни в коем случае не спорю, что синхронный сброс идеологически лучше, правильнее. Но насчет быстродействия все-таки не так однозначно. Для того, чтобы сигнал синхронного сброса/загрузки не ухудшал скорости, он должен идти мимо LUT. Да, в современных ПЛИС типа Циклона для этого есть аппаратная поддержка, в нем, согласн, нет смысла в асинхронном сбросе. Но вот в том же ACEX, который тоже еще пока не древность и отстой такой возможности, afair, нет (поправьте, если ошибаюсь) и тут этот синхронный сигнал придется вести через LUT со всеми вытекающими.

 

Насчет 400МГц, семейства виртек4, стратикс2 вполне реально могут работать на частотах до 500МГц, но вот кол-во уровней логики которые можно разложить между такими тригерам, к сожалению очень мало :(.

Стратикс бывает тольков BGA, а стратикс2 и подавно. Кста, а вёртексы4 в каких копусах бывают? Тоже только BGA?

[Yra 4]

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

 

С точки зрения моделирования поведение описаний должно быть разным. Формально, в первом случае Divider12 принимает значения от 0 до 12, однако 12 существует только в течение задержки присвоения Divider12 = #1 4'b0, так как блокирующее присваивания выполняются сразу, последовательность присваиваний прерывается только явными задержками. Во втором случае значение 12 действует в течение такта FastCLK + задержка на смену значения 1.

 

И еще одно мелкое наблюдение - лучше асинхронный сброс добавлять в список чувствительности блока.

 

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

Насчёт синхронного ресета: что касается третьего спартана, то никаких дополнительных ресурсов там не задействуется (сами триггеры в лутах поддерживают два типа ресета). К томуже SoC Wishbone предполагается синхронный сброс, в уважающих себя прцессорных ядрах тоже синхронный сброс. Синхронный сброс я использовал поначалу, теперь же приходится переделывать весь проект (глобальный синхронный сброс ещё- куда ни шло, а воб не дай Бог Вам активно использовать локальные асинхронные сбросы - такой глюк получится из- за иголок)