| |
|
  |
 Ошибки при работе схемы на ПЛИС, Прошу помощи. Временный задержки |
|
|
|
|
 Jan 23 2014, 08:38
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(gibson1980 @ Jan 23 2014, 12:30)  В корках умножителей речь идет вроде о LUTах, посмотри еще вот этот пример, вот там точно умножение будет на DSP...
вообще что за ПЛИС используется? ПЛИС - virtex 6. В корке умножителей есть выбор:
|
|
|
|
|
|
|
|
Jan 23 2014, 08:41
|
Гуру
Группа: Модераторы
Сообщений: 4 011
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369
|
Цитата(bognev @ Jan 22 2014, 14:36) . Решение проблемы нашел в последовательной обработке на более высокой частоте. На самом деле, есть еще один вариант. Не последовательно на более высокой частоте, а многопоточно, но тоже на более высокой частоте... Т.е. есть вычислитель и есть память. Из памяти извлекаются данные для N-го потока, выполняется операция и данные опять отправляются в память... При этом конвейером извлекаются данные для другого потока... Для Ваших 16-ти потоков потребуется память шириной "сколько надо" х 16... Под шириной я понимаю все или часть битов, которые извлекаются для обработки...
--------------------
www.iosifk.narod.ru
|
|
|
|
|
|
|
|
Jan 23 2014, 09:10
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(iosifk @ Jan 23 2014, 12:41) На самом деле, есть еще один вариант.
Не последовательно на более высокой частоте, а многопоточно, но тоже на более высокой частоте...
Т.е. есть вычислитель и есть память. Из памяти извлекаются данные для 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, каким образом уменьшить эту задержку?
|
|
|
|
|
|
|
|
Jan 23 2014, 10:14
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(bogaev_roman @ Jan 23 2014, 13:54) По поводу поста 9 - большое кол-во логических уровней - 10 и все они прилично размазаны, т.е. находятся на большом расстоянии друг от друга отчего задержка на путях - 73,4%. Эту задержку можно уменьшить, но общую от 12.249ns свести до 2.702ns Вы не сможете - меняйте алгоритм. В 9 посту алгоритмом является корка умножителя, разве она не должна быть сделана оптимальным образом? Цитата(bogaev_roman @ Jan 23 2014, 13:54) По поводу последнего поста все интересней - там переход из одного клокового домена в другой. У Вас там первый триггер тактируется частотой 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
|
|
|
|
|
|
|
|
Jan 23 2014, 10:50
|
Профессионал
Группа: Свой
Сообщений: 1 088
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082
|
Цитата(bognev @ Jan 23 2014, 14:14) В 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.
|
|
|
|
|
|
|
|
Jan 23 2014, 11:16
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(bogaev_roman @ Jan 23 2014, 14:50) Корка умножителя сколько на сколько? Какие цифры дает документация по максимальной частоте на такие умножители? И к этой цифре еще нужно прибавить 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 Цитата(bogaev_roman @ Jan 23 2014, 14:50) Корка умножителя сколько на сколько? Какие цифры дает документация по максимальной частоте на такие умножители? И к этой цифре еще нужно прибавить 5,320 ns, которые у Вас набегают до входа умножителя (посмотрите на координаты) 16 бит на 16 бит, по датащиту максимальная частота 450 МГц. А работает на 160 МГц. С запасом даже. Цитата(bogaev_roman @ Jan 23 2014, 14:50) Эти данные торчат на выходе корки (конкретно на регистрах) и вы их считываете на пониженной частоте, я правильно понял? Так и есть торчат на 200 МГц, считываю на 100 МГц по сигналу готовности. Цитата(bogaev_roman @ Jan 23 2014, 14:50) Просто 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
|
|
|
|
|
|
|
|
Jan 23 2014, 22:26
|
Местный
Группа: Участник
Сообщений: 230
Регистрация: 29-08-09
Пользователь №: 52 094
|
Цитата(bognev @ Jan 23 2014, 15:16) 16 бит на 16 бит, по датащиту максимальная частота 450 МГц. А работает на 160 МГц. С запасом даже. А мелкие букафки в даташите читали? Про то, в каком конкретно режиме работы умножителя получаются эти 450Mhz. Или просто посмотрели максимальную цифру и обрадовались?  Кроме того, весь этот Ваш "запас" в 4ns плавно растворяется в задержке пробегания перед умножителем, которая составляет 5,2ns.
Сообщение отредактировал o_khavin - Jan 23 2014, 22:26
|
|
|
|
|
|
|
|
Jan 24 2014, 06:34
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(Maverick @ Jan 24 2014, 00:15) проект синхронный? асинхронщины нет?
переходы из разных клоковых доменов организованы правильно? например, фифо Вы применяете? как передаете сигналы готовности схемы из разных клоковых доменов?
про счетчик, который не правильно считает: какой он разрядности? на какой частоте работает?
Вы просто собирали проект в схематехнике генерируя нужные элементы, правильно? какие-то элементы Вы сами делали?
PS В общем здесь нужно смотреть Вашу схематехнику или описание схемы....
PS PS для начала возможно не помешает какая-то блок-схема... асинхронщины нет. переходы из разных клоковых доменов скорее всего сделаны не правильно, фифо я не применяю, сигналы готовности перетактирую под нужнуй клок. счетчик работал на 100, 160, 200 Мгцах в xilinx ise блоки фильтров, умножителей я генерил в coregen, остальные части схемы сам собирал. Цитата(o_khavin @ Jan 24 2014, 02:26) А мелкие букафки в даташите читали? Про то, в каком конкретно режиме работы умножителя получаются эти 450Mhz. Или просто посмотрели максимальную цифру и обрадовались? Кроме того, весь этот Ваш "запас" в 4ns плавно растворяется в задержке пробегания перед умножителем, которая составляет 5,2ns. Я нашел в чем причина такой временной задержки, она не в самой корке, а в блоке округления и сдвига после, которые я сам и нагородил. Убрал их, скорее всего ошибки в этой части схемы уйдут.
|
|
|
|
|
|
|
|
Jan 24 2014, 07:08
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(bognev @ Jan 24 2014, 08:34) переходы из разных клоковых доменов скорее всего сделаны не правильно, фифо я не применяю, сигналы готовности перетактирую под нужнуй клок.
счетчик работал на 100, 160, 200 Мгцах рекомендую сделать (по ссылке части 11, 12)
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Jan 24 2014, 20:18
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(Maverick @ Jan 24 2014, 11:08) рекомендую сделать (по ссылке части 11, 12) Спасибо! Временные ошибки удалось свести с 50 с лишним тысяч до 33. Сейчас основные ошибки в модуле работы с памятью.
|
|
|
|
|
|
|
|
Jan 25 2014, 07:22
|
Участник
Группа: Участник
Сообщений: 58
Регистрация: 4-06-11
Пользователь №: 65 475
|
Цитата(Bad0512 @ Jan 25 2014, 10:45) Проверьте что память использует встроенные в примитив регистры, иначе тайминги будет очень сложно свести в ноль. RКаким образом можно это проверить? Посмотреть как это развелось в плис? Или в коде?
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
