Ошибки при работе схемы на ПЛИС, Прошу помощи. Временный задержки Опции

[bognev]

Приветсвую всех!

Возникла такая проблема и требуется помощь в ее решении.
Пишу проект на virtex 6. В проекте реализован 16 канальный DDC. Работоспособность проверена на железке.
Мне необходимо разместить на каждом канале алгоритм подавления несинхронной помехи. Сам алгоритм подавления я написал и проверил также его работоспособность. Но при размещении 16 подавителей, по 1 на каждый канал столкнулся с проблемой нехватки ресурсов slice. Решение проблемы нашел в последовательной обработке на более высокой частоте. Но при этом столнулся с другой проблемой. При отладке в ChipScope видно, что схема ведет себя не корректно. Например, счетчик считает 1 2 3 !2! 4 5 6. Возникают значения, которых не должно быть. Если в ChipScope раскрыть шину, то видно что некоторые сигналы в шине задерживаются на один такт и это приводит к ошибке. Собственно, это мой первый проект и раньше с временными задержками в схеме не сталкивался. Алгоритм синхронный и почему возникают такие задержки мне не понятно. Вопрос в том, в какую сторону копать в чем проблема и как бороться с временными задержками в ПЛИС? Так как вопрос достаточно общий, не знаю, какую информацию еще надо предоставить и в процессе обсуждения выложу ее.

Заранее благодарю за помощь.

Сообщение отредактировал bognev - Jan 22 2014, 10:40

[bogaev_roman]

По поводу поста 9 - большое кол-во логических уровней - 10 и все они прилично размазаны, т.е. находятся на большом расстоянии друг от друга отчего задержка на путях - 73,4%. Эту задержку можно уменьшить, но общую от 12.249ns свести до 2.702ns Вы не сможете - меняйте алгоритм.
По поводу последнего поста все интересней - там переход из одного клокового домена в другой. У Вас там первый триггер тактируется частотой ddc/ddc/i_clk_0_tb которая 200МГц, а второй clk100 который 100МГц. При этом анализатор считает, что запас по 5ns и Clock Path Skew составляет от них 3.864ns (т.е. помимо задержки данных в том месте еще и одна частота задержана относительно другой существенно). Вопрос - как формируется частота i_clk_0_tb и завязана ли она на clk100? Или это какая-нибудь часть честного буфера пересинхронизации и на анализ можно вообще не обращать внимания?

[bognev]

По поводу поста 9 - большое кол-во логических уровней - 10 и все они прилично размазаны, т.е. находятся на большом расстоянии друг от друга отчего задержка на путях - 73,4%. Эту задержку можно уменьшить, но общую от 12.249ns свести до 2.702ns Вы не сможете - меняйте алгоритм.

В 9 посту алгоритмом является корка умножителя, разве она не должна быть сделана оптимальным образом?

По поводу последнего поста все интересней - там переход из одного клокового домена в другой. У Вас там первый триггер тактируется частотой ddc/ddc/i_clk_0_tb которая 200МГц, а второй clk100 который 100МГц. При этом анализатор считает, что запас по 5ns и Clock Path Skew составляет от них 3.864ns (т.е. помимо задержки данных в том месте еще и одна частота задержана относительно другой существенно). Вопрос - как формируется частота i_clk_0_tb и завязана ли она на clk100? Или это какая-нибудь часть честного буфера пересинхронизации и на анализ можно вообще не обращать внимания?

Клок i_clk_0_tb формируется в корке контроллера памяти на основе 200 МГц, которые в свою очередь формируются из 100 МГц с помощью mmcm_base от внешнего клока.
Если в кратце, то я во внешней памяти DDRII SRAM организовал циклический буфер, память работает на 200 МГц.
Данные из памяти, я преобразую в последовательные в схеме которая работает на 100 МГц.

Вообще схема у меня работает так. Есть данные с АЦП на входе с частотой 160 МГц, 16 каналов. С помощью DDС я понижаю частоту дискретизации сигнала до 2 МГц. По каждому отсчету вырабатывет флаг готовности на выходе DDC. Данные с каждого из 16 каналов идут параллельно. Потом эти данные с частотой 200 МГц записываются в память и считываются. Соответственно, по сигналу готовности с памяти записываю данные в регистр, а потом преобразую в последовательный поток схемой, которая работает на частоте 100 МГц. То есть, есть поток данных, каждый отсчет длительностью 1/2Мгц = 500 нс, но он состоит из 200МГц/2МГц = 100 одинаковых отсчетов.

Сообщение отредактировал bognev - Jan 23 2014, 10:32

[bogaev_roman]

В 9 посту алгоритмом является корка умножителя, разве она не должна быть сделана оптимальным образом?

Корка умножителя сколько на сколько? Какие цифры дает документация по максимальной частоте на такие умножители? И к этой цифре еще нужно прибавить 5,320 ns, которые у Вас набегают до входа умножителя (посмотрите на координаты)

Код

