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

[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]

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

Если в ChipScope раскрыть шину, то видно что некоторые сигналы в шине задерживаются на один такт и это приводит к ошибке. Собственно, это мой первый проект и раньше с временными задержками в схеме не сталкивался. Алгоритм синхронный и почему возникают такие задержки мне не понятно. Вопрос в том, в какую сторону копать в чем проблема и как бороться с временными задержками в ПЛИС? Так как вопрос достаточно общий, не знаю, какую информацию еще надо предоставить и в процессе обсуждения выложу ее.

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

Копайте в сторону временных ограничений - Вы их вообще задавали? Какая частота и что говорит компилятор на наличие временных ошибок, есть ли уверенность что все временные ограничения заданы правильно?

[bognev]

Копайте в сторону временных ограничений - Вы их вообще задавали? Какая частота и что говорит компилятор на наличие временных ошибок, есть ли уверенность что все временные ограничения заданы правильно?

дело в том, что ucf файл создавал не я, но ограничения там стоят такие

CODE

NET "clk300" PERIOD = 370 MHz;
NET "clk_adc" PERIOD = 370 MHz;
NET "clk100" PERIOD = 110 MHz;
/*


NET "clk100" PERIOD = 110 MHz;
#NET "cal_done_inv_BUFG" PERIOD = 230 MHz;
NET "aclk" PERIOD = 120 MHz;
NET "clk200" PERIOD = 300 MHz;
NET "clkfft" PERIOD = 200 MHz;
#NET "clk400" PERIOD = 420 MHz;

NET "clk240" PERIOD = 240 MHz;

TIMESPEC TS_CLKADC = PERIOD "CLK_ADC" 160 MHz INPUT_JITTER 500 ps;
TIMESPEC TS_CLK100 = PERIOD "CLK100" 100 MHz INPUT_JITTER 500 ps;
NET "bl0sync_p" TNM_NET = "CLK100";
NET "ba0clkouta" TNM_NET = "CLK_ADC";
INST "const" AREA_GROUP = "pblock_const";
AREA_GROUP "pblock_const" RANGE=SLICE_X68Y128:SLICE_X71Y139;
INST "fifo_adm" AREA_GROUP = "pblock_fifo_adm";
AREA_GROUP "pblock_fifo_adm" RANGE=SLICE_X56Y170:SLICE_X63Y179;
AREA_GROUP "pblock_fifo_adm" RANGE=RAMB18_X3Y68:RAMB18_X3Y71;
AREA_GROUP "pblock_fifo_adm" RANGE=RAMB36_X3Y34:RAMB36_X3Y35;
INST "trans" AREA_GROUP = "pblock_trans";
AREA_GROUP "pblock_trans" RANGE=SLICE_X64Y161:SLICE_X71Y178;
INST "slave" AREA_GROUP = "pblock_slave";
AREA_GROUP "pblock_slave" RANGE=SLICE_X64Y121:SLICE_X67Y139;
INST "adc" AREA_GROUP = "pblock_adc";
AREA_GROUP "pblock_adc" RANGE=SLICE_X84Y121:SLICE_X91Y142;
AREA_GROUP "pblock_2" RANGE=SLICE_X22Y0:SLICE_X57Y239, SLICE_X2Y0:SLICE_X11Y239;
AREA_GROUP "pblock_2" RANGE=DSP48_X2Y0:DSP48_X3Y95;
AREA_GROUP "pblock_2" RANGE=RAMB18_X0Y0:RAMB18_X3Y95;
AREA_GROUP "pblock_2" RANGE=RAMB36_X0Y0:RAMB36_X3Y47;
AREA_GROUP "pblock_1" RANGE=SLICE_X10Y0:SLICE_X21Y239;
AREA_GROUP "pblock_1" RANGE=DSP48_X0Y0:DSP48_X1Y95;

Что касается временных ограничений, то компилятор сообщает следующее:

CODE

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/sysclk270_i" derived from PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 9.09090909 ns HIGH 50% SETUP HOLD 1.297ns -0.524ns 2.815ns 0 9 0 2848
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 = 9.09090909 ns HIGH 50% SETUP HOLD -7.302ns -2.980ns 11.847ns 9083 644 18031266 898848
Yes PERIOD analysis for net "clk300x" derived from NET "clk100" PERIOD = 9.09090909 ns HIGH 50% MINPERIOD 1.601ns 1.429ns 0 0
No PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 9.09090909 ns HIGH 50% SETUP HOLD MINPERIOD 2.626ns 0.124ns -0.216ns 1.919ns 4.761ns 0 0 2 0 0 432
No NET "clk_adc" PERIOD = 2.7027027 ns HIGH 50% SETUP HOLD -8.429ns -0.053ns 11.131ns 41580 61 112876868 1228
No NET "clk300" PERIOD = 2.7027027 ns HIGH 50% SETUP HOLD -5.020ns -0.099ns 7.722ns 4669 70 5668726 2209
Yes NET "clk100" PERIOD = 9.09090909 ns HIGH 50% SETUP HOLD 0.024ns 0.016ns 9.066ns 0 0 0 0

Route:441 - The router has detected a very high timing score (7319463) for this design. It is extremely unlikely the router will be able to meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the implementation or synthesis of logic in the critical timing path. If you would prefer the router continue trying to meet timing and you are willing to accept a long run time set the option "-xe c" to override the present behavior.

Route:441 - The router has detected a very high timing score (7319463) for this design. It is extremely unlikely the router will be able to meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the implementation or synthesis of logic in the critical timing path. If you would prefer the router continue trying to meet timing and you are willing to accept a long run time set the option "-xe c" to override the present behavior.

Route:441 - The router has detected a very high timing score (7319463) for this design. It is extremely unlikely the router will be able to meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the implementation or synthesis of logic in the critical timing path. If you would prefer the router continue trying to meet timing and you are willing to accept a long run time set the option "-xe c" to override the present behavior.


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