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

[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 блоков.

[gibson1980]

В корках умножителей речь идет вроде о LUTах, посмотри еще вот этот пример, вот там точно умножение будет на DSP...


вообще что за ПЛИС используется?

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

[bognev]

В корках умножителей речь идет вроде о LUTах, посмотри еще вот этот пример, вот там точно умножение будет на DSP...


вообще что за ПЛИС используется?

ПЛИС - virtex 6.

В корке умножителей есть выбор:

[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, каким образом уменьшить эту задержку?

[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

[Maverick]

проект синхронный? асинхронщины нет?
переходы из разных клоковых доменов организованы правильно? например, фифо Вы применяете? как передаете сигналы готовности схемы из разных клоковых доменов?

про счетчик, который не правильно считает: какой он разрядности? на какой частоте работает?

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

PS В общем здесь нужно смотреть Вашу схематехнику или описание схемы....
PS PS для начала возможно не помешает какая-то блок-схема...

[o_khavin]

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

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

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

[bognev]

проект синхронный? асинхронщины нет?
переходы из разных клоковых доменов организованы правильно? например, фифо Вы применяете? как передаете сигналы готовности схемы из разных клоковых доменов?

про счетчик, который не правильно считает: какой он разрядности? на какой частоте работает?

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

PS В общем здесь нужно смотреть Вашу схематехнику или описание схемы....
PS PS для начала возможно не помешает какая-то блок-схема...

асинхронщины нет.
переходы из разных клоковых доменов скорее всего сделаны не правильно, фифо я не применяю, сигналы готовности перетактирую под нужнуй клок.
счетчик работал на 100, 160, 200 Мгцах

в xilinx ise блоки фильтров, умножителей я генерил в coregen, остальные части схемы сам собирал.

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

Я нашел в чем причина такой временной задержки, она не в самой корке, а в блоке округления и сдвига после, которые я сам и нагородил. Убрал их, скорее всего ошибки в этой части схемы уйдут.

[Maverick]

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

рекомендую сделать (по ссылке части 11, 12)

[bognev]

рекомендую сделать (по ссылке части 11, 12)

Спасибо!

Временные ошибки удалось свести с 50 с лишним тысяч до 33.
Сейчас основные ошибки в модуле работы с памятью.

[Bad0512]

Спасибо!

Временные ошибки удалось свести с 50 с лишним тысяч до 33.
Сейчас основные ошибки в модуле работы с памятью.

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

[bognev]

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

RКаким образом можно это проверить? Посмотреть как это развелось в плис? Или в коде?

[Bad0512]

RКаким образом можно это проверить? Посмотреть как это развелось в плис? Или в коде?

Можно посмотреть в тайминг репорте. Если регистры используются, то должен фигурировать параметр TRCKO_DO_REG.
Если не используются, то TRCKO_DO. Также это можно увидеть с помощью Xilinx Desing Editor (XDE) или же в Planahead.
К примеру для 6 виртекса -2 спидгрейда эти величины (согласно даташиту) составляют 1.79nS и 0.66nS соответственно.

З Ы Внимательный читатель может заметить, что даже при использовании регистров времянка с выхода памяти всё равно чуть хуже,
чем с выхода обычного CLB. Поэтому в особо тяжелых случаях приходится ставить дополнительный слой обычных триггеров на выходе памяти
тем самым увеличивая задержку чтения, но и увеличивая быстродействие.

[bognev]

Временные ошибки в памяти свелись к сигналу сброса

CODE

Hold Paths: 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%; divided by 2.00 to 5 nS
duty cycle corrected to 5 nS HIGH 2.500 nS

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

Paths for end point ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst0_sync_r_23_33 (SLICE_X32Y128.SR), 1 path
--------------------------------------------------------------------------------
Slack (hold path): -3.017ns (requirement - (clock path skew + uncertainty - data path))
Source: slave/reset_out (FF)
Destination: ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst0_sync_r_23_33 (FF)
Requirement: 0.000ns
Data Path Delay: 1.298ns (Levels of Logic = 1)
Clock Path Skew: 3.822ns (5.308 - 1.486)
Source Clock: clk100 rising at 0.000ns
Destination Clock: ddc/ddc/i_clk_0_tb rising at 0.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

Minimum Data Path at Slow Process Corner: slave/reset_out to ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst0_sync_r_23_33
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X37Y121.AQ Tcko 0.270 slave/reset_out
slave/reset_out
SLICE_X34Y121.D5 net (fanout=10) 0.404 slave/reset_out
SLICE_X34Y121.D Tilo 0.055 ddc/ddc/U_MEM_CONTROLLER/u_ddrii_top_0/U_DDRII_PHY_TOP/U_DDRII_PHY_IO/U_DDRII_PHY_INIT_SM/idly_ctrl_ready_r1
ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst_tmp1
SLICE_X32Y128.SR net (fanout=158) 0.431 ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst_tmp
SLICE_X32Y128.CLK Tremck (-Th) -0.138 ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst0_sync_r<23>_36
ddc/ddc/U_MEM_CONTROLLER/u_ddrii_infrastructure/rst0_sync_r_23_33
------------------------------------------------- ---------------------------
Total 1.298ns (0.463ns logic, 0.835ns route)
(35.7% logic, 64.3% route)

Я догадываюсь в чем ошибка.
Есть внешний сигнал сброса rst, в модуле slave reset_out получается следующим образом
reset_out <= rst_i1 when rising_edge( clk100 );
этот сигнал я подаю на контроллер памяти, работающий на частоте i_clk_0_tb 200 Мгц.
Отсюда возникает такая большая задержка?
После исправления всех временных ошибок косяки пропали. Спасибо за помощь всем!

Сообщение отредактировал bognev - Jan 27 2014, 09:39

[bognev]

Стал дальше реализовывать проект и столкнулся с новыми временными ошибками.

CODE

process(clk_0)
variable rdy_in : std_logic;
begin
if(rising_edge(clk_0)) then
if(reset_clk_0 = '1') then
rdy <= '0';
rdy_in := '0';

user_rd_data_0_0_i <= (others => '0');
user_rd_data_1_0_i <= (others => '0');
user_rd_data_2_0_i <= (others => '0');
user_rd_data_3_0_i <= (others => '0');
user_rd_data_4_0_i <= (others => '0');
user_rd_data_5_0_i <= (others => '0');
user_rd_data_6_0_i <= (others => '0');
user_rd_data_7_0_i <= (others => '0');
user_rd_data_8_0_i <= (others => '0');
user_rd_data_9_0_i <= (others => '0');
user_rd_data_10_0_i <= (others => '0');
user_rd_data_11_0_i <= (others => '0');
user_rd_data_12_0_i <= (others => '0');
user_rd_data_13_0_i <= (others => '0');
user_rd_data_14_0_i <= (others => '0');
user_rd_data_15_0_i <= (others => '0');

user_rd_data_0_1_i <= (others => '0');
user_rd_data_1_1_i <= (others => '0');
user_rd_data_2_1_i <= (others => '0');
user_rd_data_3_1_i <= (others => '0');
user_rd_data_4_1_i <= (others => '0');
user_rd_data_5_1_i <= (others => '0');
user_rd_data_6_1_i <= (others => '0');
user_rd_data_7_1_i <= (others => '0');
user_rd_data_8_1_i <= (others => '0');
user_rd_data_9_1_i <= (others => '0');
user_rd_data_10_1_i <= (others => '0');
user_rd_data_11_1_i <= (others => '0');
user_rd_data_12_1_i <= (others => '0');
user_rd_data_13_1_i <= (others => '0');
user_rd_data_14_1_i <= (others => '0');
user_rd_data_15_1_i <= (others => '0');

user_rd_data_0_2_i <= (others => '0');
user_rd_data_1_2_i <= (others => '0');
user_rd_data_2_2_i <= (others => '0');
user_rd_data_3_2_i <= (others => '0');
user_rd_data_4_2_i <= (others => '0');
user_rd_data_5_2_i <= (others => '0');
user_rd_data_6_2_i <= (others => '0');
user_rd_data_7_2_i <= (others => '0');
user_rd_data_8_2_i <= (others => '0');
user_rd_data_9_2_i <= (others => '0');
user_rd_data_10_2_i <= (others => '0');
user_rd_data_11_2_i <= (others => '0');
user_rd_data_12_2_i <= (others => '0');
user_rd_data_13_2_i <= (others => '0');
user_rd_data_14_2_i <= (others => '0');
user_rd_data_15_2_i <= (others => '0');
-----------------------------------------------------
user_rd_data_0_3_i <= (others => '0');
user_rd_data_1_3_i <= (others => '0');
user_rd_data_2_3_i <= (others => '0');
user_rd_data_3_3_i <= (others => '0');
user_rd_data_4_3_i <= (others => '0');
user_rd_data_5_3_i <= (others => '0');
user_rd_data_6_3_i <= (others => '0');
user_rd_data_7_3_i <= (others => '0');
user_rd_data_8_3_i <= (others => '0');
user_rd_data_9_3_i <= (others => '0');
user_rd_data_10_3_i <= (others => '0');
user_rd_data_11_3_i <= (others => '0');
user_rd_data_12_3_i <= (others => '0');
user_rd_data_13_3_i <= (others => '0');
user_rd_data_14_3_i <= (others => '0');
user_rd_data_15_3_i <= (others => '0');
------------------------------------------------------
user_rd_data_0_4_i <= (others => '0');
user_rd_data_1_4_i <= (others => '0');
user_rd_data_2_4_i <= (others => '0');
user_rd_data_3_4_i <= (others => '0');
user_rd_data_4_4_i <= (others => '0');
user_rd_data_5_4_i <= (others => '0');
user_rd_data_6_4_i <= (others => '0');
user_rd_data_7_4_i <= (others => '0');
user_rd_data_8_4_i <= (others => '0');
user_rd_data_9_4_i <= (others => '0');
user_rd_data_10_4_i <= (others => '0');
user_rd_data_11_4_i <= (others => '0');
user_rd_data_12_4_i <= (others => '0');
user_rd_data_13_4_i <= (others => '0');
user_rd_data_14_4_i <= (others => '0');
user_rd_data_15_4_i <= (others => '0');
------------------------------------------------------
user_rd_data_0_5_i <= (others => '0');
user_rd_data_1_5_i <= (others => '0');
user_rd_data_2_5_i <= (others => '0');
user_rd_data_3_5_i <= (others => '0');
user_rd_data_4_5_i <= (others => '0');
user_rd_data_5_5_i <= (others => '0');
user_rd_data_6_5_i <= (others => '0');
user_rd_data_7_5_i <= (others => '0');
user_rd_data_8_5_i <= (others => '0');
user_rd_data_9_5_i <= (others => '0');
user_rd_data_10_5_i <= (others => '0');
user_rd_data_11_5_i <= (others => '0');
user_rd_data_12_5_i <= (others => '0');
user_rd_data_13_5_i <= (others => '0');
user_rd_data_14_5_i <= (others => '0');
user_rd_data_15_5_i <= (others => '0');
------------------------------------------------------
user_rd_data_0_6_i <= (others => '0');
user_rd_data_1_6_i <= (others => '0');
user_rd_data_2_6_i <= (others => '0');
user_rd_data_3_6_i <= (others => '0');
user_rd_data_4_6_i <= (others => '0');
user_rd_data_5_6_i <= (others => '0');
user_rd_data_6_6_i <= (others => '0');
user_rd_data_7_6_i <= (others => '0');
user_rd_data_8_6_i <= (others => '0');
user_rd_data_9_6_i <= (others => '0');
user_rd_data_10_6_i <= (others => '0');
user_rd_data_11_6_i <= (others => '0');
user_rd_data_12_6_i <= (others => '0');
user_rd_data_13_6_i <= (others => '0');
user_rd_data_14_6_i <= (others => '0');
user_rd_data_15_6_i <= (others => '0');
------------------------------------------------------
user_rd_data_0_7_i <= (others => '0');
user_rd_data_1_7_i <= (others => '0');
user_rd_data_2_7_i <= (others => '0');
user_rd_data_3_7_i <= (others => '0');
user_rd_data_4_7_i <= (others => '0');
user_rd_data_5_7_i <= (others => '0');
user_rd_data_6_7_i <= (others => '0');
user_rd_data_7_7_i <= (others => '0');
user_rd_data_8_7_i <= (others => '0');
user_rd_data_9_7_i <= (others => '0');
user_rd_data_10_7_i <= (others => '0');
user_rd_data_11_7_i <= (others => '0');
user_rd_data_12_7_i <= (others => '0');
user_rd_data_13_7_i <= (others => '0');
user_rd_data_14_7_i <= (others => '0');
user_rd_data_15_7_i <= (others => '0');
------------------------------------------------------
user_rd_data_0_8_i <= (others => '0');
user_rd_data_1_8_i <= (others => '0');
user_rd_data_2_8_i <= (others => '0');
user_rd_data_3_8_i <= (others => '0');
user_rd_data_4_8_i <= (others => '0');
user_rd_data_5_8_i <= (others => '0');
user_rd_data_6_8_i <= (others => '0');
user_rd_data_7_8_i <= (others => '0');
user_rd_data_8_8_i <= (others => '0');
user_rd_data_9_8_i <= (others => '0');
user_rd_data_10_8_i <= (others => '0');
user_rd_data_11_8_i <= (others => '0');
user_rd_data_12_8_i <= (others => '0');
user_rd_data_13_8_i <= (others => '0');
user_rd_data_14_8_i <= (others => '0');
user_rd_data_15_8_i <= (others => '0');
------------------------------------------------------
rdy <= '0';
rdy_in := '0';
------------------------------------------------------
user_rd_data_0_0 <= (others => '0');
user_rd_data_1_0 <= (others => '0');
user_rd_data_2_0 <= (others => '0');
user_rd_data_3_0 <= (others => '0');
user_rd_data_4_0 <= (others => '0');
user_rd_data_5_0 <= (others => '0');
user_rd_data_6_0 <= (others => '0');
user_rd_data_7_0 <= (others => '0');
user_rd_data_8_0 <= (others => '0');
user_rd_data_9_0 <= (others => '0');
user_rd_data_10_0 <= (others => '0');
user_rd_data_11_0 <= (others => '0');
user_rd_data_12_0 <= (others => '0');
user_rd_data_13_0 <= (others => '0');
user_rd_data_14_0 <= (others => '0');
user_rd_data_15_0 <= (others => '0');
------------------------------------------------------
user_rd_data_0_1 <= (others => '0');
user_rd_data_1_1 <= (others => '0');
user_rd_data_2_1 <= (others => '0');
user_rd_data_3_1 <= (others => '0');
user_rd_data_4_1 <= (others => '0');
user_rd_data_5_1 <= (others => '0');
user_rd_data_6_1 <= (others => '0');
user_rd_data_7_1 <= (others => '0');
user_rd_data_8_1 <= (others => '0');
user_rd_data_9_1 <= (others => '0');
user_rd_data_10_1 <= (others => '0');
user_rd_data_11_1 <= (others => '0');
user_rd_data_12_1 <= (others => '0');
user_rd_data_13_1 <= (others => '0');
user_rd_data_14_1 <= (others => '0');
user_rd_data_15_1 <= (others => '0');
------------------------------------------------------
user_rd_data_0_2 <= (others => '0');
user_rd_data_1_2 <= (others => '0');
user_rd_data_2_2 <= (others => '0');
user_rd_data_3_2 <= (others => '0');
user_rd_data_4_2 <= (others => '0');
user_rd_data_5_2 <= (others => '0');
user_rd_data_6_2 <= (others => '0');
user_rd_data_7_2 <= (others => '0');
user_rd_data_8_2 <= (others => '0');
user_rd_data_9_2 <= (others => '0');
user_rd_data_10_2 <= (others => '0');
user_rd_data_11_2 <= (others => '0');
user_rd_data_12_2 <= (others => '0');
user_rd_data_13_2 <= (others => '0');
user_rd_data_14_2 <= (others => '0');
user_rd_data_15_2 <= (others => '0');
------------------------------------------------------
user_rd_data_0_3 <= (others => '0');
user_rd_data_1_3 <= (others => '0');
user_rd_data_2_3 <= (others => '0');
user_rd_data_3_3 <= (others => '0');
user_rd_data_4_3 <= (others => '0');
user_rd_data_5_3 <= (others => '0');
user_rd_data_6_3 <= (others => '0');
user_rd_data_7_3 <= (others => '0');
user_rd_data_8_3 <= (others => '0');
user_rd_data_9_3 <= (others => '0');
user_rd_data_10_3 <= (others => '0');
user_rd_data_11_3 <= (others => '0');
user_rd_data_12_3 <= (others => '0');
user_rd_data_13_3 <= (others => '0');
user_rd_data_14_3 <= (others => '0');
user_rd_data_15_3 <= (others => '0');
------------------------------------------------------
user_rd_data_0_4 <= (others => '0');
user_rd_data_1_4 <= (others => '0');
user_rd_data_2_4 <= (others => '0');
user_rd_data_3_4 <= (others => '0');
user_rd_data_4_4 <= (others => '0');
user_rd_data_5_4 <= (others => '0');
user_rd_data_6_4 <= (others => '0');
user_rd_data_7_4 <= (others => '0');
user_rd_data_8_4 <= (others => '0');
user_rd_data_9_4 <= (others => '0');
user_rd_data_10_4 <= (others => '0');
user_rd_data_11_4 <= (others => '0');
user_rd_data_12_4 <= (others => '0');
user_rd_data_13_4 <= (others => '0');
user_rd_data_14_4 <= (others => '0');
user_rd_data_15_4 <= (others => '0');

user_rd_data_0_5 <= (others => '0');
user_rd_data_1_5 <= (others => '0');
user_rd_data_2_5 <= (others => '0');
user_rd_data_3_5 <= (others => '0');
user_rd_data_4_5 <= (others => '0');
user_rd_data_5_5 <= (others => '0');
user_rd_data_6_5 <= (others => '0');
user_rd_data_7_5 <= (others => '0');
user_rd_data_8_5 <= (others => '0');
user_rd_data_9_5 <= (others => '0');
user_rd_data_10_5 <= (others => '0');
user_rd_data_11_5 <= (others => '0');
user_rd_data_12_5 <= (others => '0');
user_rd_data_13_5 <= (others => '0');
user_rd_data_14_5 <= (others => '0');
user_rd_data_15_5 <= (others => '0');
------------------------------------------------------
user_rd_data_0_6 <= (others => '0');
user_rd_data_1_6 <= (others => '0');
user_rd_data_2_6 <= (others => '0');
user_rd_data_3_6 <= (others => '0');
user_rd_data_4_6 <= (others => '0');
user_rd_data_5_6 <= (others => '0');
user_rd_data_6_6 <= (others => '0');
user_rd_data_7_6 <= (others => '0');
user_rd_data_8_6 <= (others => '0');
user_rd_data_9_6 <= (others => '0');
user_rd_data_10_6 <= (others => '0');
user_rd_data_11_6 <= (others => '0');
user_rd_data_12_6 <= (others => '0');
user_rd_data_13_6 <= (others => '0');
user_rd_data_14_6 <= (others => '0');
user_rd_data_15_6 <= (others => '0');

user_rd_data_0_7 <= (others => '0');
user_rd_data_1_7 <= (others => '0');
user_rd_data_2_7 <= (others => '0');
user_rd_data_3_7 <= (others => '0');
user_rd_data_4_7 <= (others => '0');
user_rd_data_5_7 <= (others => '0');
user_rd_data_6_7 <= (others => '0');
user_rd_data_7_7 <= (others => '0');
user_rd_data_8_7 <= (others => '0');
user_rd_data_9_7 <= (others => '0');
user_rd_data_10_7 <= (others => '0');
user_rd_data_11_7 <= (others => '0');
user_rd_data_12_7 <= (others => '0');
user_rd_data_13_7 <= (others => '0');
user_rd_data_14_7 <= (others => '0');
user_rd_data_15_7 <= (others => '0');
------------------------------------------------------
user_rd_data_0_8 <= (others => '0');
user_rd_data_1_8 <= (others => '0');
user_rd_data_2_8 <= (others => '0');
user_rd_data_3_8 <= (others => '0');
user_rd_data_4_8 <= (others => '0');
user_rd_data_5_8 <= (others => '0');
user_rd_data_6_8 <= (others => '0');
user_rd_data_7_8 <= (others => '0');
user_rd_data_8_8 <= (others => '0');
user_rd_data_9_8 <= (others => '0');
user_rd_data_10_8 <= (others => '0');
user_rd_data_11_8 <= (others => '0');
user_rd_data_12_8 <= (others => '0');
user_rd_data_13_8 <= (others => '0');
user_rd_data_14_8 <= (others => '0');
user_rd_data_15_8 <= (others => '0');
data_valid_i <= '0';
mpx_cmp <= "0000000";
elsif(rd_data_valid = '1') then
data_valid_i <= '1';
--if(first = '0') then
---------------------------------
case mpx_cmp is
when("0000000") =>
user_rd_data_0_0_i <= user_rd_data_rise;
user_rd_data_1_0_i <= user_rd_data_fall;
mpx_cmp <= "0000001";
when ("0000001") =>
user_rd_data_2_0_i <= user_rd_data_rise;
user_rd_data_3_0_i <= user_rd_data_fall;
mpx_cmp <= "0000010";
when("0000010") =>
user_rd_data_4_0_i <= user_rd_data_rise;
user_rd_data_5_0_i <= user_rd_data_fall;
mpx_cmp <= "0000011";
when("0000011") =>
user_rd_data_6_0_i <= user_rd_data_rise;
user_rd_data_7_0_i <= user_rd_data_fall;
mpx_cmp <= "0000100";
when("0000100") =>
user_rd_data_8_0_i <= user_rd_data_rise;
user_rd_data_9_0_i <= user_rd_data_fall;
mpx_cmp <= "0000101";
when("0000101") =>
user_rd_data_10_0_i <= user_rd_data_rise;
user_rd_data_11_0_i <= user_rd_data_fall;
mpx_cmp <= "0000110";
when("0000110") =>
user_rd_data_12_0_i <= user_rd_data_rise;
user_rd_data_13_0_i <= user_rd_data_fall;
mpx_cmp <= "0000111";
when("0000111") =>
user_rd_data_14_0_i <= user_rd_data_rise;
user_rd_data_15_0_i <= user_rd_data_fall;
mpx_cmp <= "0001000";
---------------------------------1
when("0001000") =>
user_rd_data_0_1_i <= user_rd_data_rise;
user_rd_data_1_1_i <= user_rd_data_fall;
mpx_cmp <= "0001001";
when("0001001") =>
user_rd_data_2_1_i <= user_rd_data_rise;
user_rd_data_3_1_i <= user_rd_data_fall;
mpx_cmp <= "0001010";
when("0001010") =>
user_rd_data_4_1_i <= user_rd_data_rise;
user_rd_data_5_1_i <= user_rd_data_fall;
mpx_cmp <= "0001011";
when("0001011") =>
user_rd_data_6_1_i <= user_rd_data_rise;
user_rd_data_7_1_i <= user_rd_data_fall;
mpx_cmp <= "0001100";
when("0001100") =>
user_rd_data_8_1_i <= user_rd_data_rise;
user_rd_data_9_1_i <= user_rd_data_fall;
mpx_cmp <= "0001101";
when("0001101") =>
user_rd_data_10_1_i <= user_rd_data_rise;
user_rd_data_11_1_i <= user_rd_data_fall;
mpx_cmp <= "0001110";
when("0001110") =>
user_rd_data_12_1_i <= user_rd_data_rise;
user_rd_data_13_1_i <= user_rd_data_fall;
mpx_cmp <= "0001111";
when("0001111") =>
user_rd_data_14_1_i <= user_rd_data_rise;
user_rd_data_15_1_i <= user_rd_data_fall;
mpx_cmp <= "0010000";
---------------------------------2
when("0010000") =>
user_rd_data_0_2_i <= user_rd_data_rise;
user_rd_data_1_2_i <= user_rd_data_fall;
mpx_cmp <= "0010001";
when("0010001") =>
user_rd_data_2_2_i <= user_rd_data_rise;
user_rd_data_3_2_i <= user_rd_data_fall;
mpx_cmp <= "0010010";
when("0010010") =>
user_rd_data_4_2_i <= user_rd_data_rise;
user_rd_data_5_2_i <= user_rd_data_fall;
mpx_cmp <= "0010011";
when("0010011") =>
user_rd_data_6_2_i <= user_rd_data_rise;
user_rd_data_7_2_i <= user_rd_data_fall;
mpx_cmp <= "0010100";
when("0010100") =>
user_rd_data_8_2_i <= user_rd_data_rise;
user_rd_data_9_2_i <= user_rd_data_fall;
mpx_cmp <= "0010101";
when("0010101") =>
user_rd_data_10_2_i <= user_rd_data_rise;
user_rd_data_11_2_i <= user_rd_data_fall;
mpx_cmp <= "0010110";
when("0010110") =>
user_rd_data_12_2_i <= user_rd_data_rise;
user_rd_data_13_2_i <= user_rd_data_fall;
mpx_cmp <= "0010111";
when("0010111") =>
user_rd_data_14_2_i <= user_rd_data_rise;
user_rd_data_15_2_i <= user_rd_data_fall;
mpx_cmp <= "0011111";
---------------------------------3
when("0011111") =>
user_rd_data_0_3_i <= user_rd_data_rise;
user_rd_data_1_3_i <= user_rd_data_fall;
mpx_cmp <= "0100000";
when("0100000") =>
user_rd_data_2_3_i <= user_rd_data_rise;
user_rd_data_3_3_i <= user_rd_data_fall;
mpx_cmp <= "0100001";
when("0100001") =>
user_rd_data_4_3_i <= user_rd_data_rise;
user_rd_data_5_3_i <= user_rd_data_fall;
mpx_cmp <= "0100010";
when("0100010") =>
user_rd_data_6_3_i <= user_rd_data_rise;
user_rd_data_7_3_i <= user_rd_data_fall;
mpx_cmp <= "0100011";
when("0100011") =>
user_rd_data_8_3_i <= user_rd_data_rise;
user_rd_data_9_3_i <= user_rd_data_fall;
mpx_cmp <= "0100100";
when("0100100") =>
user_rd_data_10_3_i <= user_rd_data_rise;
user_rd_data_11_3_i <= user_rd_data_fall;
mpx_cmp <= "0100101";
when("0100101") =>
user_rd_data_12_3_i <= user_rd_data_rise;
user_rd_data_13_3_i <= user_rd_data_fall;
mpx_cmp <= "0100110";
when("0100110") =>
user_rd_data_14_3_i <= user_rd_data_rise;
user_rd_data_15_3_i <= user_rd_data_fall;
mpx_cmp <= "0100111";
---------------------------------4
when("0100111") =>
user_rd_data_0_4_i <= user_rd_data_rise;
user_rd_data_1_4_i <= user_rd_data_fall;
mpx_cmp <= "0101000";
when("0101000") =>
user_rd_data_2_4_i <= user_rd_data_rise;
user_rd_data_3_4_i <= user_rd_data_fall;
mpx_cmp <= "0101001";
when("0101001") =>
user_rd_data_4_4_i <= user_rd_data_rise;
user_rd_data_5_4_i <= user_rd_data_fall;
mpx_cmp <= "0101010";
when("0101010") =>
user_rd_data_6_4_i <= user_rd_data_rise;
user_rd_data_7_4_i <= user_rd_data_fall;
mpx_cmp <= "0101011";
when("0101011") =>
user_rd_data_8_4_i <= user_rd_data_rise;
user_rd_data_9_4_i <= user_rd_data_fall;
mpx_cmp <= "0101100";
when("0101100") =>
user_rd_data_10_4_i <= user_rd_data_rise;
user_rd_data_11_4_i <= user_rd_data_fall;
mpx_cmp <= "0101101";
when("0101101") =>
user_rd_data_12_4_i <= user_rd_data_rise;
user_rd_data_13_4_i <= user_rd_data_fall;
mpx_cmp <= "0101110";
when("0101110") =>
user_rd_data_14_4_i <= user_rd_data_rise;
user_rd_data_15_4_i <= user_rd_data_fall;
mpx_cmp <= "0101111";
-------------------------------------------------------
when("0101111") =>
user_rd_data_0_5_i <= user_rd_data_rise;
user_rd_data_1_5_i <= user_rd_data_fall;
mpx_cmp <= "0110000";
when("0110000") =>
user_rd_data_2_5_i <= user_rd_data_rise;
user_rd_data_3_5_i <= user_rd_data_fall;
mpx_cmp <= "0110001";
when("0110001") =>
user_rd_data_4_5_i <= user_rd_data_rise;
user_rd_data_5_5_i <= user_rd_data_fall;
mpx_cmp <= "0110010";
when("0110010") =>
user_rd_data_6_5_i <= user_rd_data_rise;
user_rd_data_7_5_i <= user_rd_data_fall;
mpx_cmp <= "0110011";
when("0110011") =>
user_rd_data_8_5_i <= user_rd_data_rise;
user_rd_data_9_5_i <= user_rd_data_fall;
mpx_cmp <= "0110100";
when("0110100") =>
user_rd_data_10_5_i <= user_rd_data_rise;
user_rd_data_11_5_i <= user_rd_data_fall;
mpx_cmp <= "0110101";
when("0110101") =>
user_rd_data_12_5_i <= user_rd_data_rise;
user_rd_data_13_5_i <= user_rd_data_fall;
mpx_cmp <= "0110110";
when("0110110") =>
user_rd_data_14_5_i <= user_rd_data_rise;
user_rd_data_15_5_i <= user_rd_data_fall;
mpx_cmp <= "0110111";
--------------------------------------------------
when("0110111") =>
user_rd_data_0_6_i <= user_rd_data_rise;
user_rd_data_1_6_i <= user_rd_data_fall;
mpx_cmp <= "0111000";
when("0111000") =>
user_rd_data_2_6_i <= user_rd_data_rise;
user_rd_data_3_6_i <= user_rd_data_fall;
mpx_cmp <= "0111001";
when("0111001") =>
user_rd_data_4_6_i <= user_rd_data_rise;
user_rd_data_5_6_i <= user_rd_data_fall;
mpx_cmp <= "0111010";
when("0111010") =>
user_rd_data_6_6_i <= user_rd_data_rise;
user_rd_data_7_6_i <= user_rd_data_fall;
mpx_cmp <= "0111011";
when("0111011") =>
user_rd_data_8_6_i <= user_rd_data_rise;
user_rd_data_9_6_i <= user_rd_data_fall;
mpx_cmp <= "0111100";
when("0111100") =>
user_rd_data_10_6_i <= user_rd_data_rise;
user_rd_data_11_6_i <= user_rd_data_fall;
mpx_cmp <= "0111101";
when("0111101") =>
user_rd_data_12_6_i <= user_rd_data_rise;
user_rd_data_13_6_i <= user_rd_data_fall;
mpx_cmp <= "0111110";
when("0111110") =>
user_rd_data_14_6_i <= user_rd_data_rise;
user_rd_data_15_6_i <= user_rd_data_fall;
mpx_cmp <= "0111111";

when("0111111") =>
user_rd_data_0_7_i <= user_rd_data_rise;
user_rd_data_1_7_i <= user_rd_data_fall;
mpx_cmp <= "1000000";
when("1000000") =>
user_rd_data_2_7_i <= user_rd_data_rise;
user_rd_data_3_7_i <= user_rd_data_fall;
mpx_cmp <= "1000001";
when("1000001") =>
user_rd_data_4_7_i <= user_rd_data_rise;
user_rd_data_5_7_i <= user_rd_data_fall;
mpx_cmp <= "1000010";
when("1000010") =>
user_rd_data_6_7_i <= user_rd_data_rise;
user_rd_data_7_7_i <= user_rd_data_fall;
mpx_cmp <= "1000011";
when("1000011") =>
user_rd_data_8_7_i <= user_rd_data_rise;
user_rd_data_9_7_i <= user_rd_data_fall;
mpx_cmp <= "1000100";
when("1000100") =>
user_rd_data_10_7_i <= user_rd_data_rise;
user_rd_data_11_7_i <= user_rd_data_fall;
mpx_cmp <= "1000101";
when("1000101") =>
user_rd_data_12_7_i <= user_rd_data_rise;
user_rd_data_13_7_i <= user_rd_data_fall;
mpx_cmp <= "1000110";
when("1000110") =>
user_rd_data_14_7_i <= user_rd_data_rise;
user_rd_data_15_7_i <= user_rd_data_fall;
mpx_cmp <= "1000111";

when("1000111") =>
user_rd_data_0_8_i <= user_rd_data_rise;
user_rd_data_1_8_i <= user_rd_data_fall;
mpx_cmp <= "1001000";
when("1001000") =>
user_rd_data_2_8_i <= user_rd_data_rise;
user_rd_data_3_8_i <= user_rd_data_fall;
mpx_cmp <= "1001001";
when("1001001") =>
user_rd_data_4_8_i <= user_rd_data_rise;
user_rd_data_5_8_i <= user_rd_data_fall;
mpx_cmp <= "1001010";
when("1001010") =>
user_rd_data_6_8_i <= user_rd_data_rise;
user_rd_data_7_8_i <= user_rd_data_fall;
mpx_cmp <= "1001011";
when("1001011") =>
user_rd_data_8_8_i <= user_rd_data_rise;
user_rd_data_9_8_i <= user_rd_data_fall;
mpx_cmp <= "1001100";
when("1001100") =>
user_rd_data_10_8_i <= user_rd_data_rise;
user_rd_data_11_8_i <= user_rd_data_fall;
mpx_cmp <= "1001101";
when("1001101") =>
user_rd_data_12_8_i <= user_rd_data_rise;
user_rd_data_13_8_i <= user_rd_data_fall;
mpx_cmp <= "1010010";
when("1010010") =>
--user_rd_data_14_2_i <= user_rd_data_rise;
--user_rd_data_15_2_i <= user_rd_data_fall;
rdy_in := not rdy_in;
rdy <= rdy_in;

user_rd_data_0_0 <= user_rd_data_0_0_i;
user_rd_data_1_0 <= user_rd_data_1_0_i;
user_rd_data_2_0 <= user_rd_data_2_0_i;
user_rd_data_3_0 <= user_rd_data_3_0_i;
user_rd_data_4_0 <= user_rd_data_4_0_i;
user_rd_data_5_0 <= user_rd_data_5_0_i;
user_rd_data_6_0 <= user_rd_data_6_0_i;
user_rd_data_7_0 <= user_rd_data_7_0_i;
user_rd_data_8_0 <= user_rd_data_8_0_i;
user_rd_data_9_0 <= user_rd_data_9_0_i;
user_rd_data_10_0 <= user_rd_data_10_0_i;
user_rd_data_11_0 <= user_rd_data_11_0_i;
user_rd_data_12_0 <= user_rd_data_12_0_i;
user_rd_data_13_0 <= user_rd_data_13_0_i;
user_rd_data_14_0 <= user_rd_data_14_0_i;
user_rd_data_15_0 <= user_rd_data_15_0_i;

user_rd_data_0_1 <= user_rd_data_0_1_i;
user_rd_data_1_1 <= user_rd_data_1_1_i;
user_rd_data_2_1 <= user_rd_data_2_1_i;
user_rd_data_3_1 <= user_rd_data_3_1_i;
user_rd_data_4_1 <= user_rd_data_4_1_i;
user_rd_data_5_1 <= user_rd_data_5_1_i;
user_rd_data_6_1 <= user_rd_data_6_1_i;
user_rd_data_7_1 <= user_rd_data_7_1_i;
user_rd_data_8_1 <= user_rd_data_8_1_i;
user_rd_data_9_1 <= user_rd_data_9_1_i;
user_rd_data_10_1 <= user_rd_data_10_1_i;
user_rd_data_11_1 <= user_rd_data_11_1_i;
user_rd_data_12_1 <= user_rd_data_12_1_i;
user_rd_data_13_1 <= user_rd_data_13_1_i;
user_rd_data_14_1 <= user_rd_data_14_1_i;
user_rd_data_15_1 <= user_rd_data_15_1_i;

user_rd_data_0_2 <= user_rd_data_0_2_i;
user_rd_data_1_2 <= user_rd_data_1_2_i;
user_rd_data_2_2 <= user_rd_data_2_2_i;
user_rd_data_3_2 <= user_rd_data_3_2_i;
user_rd_data_4_2 <= user_rd_data_4_2_i;
user_rd_data_5_2 <= user_rd_data_5_2_i;
user_rd_data_6_2 <= user_rd_data_6_2_i;
user_rd_data_7_2 <= user_rd_data_7_2_i;
user_rd_data_8_2 <= user_rd_data_8_2_i;
user_rd_data_9_2 <= user_rd_data_9_2_i;
user_rd_data_10_2 <= user_rd_data_10_2_i;
user_rd_data_11_2 <= user_rd_data_11_2_i;
user_rd_data_12_2 <= user_rd_data_12_2_i;
user_rd_data_13_2 <= user_rd_data_13_2_i;
user_rd_data_14_2 <= user_rd_data_14_2_i;
user_rd_data_15_2 <= user_rd_data_15_2_i;

user_rd_data_0_3 <= user_rd_data_0_3_i;
user_rd_data_1_3 <= user_rd_data_1_3_i;
user_rd_data_2_3 <= user_rd_data_2_3_i;
user_rd_data_3_3 <= user_rd_data_3_3_i;
user_rd_data_4_3 <= user_rd_data_4_3_i;
user_rd_data_5_3 <= user_rd_data_5_3_i;
user_rd_data_6_3 <= user_rd_data_6_3_i;
user_rd_data_7_3 <= user_rd_data_7_3_i;
user_rd_data_8_3 <= user_rd_data_8_3_i;
user_rd_data_9_3 <= user_rd_data_9_3_i;
user_rd_data_10_3 <= user_rd_data_10_3_i;
user_rd_data_11_3 <= user_rd_data_11_3_i;
user_rd_data_12_3 <= user_rd_data_12_3_i;
user_rd_data_13_3 <= user_rd_data_13_3_i;
user_rd_data_14_3 <= user_rd_data_14_3_i;
user_rd_data_15_3 <= user_rd_data_15_3_i;

user_rd_data_0_4 <= user_rd_data_0_4_i;
user_rd_data_1_4 <= user_rd_data_1_4_i;
user_rd_data_2_4 <= user_rd_data_2_4_i;
user_rd_data_3_4 <= user_rd_data_3_4_i;
user_rd_data_4_4 <= user_rd_data_4_4_i;
user_rd_data_5_4 <= user_rd_data_5_4_i;
user_rd_data_6_4 <= user_rd_data_6_4_i;
user_rd_data_7_4 <= user_rd_data_7_4_i;
user_rd_data_8_4 <= user_rd_data_8_4_i;
user_rd_data_9_4 <= user_rd_data_9_4_i;
user_rd_data_10_4 <= user_rd_data_10_4_i;
user_rd_data_11_4 <= user_rd_data_11_4_i;
user_rd_data_12_4 <= user_rd_data_12_4_i;
user_rd_data_13_4 <= user_rd_data_13_4_i;
user_rd_data_14_4 <= user_rd_data_14_4_i;
user_rd_data_15_4 <= user_rd_data_15_4_i;

user_rd_data_0_5 <= user_rd_data_0_5_i;
user_rd_data_1_5 <= user_rd_data_1_5_i;
user_rd_data_2_5 <= user_rd_data_2_5_i;
user_rd_data_3_5 <= user_rd_data_3_5_i;
user_rd_data_4_5 <= user_rd_data_4_5_i;
user_rd_data_5_5 <= user_rd_data_5_5_i;
user_rd_data_6_5 <= user_rd_data_6_5_i;
user_rd_data_7_5 <= user_rd_data_7_5_i;
user_rd_data_8_5 <= user_rd_data_8_5_i;
user_rd_data_9_5 <= user_rd_data_9_5_i;
user_rd_data_10_5 <= user_rd_data_10_5_i;
user_rd_data_11_5 <= user_rd_data_11_5_i;
user_rd_data_12_5 <= user_rd_data_12_5_i;
user_rd_data_13_5 <= user_rd_data_13_5_i;
user_rd_data_14_5 <= user_rd_data_14_5_i;
user_rd_data_15_5 <= user_rd_data_15_5_i;

user_rd_data_0_6 <= user_rd_data_0_6_i;
user_rd_data_1_6 <= user_rd_data_1_6_i;
user_rd_data_2_6 <= user_rd_data_2_6_i;
user_rd_data_3_6 <= user_rd_data_3_6_i;
user_rd_data_4_6 <= user_rd_data_4_6_i;
user_rd_data_5_6 <= user_rd_data_5_6_i;
user_rd_data_6_6 <= user_rd_data_6_6_i;
user_rd_data_7_6 <= user_rd_data_7_6_i;
user_rd_data_8_6 <= user_rd_data_8_6_i;
user_rd_data_9_6 <= user_rd_data_9_6_i;
user_rd_data_10_6 <= user_rd_data_10_6_i;
user_rd_data_11_6 <= user_rd_data_11_6_i;
user_rd_data_12_6 <= user_rd_data_12_6_i;
user_rd_data_13_6 <= user_rd_data_13_6_i;
user_rd_data_14_6 <= user_rd_data_14_6_i;
user_rd_data_15_6 <= user_rd_data_15_6_i;

user_rd_data_0_7 <= user_rd_data_0_7_i;
user_rd_data_1_7 <= user_rd_data_1_7_i;
user_rd_data_2_7 <= user_rd_data_2_7_i;
user_rd_data_3_7 <= user_rd_data_3_7_i;
user_rd_data_4_7 <= user_rd_data_4_7_i;
user_rd_data_5_7 <= user_rd_data_5_7_i;
user_rd_data_6_7 <= user_rd_data_6_7_i;
user_rd_data_7_7 <= user_rd_data_7_7_i;
user_rd_data_8_7 <= user_rd_data_8_7_i;
user_rd_data_9_7 <= user_rd_data_9_7_i;
user_rd_data_10_7 <= user_rd_data_10_7_i;
user_rd_data_11_7 <= user_rd_data_11_7_i;
user_rd_data_12_7 <= user_rd_data_12_7_i;
user_rd_data_13_7 <= user_rd_data_13_7_i;
user_rd_data_14_7 <= user_rd_data_14_7_i;
user_rd_data_15_7 <= user_rd_data_15_7_i;

user_rd_data_0_8_l <= user_rd_data_0_8_i;
user_rd_data_1_8_l <= user_rd_data_1_8_i;
user_rd_data_2_8_l <= user_rd_data_2_8_i;
user_rd_data_3_8_l <= user_rd_data_3_8_i;
user_rd_data_4_8_l <= user_rd_data_4_8_i;
user_rd_data_5_8_l <= user_rd_data_5_8_i;
user_rd_data_6_8_l <= user_rd_data_6_8_i;
user_rd_data_7_8_l <= user_rd_data_7_8_i;
user_rd_data_8_8_l <= user_rd_data_8_8_i;
user_rd_data_9_8_l <= user_rd_data_9_8_i;
user_rd_data_10_8_l <= user_rd_data_10_8_i;
user_rd_data_11_8_l <= user_rd_data_11_8_i;
user_rd_data_12_8_l <= user_rd_data_12_8_i;
user_rd_data_13_8_l <= user_rd_data_13_8_i;
user_rd_data_14_8_l <= user_rd_data_rise;
user_rd_data_15_8_l <= user_rd_data_fall;


user_rd_data_0_8 <= user_rd_data_0_8_l;
user_rd_data_1_8 <= user_rd_data_1_8_l;
user_rd_data_2_8 <= user_rd_data_2_8_l;
user_rd_data_3_8 <= user_rd_data_3_8_l;
user_rd_data_4_8 <= user_rd_data_4_8_l;
user_rd_data_5_8 <= user_rd_data_5_8_l;
user_rd_data_6_8 <= user_rd_data_6_8_l;
user_rd_data_7_8 <= user_rd_data_7_8_l;
user_rd_data_8_8 <= user_rd_data_8_8_l;
user_rd_data_9_8 <= user_rd_data_9_8_l;
user_rd_data_10_8 <= user_rd_data_10_8_l;
user_rd_data_11_8 <= user_rd_data_11_8_l;
user_rd_data_12_8 <= user_rd_data_12_8_l;
user_rd_data_13_8 <= user_rd_data_13_8_l;
user_rd_data_14_8 <= user_rd_data_14_8_l;
user_rd_data_15_8 <= user_rd_data_15_8_l;
mpx_cmp <= "0000000";
when others => NULL;
end case;
end if;
end if;
end process;
;

Вот в этой части кода я данные по сигналу rd_data_valid с памяти последовательно записываю в регистры и параллельно выдаю по окончании.
Не могли бы вы подсказать насколько данный код не оптимален? И в чем? И как правильно организовать преобразование последоветельного потока данных в параллельный?

CODE

Timing constraint: PERIOD analysis for net "clk200x" derived from NET "clk100" PERIOD = 10 ns HIGH 50%; divided by 2.00 to 5 nS
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
191470397 paths analyzed, 17155 endpoints analyzed, 1066 failing endpoints
1066 timing errors detected. (1061 setup errors, 5 hold errors, 0 component switching limit errors)
Minimum period is 5.956ns.
--------------------------------------------------------------------------------

Paths for end point ddc/ddc/IMPCI/U2/U2/blk00000337 (SLICE_X64Y150.CIN), 1810530 paths
--------------------------------------------------------------------------------
Slack (setup path): -0.956ns (requirement - (data path - clock path skew + uncertainty))
Source: ddc/ddc/SW_IN_I/Label1/U15/outp_20 (FF)
Destination: ddc/ddc/IMPCI/U2/U2/blk00000337 (FF)
Requirement: 5.000ns
Data Path Delay: 5.833ns (Levels of Logic = 9)
Clock Path Skew: -0.051ns (0.893 - 0.944)
Source Clock: clk200 rising at 0.000ns
Destination Clock: clk200 rising at 5.000ns
Clock Uncertainty: 0.072ns

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

Maximum Data Path at Slow Process Corner: ddc/ddc/SW_IN_I/Label1/U15/outp_20 to ddc/ddc/IMPCI/U2/U2/blk00000337
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X67Y143.DQ Tcko 0.337 ddc/ddc/SW_IN_I/Label1/U15/outp<20>
ddc/ddc/SW_IN_I/Label1/U15/outp_20
SLICE_X60Y143.B2 net (fanout=34) 0.952 ddc/ddc/SW_IN_I/Label1/U15/outp<20>
SLICE_X60Y143.COUT Topcyb 0.406 ddc/ddc/IMPCI/U2/U2/sig0000030e
ddc/ddc/IMPCI/U2/U2/blk000003a5
ddc/ddc/IMPCI/U2/U2/blk000000fa
SLICE_X60Y144.CIN net (fanout=1) 0.000 ddc/ddc/IMPCI/U2/U2/sig0000030e
SLICE_X60Y144.DMUX Tcind 0.316 ddc/ddc/IMPCI/U2/U2/sig000002ee
ddc/ddc/IMPCI/U2/U2/blk000000da
SLICE_X59Y145.B3 net (fanout=2) 0.470 ddc/ddc/IMPCI/U2/U2/sig00000247
SLICE_X59Y145.COUT Topcyb 0.404 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_11_1_i<20>
ddc/ddc/IMPCI/U2/U2/blk000002f2
ddc/ddc/IMPCI/U2/U2/blk000002eb
SLICE_X59Y146.CIN net (fanout=1) 0.000 ddc/ddc/IMPCI/U2/U2/sig000000db
SLICE_X59Y146.CMUX Tcinc 0.243 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_2_1_i<25>
ddc/ddc/IMPCI/U2/U2/blk000002df
SLICE_X65Y147.A4 net (fanout=1) 0.914 ddc/ddc/IMPCI/U2/U2/sig0000018d
SLICE_X65Y147.COUT Topcya 0.409 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_10_1<8>
ddc/ddc/IMPCI/U2/U2/blk0000023e
ddc/ddc/IMPCI/U2/U2/blk00000234
SLICE_X65Y148.CIN net (fanout=1) 0.000 ddc/ddc/IMPCI/U2/U2/sig00000062
SLICE_X65Y148.DMUX Tcind 0.315 ddc/ddc/u_ddrii_tb_top_0/Label1/user_rd_data_0_1_i<2>
ddc/ddc/IMPCI/U2/U2/blk00000228
SLICE_X64Y148.D4 net (fanout=2) 0.530 ddc/ddc/IMPCI/U2/U2/sig0000015f
SLICE_X64Y148.COUT Topcyd 0.319 ddc/ddc/IMPCI/U2/BUS47<23>
ddc/ddc/IMPCI/U2/U2/blk000001bc
ddc/ddc/IMPCI/U2/U2/blk000001bb
SLICE_X64Y149.CIN net (fanout=1) 0.000 ddc/ddc/IMPCI/U2/U2/sig00000012
SLICE_X64Y149.COUT Tbyp 0.078 ddc/ddc/IMPCI/U2/BUS47<27>
ddc/ddc/IMPCI/U2/U2/blk000001af
SLICE_X64Y150.CIN net (fanout=1) 0.000 ddc/ddc/IMPCI/U2/U2/sig0000000a
SLICE_X64Y150.CLK Tcinck 0.140 ddc/ddc/IMPCI/U2/BUS47<31>
ddc/ddc/IMPCI/U2/U2/blk000001a3
ddc/ddc/IMPCI/U2/U2/blk00000337
------------------------------------------------- ---------------------------
Total 5.833ns (2.967ns logic, 2.866ns route)
(50.9% logic, 49.1% route)

CODE

Paths for end point ddc/ddc/IMPCI/U9/blk00000003 (DSP48_X4Y39.PCIN0), 17 paths
--------------------------------------------------------------------------------
Slack (setup path): -0.938ns (requirement - (data path - clock path skew + uncertainty))
Source: ddc/ddc/IMPCI/U8/median_5 (FF)
Destination: ddc/ddc/IMPCI/U9/blk00000003 (DSP)
Requirement: 5.000ns
Data Path Delay: 5.874ns (Levels of Logic = 1)(Component delays alone exceeds constraint)
Clock Path Skew: 0.008ns (0.904 - 0.896)
Source Clock: clk200 rising at 0.000ns
Destination Clock: clk200 rising at 5.000ns
Clock Uncertainty: 0.072ns

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

Maximum Data Path at Slow Process Corner: ddc/ddc/IMPCI/U8/median_5 to ddc/ddc/IMPCI/U9/blk00000003
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X81Y96.BMUX Tshcko 0.420 ddc/ddc/IMPCI/U8/median<11>
ddc/ddc/IMPCI/U8/median_5
DSP48_X4Y38.B5 net (fanout=1) 0.423 ddc/ddc/IMPCI/U8/median<5>
DSP48_X4Y38.PCOUT0 Tdspdo_B_PCOUT_MULT 3.691 ddc/ddc/IMPCI/U9/blk00000004
ddc/ddc/IMPCI/U9/blk00000004
DSP48_X4Y39.PCIN0 net (fanout=1) 0.002 ddc/ddc/IMPCI/U9/sig00000003
DSP48_X4Y39.CLK Tdspdck_PCIN_PREG 1.338 ddc/ddc/IMPCI/U9/blk00000003
ddc/ddc/IMPCI/U9/blk00000003
------------------------------------------------- ---------------------------
Total 5.874ns (5.449ns logic, 0.425ns route)
(92.8% logic, 7.2% route)

У меня в схеме есть две разных корки умножителя на DSP48 с оптимальным pipeline. У меня получается такая закономерность, что при синтезе пути к этим умножителям страдают от временных ошибок. Из за чего такое может быть?

Сообщение отредактировал bognev - Jan 31 2014, 04:52

[Timmy]

Я бы посоветовал для начала разместить user_rd_data в двумерном массиве, и сократить код раз в 20(если вам, конечно, не платят за массовую копипасту) с помощью циклов, причём case тоже можно легко запихнуть в цикл for if, или использовать индексацию(тут надо повнимательнее разобраться).

[Джеймс]

Стал дальше реализовывать проект и столкнулся с новыми временными ошибками.

Не могли бы вы подсказать насколько данный код не оптимален? И в чем? И как правильно организовать преобразование последоветельного потока данных в параллельный?

Замените мультиплексор на регистр сдвига. Так вы по крайней мере избавитесь от огромного разветвления user_rd_data_rise, user_rd_data_fall.
Имею в виду вот это:

Код

        when("1001010") =>
                    user_rd_data_6_8_i <= user_rd_data_rise;
                    user_rd_data_7_8_i <= user_rd_data_fall;
                    mpx_cmp <= "1001011";                   
                when("1001011") =>
                    user_rd_data_8_8_i <= user_rd_data_rise;
                    user_rd_data_9_8_i <= user_rd_data_fall;

P.S. Старайтесь везде указывать разрядность.. Полезная привычка.

[bognev]

Замените мультиплексор на регистр сдвига. Так вы по крайней мере избавитесь от огромного разветвления user_rd_data_rise, user_rd_data_fall.
Имею в виду вот это:

Код

        when("1001010") =>
                    user_rd_data_6_8_i <= user_rd_data_rise;
                    user_rd_data_7_8_i <= user_rd_data_fall;
                    mpx_cmp <= "1001011";                   
                when("1001011") =>
                    user_rd_data_8_8_i <= user_rd_data_rise;
                    user_rd_data_9_8_i <= user_rd_data_fall;

P.S. Старайтесь везде указывать разрядность.. Полезная привычка.

Разрядность шин 36 бит.

Я заменил мультиплексор на сдвиговые регистры, но проблема с временными ошибками не решена.

У меня такой глобальный вопрос.
Есь 16 канальный DDC, его данные я записываю с помощью контроллера в память с частотой 200 Мгц. Частота дискретизации данных на выходе DDC 2МГц. Я записываю данные в SDRAm и считываю их.
В этой части проблем с временными ошибками нет.
После принятия порции отсчетов, считанных с памяти, я хочу их обработать в алгоритме подавления несинхронных помех на той же частоте 200 МГц. Но эта частота излишняя, хватает 32 МГц для обработки 1 подавителем отсчетов со всех 16 каналов. И на этой частоте в дизайне появляются временные ошибки.
Как правильно принять эти даннные и обработать? То есть дело не в алгоритме, а в том как правильно обработать данные, принятые на частоте 200 МГц, например, на частоте 100 Мгц, как правильно сделать переход?