SLICE_X75Y110.BQ Tcko 0.337 ddc/adc1_x<9>_REPLICA_1417
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000000b0
SLICE_X57Y35.C1 net (fanout=1) 5.320 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000153

Я думаю что 370МГц здесь получить нереально.

Если в кратце, то я во внешней памяти DDRII SRAM организовал циклический буфер, память работает на 200 МГц.
Данные из памяти, я преобразую в последовательные в схеме которая работает на 100 МГц.

Эти данные торчат на выходе корки (конкретно на регистрах) и вы их считываете на пониженной частоте, я правильно понял? Просто Clock Path Skew очень большой, такое ощущение, что частота ddc/ddc/i_clk_0_tb пущена по обычной (сигнальной) цепи, а не на клоковой. Тут можно поробовать либо принудительно ее пустить по клоковой шине (региональный клок например) и таким образом Clock Path Skew должен уменьшиться, либо триггеры типа ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14 принудительно расположить (констрейнами задать координаты) рядом с ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3_14.

[bognev]

Корка умножителя сколько на сколько? Какие цифры дает документация по максимальной частоте на такие умножители? И к этой цифре еще нужно прибавить 5,320 ns, которые у Вас набегают до входа умножителя (посмотрите на координаты)

Код

SLICE_X75Y110.BQ Tcko 0.337 ddc/adc1_x<9>_REPLICA_1417
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000000b0
SLICE_X57Y35.C1 net (fanout=1) 5.320 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000153

Я думаю что 370МГц здесь получить нереально.

Я поправил ucf файл в соответсвии с тем, что на самом деле имею

Код

NET "clk300"      PERIOD = 300 MHz;
NET "clk_adc"      PERIOD = 160 MHz;
NET "clk100"      PERIOD = 100 MHz;
NET "clk100"      PERIOD = 100 MHz;
NET "clk200"      PERIOD = 200 MHz;

370 МГц было специально задрано.

Конечно, количество временных ошибок уменьштлось с 50 с лишним тысяч, но они все равно остались:

Код

Met Constraint Check Worst Case Slack Best Case Achievable Timing Errors Timing Score
No PERIOD analysis for net "ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/sysclk0_i" derived from PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 10 ns HIGH 50% SETUP HOLD -0.246ns -3.005ns 5.246ns  35 16 3241 45928
No PERIOD analysis for net "ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/sysclk270_i" derived from PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 10 ns HIGH 50% SETUP HOLD 0.247ns -2.095ns 4.670ns  0 8 0 16760
No NET "clk300" PERIOD = 3.33333333 ns HIGH 50% SETUP HOLD -1.766ns 0.014ns 5.099ns  20 0 13311 0
No NET "clk_adc" PERIOD = 6.25 ns HIGH 50% SETUP HOLD -1.026ns 0.002ns 7.276ns  2162 0 520393 0
No NET "clk100" PERIOD = 10 ns HIGH 50% SETUP HOLD -0.949ns 0.054ns 11.898ns  2971 0 968494 0
Yes PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 10 ns HIGH 50% SETUP HOLD MINPERIOD 2.981ns 0.135ns 0.239ns 2.019ns 4.761ns 0 0 0 0 0 0
Yes PERIOD analysis for net "clk300x" derived from NET "clk100" PERIOD = 10 ns HIGH 50% MINPERIOD 1.904ns 1.429ns 0 0

Корка умножителя сколько на сколько? Какие цифры дает документация по максимальной частоте на такие умножители? И к этой цифре еще нужно прибавить 5,320 ns, которые у Вас набегают до входа умножителя (посмотрите на координаты)

16 бит на 16 бит, по датащиту максимальная частота 450 МГц. А работает на 160 МГц. С запасом даже.

Эти данные торчат на выходе корки (конкретно на регистрах) и вы их считываете на пониженной частоте, я правильно понял?

Так и есть торчат на 200 МГц, считываю на 100 МГц по сигналу готовности.

Просто Clock Path Skew очень большой, такое ощущение, что частота ddc/ddc/i_clk_0_tb пущена по обычной (сигнальной) цепи, а не на клоковой. Тут можно поробовать либо принудительно ее пустить по клоковой шине (региональный клок например) и таким образом Clock Path Skew должен уменьшиться, либо триггеры типа ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14 принудительно расположить (констрейнами задать координаты) рядом с ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3_14.

Клок i_clk_0_tb формируется из DCM_ADV. И подключен к глобальному клоку.

Сообщение отредактировал bognev - Jan 23 2014, 11:18

[o_khavin]

16 бит на 16 бит, по датащиту максимальная частота 450 МГц. А работает на 160 МГц. С запасом даже.

А мелкие букафки в даташите читали? Про то, в каком конкретно режиме работы умножителя получаются эти 450Mhz. Или просто посмотрели максимальную цифру и обрадовались?
Кроме того, весь этот Ваш "запас" в 4ns плавно растворяется в задержке пробегания перед умножителем, которая составляет 5,2ns.

Сообщение отредактировал o_khavin - Jan 23 2014, 22:26