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

[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

[bogaev_roman]

Я давно в ISE не работал, но все равно тут можно сказать, что частоты у Вас высокие и разводится все с временными ошибками. Причем ошибки есть и по сетапам и по холдам и в разных клоковых доменах. Причем ошибки, скажем, по сетапу для clk_adc вообще заоблачные - более 3 периодов. Могу только посоветовать разбираться последовательно с каждым клоком и смотреть на суммарные задержки и, скорее всего, менять алгоритм - в ином случае это работать не будет, тут даже чипскопом смотреть не нужно. Т.е. по сути получается что у Вас часть логики реально не синхронна ибо в некоторых путях суммарная задержка от выхода триггера до входа следующего триггера больше такта рабочей частоты.

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

[bognev]

А каким способом можно уменьшить эти нарушения? Как строить алгоритм, чтобы минимизировать временные задержки?

[bogaev_roman]

А каким способом можно уменьшить эти нарушения? Как строить алгоритм, чтобы минимизировать временные задержки?

Способов много, но нужно сначала узнать, что за пути, есть ли возможность разрезать путь дополнительным регистром. Иногда помогает только изменение алгоритма.
А вообще алгоритмов вытягивания много и по сложности они разные - начиная от дублирования логики и заканчивая игрой настроек в САПР или жестким фиксированием отдельных модулей (в виде разведенных нетлистов) на кристалле. Все зависит от конкретной ситуации.

[iosifk]

Возникла такая проблема и требуется помощь в ее решении.
Пишу проект на virtex 6. В проекте реализован 16 канальный DDC. Работоспособность проверена на железке.

У Вас в файле написано:
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;

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;

и это еще не все... Откуда столько частот? Они что, извне приходят в кристалл?
Как сделан переход между ними?

[bognev]

Способов много, но нужно сначала узнать, что за пути, есть ли возможность разрезать путь дополнительным регистром. Иногда помогает только изменение алгоритма.
А вообще алгоритмов вытягивания много и по сложности они разные - начиная от дублирования логики и заканчивая игрой настроек в САПР или жестким фиксированием отдельных модулей (в виде разведенных нетлистов) на кристалле. Все зависит от конкретной ситуации.

А вы не могли бы привести где более подробно можно почитать? Как повлияет установка дополнительно регистра? Ресурс в интернете или книга, аппнот?

и это еще не все... Откуда столько частот? Они что, извне приходят в кристалл?
Как сделан переход между ними?

На плис клоки clk100 100МГц и CLK_ADC 160 МГц приходят извне. На основе клока CLK100 формируются 200 МГц и 300 МГц с помощью MMCM_BASE.
Клоки clkfft, clk400, сlk240, aclk не используются и не формируются.

[bognev]

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

Если я правильно вас понял, то

CODE

Timing constraint: NET "clk_adc" PERIOD = 2.7027027 ns HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
48009355 paths analyzed, 160420 endpoints analyzed, 32116 failing endpoints
32116 timing errors detected. (32028 setup errors, 88 hold errors, 0 component switching limit errors)
Minimum period is 12.125ns.
--------------------------------------------------------------------------------

Paths for end point ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp_30 (SLICE_X57Y28.CIN), 167868 paths
--------------------------------------------------------------------------------
Slack (setup path): -9.423ns (requirement - (data path - clock path skew + uncertainty))
Source: ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000000b0 (FF)
Destination: ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp_30 (FF)
Requirement: 2.702ns
Data Path Delay: 12.249ns (Levels of Logic = 10)(Component delays alone exceeds constraint)
Clock Path Skew: 0.159ns (1.635 - 1.476)
Source Clock: clk_adc rising at 0.000ns
Destination Clock: clk_adc rising at 2.702ns
Clock Uncertainty: 0.035ns

Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns

Maximum Data Path at Slow Process Corner: ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000000b0 to ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp_30
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
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
SLICE_X57Y35.CMUX Tilo 0.191 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000234
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000002f9/LUT5
SLICE_X57Y35.D3 net (fanout=2) 0.451 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000463
SLICE_X57Y35.COUT Topcyd 0.319 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000234
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000002f8/LUT6
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000002cd
SLICE_X57Y36.CIN net (fanout=1) 0.000 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig0000042a
SLICE_X57Y36.DQ Tito_logic 0.537 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000238
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000002c5
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000238_rt
SLICE_X60Y33.D2 net (fanout=1) 0.863 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000238
SLICE_X60Y33.DMUX Tilo 0.196 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig000001f8
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk0000022a/LUT5
SLICE_X60Y34.A2 net (fanout=2) 0.599 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000393
SLICE_X60Y34.COUT Topcya 0.410 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig000001fc
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk00000229/LUT6
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000001f3
SLICE_X60Y35.CIN net (fanout=1) 0.000 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig0000035c
SLICE_X60Y35.COUT Tbyp 0.078 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000200
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000001eb
SLICE_X60Y36.CIN net (fanout=1) 0.000 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000358
SLICE_X60Y36.AQ Tito_logic 0.438 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000204
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000001e3
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000201_rt
SLICE_X57Y27.A2 net (fanout=1) 1.115 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig00000201
SLICE_X57Y27.AMUX Tilo 0.194 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp<28>
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000001bc/LUT5
SLICE_X57Y27.B4 net (fanout=2) 0.644 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig0000031e
SLICE_X57Y27.COUT Topcyb 0.404 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp<28>
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk000001bb/LUT6
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk0000017e
SLICE_X57Y28.CIN net (fanout=1) 0.000 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/sig000002f1
SLICE_X57Y28.CLK Tcinck 0.153 ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp<31>
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U1/blk00000175
ddc/ddc/x_gen_mult_s4[0].x_mult_q/U2/outp_30
------------------------------------------------- ---------------------------
Total 12.249ns (3.257ns logic, 8.992ns route)
(26.6% logic, 73.4% route)

[gibson1980]

Решение проблемы нашел в последовательной обработке на более высокой частоте.

Может попробовать комбинировать? К примеру 4х4.
Если есть Коре элементы, перекинуть их на DSP, тем самым освободить слайсы.

Сообщение отредактировал gibson1980 - Jan 23 2014, 07:43

[bognev]

Может попробовать комбинировать? К примеру 4х4.
Если есть Коре элементы, перекинуть их на DCM, тем самым освободить слайсы.

Пробовал комбинировать 8x2, ошибки также вылазят. Ошибки вылазят на простом счетчике даже при остутсвии алгоритма подавления несинхронных помех.

Если есть Коре элементы, перекинуть их на DCM, тем самым освободить слайсы.

Можно по подробнее? Коре элементы есть, но это фильтры и умножители, я не до конца вас понимаю.

[gibson1980]

Можно по подробнее? Коре элементы есть, но это фильтры и умножители, я не до конца вас понимаю.

Может я ошибаюсь, но вот...


Умножители кстати лучше тоже на DSP делать, поддерживаются более высокие скорость, экономятся ресурсы ПЛИС ну и т.д. XtremeDSP 48 Slice

Сообщение отредактировал gibson1980 - Jan 23 2014, 08:05

[bognev]

Может я ошибаюсь, но вот...

Я попробую снять эту опцию, если я правильно вас понимаю, то это уменьшит использование слайсов и как результат снизит временные ошибки?

[gibson1980]

Наоборот поставить. Я так понимаю что должно уменьшить количество слайсов
Тут есть пример умножителя на DSP.

Эскизы прикрепленных изображений

 

[bognev]

Наоборот поставить. Я так понимаю что должно уменьшить количество слайсов
Тут есть пример умножителя на DSP.

К сожалению, эта опция уже стоит.
А в корках умножителей тоже выбрано использование DSP блоков.