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

[bognev]

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

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

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

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

[iosifk]

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

На самом деле, есть еще один вариант.
Не последовательно на более высокой частоте, а многопоточно, но тоже на более высокой частоте...
Т.е. есть вычислитель и есть память. Из памяти извлекаются данные для N-го потока, выполняется операция и данные опять отправляются в память... При этом конвейером извлекаются данные для другого потока... Для Ваших 16-ти потоков потребуется память шириной "сколько надо" х 16... Под шириной я понимаю все или часть битов, которые извлекаются для обработки...

[bognev]

На самом деле, есть еще один вариант.
Не последовательно на более высокой частоте, а многопоточно, но тоже на более высокой частоте...
Т.е. есть вычислитель и есть память. Из памяти извлекаются данные для N-го потока, выполняется операция и данные опять отправляются в память... При этом конвейером извлекаются данные для другого потока... Для Ваших 16-ти потоков потребуется память шириной "сколько надо" х 16... Под шириной я понимаю все или часть битов, которые извлекаются для обработки...

Вариант понятен, но скажем если без алгоритма в чипскопе я наблюдаю такую картинку:

TRIG1, TRIG3, TRIG3, TRIG4 - это отсчеты 16и каналов последовательно передаются на вход алгоритма, а в TRIG5 счетчик, который синхронно с отсчетом в одно время должен менять свое значение, но если посмотреть на шину, то видно, что есть задержка.
При этом алгоритм подавления сейчас в схеме закомментирован. Если сейчас так схема работает, то более высокая частота или конвейер вряд ли спасут.


Вот вопрос такой

CODE

Timing constraint: NET "clk100" PERIOD = 10 ns HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
22078 paths analyzed, 14128 endpoints analyzed, 2971 failing endpoints
2971 timing errors detected. (2971 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 11.898ns.
--------------------------------------------------------------------------------

Paths for end point ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14 (SLICE_X21Y127.CX), 1 path
--------------------------------------------------------------------------------
Slack (setup path): -0.949ns (requirement - (data path - clock path skew + uncertainty))
Source: ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3_14 (FF)
Destination: ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14 (FF)
Requirement: 5.000ns
Data Path Delay: 1.592ns (Levels of Logic = 0)
Clock Path Skew: -3.864ns (1.420 - 5.284)
Source Clock: ddc/ddc/i_clk_0_tb rising at 5.000ns
Destination Clock: clk100 rising at 10.000ns
Clock Uncertainty: 0.493ns

Clock Uncertainty: 0.493ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Discrete Jitter (DJ): 0.220ns
Phase Error (PE): 0.377ns

Maximum Data Path at Slow Process Corner: ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3_14 to ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X29Y143.CQ Tcko 0.337 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3<15>
ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3_14
SLICE_X21Y127.CX net (fanout=1) 1.221 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_3<14>
SLICE_X21Y127.CLK Tdick 0.034 ddc/ddc/SW_IN_I/user_rd_data_10_3_ii<15>
ddc/ddc/SW_IN_I/user_rd_data_10_3_ii_14
------------------------------------------------- ---------------------------
Total 1.592ns (0.371ns logic, 1.221ns route)
(23.3% logic, 76.7% route)

--------------------------------------------------------------------------------

В Timing Report я вижу максимальный путь между двумя FF на выходе блока u_ddrii_tb_top_0 и на входе другого блока SW_IN_I, каким образом уменьшить эту задержку?