Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.
Нажмите для просмотра прикрепленного файла
Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
Нажмите для просмотра прикрепленного файла
Полная версия этой страницы: Проблема приема данных Spartan-6 от АЦП
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
А вы входные триггеры в "лапы" поместили?
Цитата(maxics @ Nov 26 2013, 16:39) 
Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.
Нажмите для просмотра прикрепленного файла
Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
Нажмите для просмотра прикрепленного файла
Да уж. Во-первых, смотрите xapp645. Принимать надо входными serdes, инвертировать после триггера или serdes. Если разводка и правильная, то можно и dcm фазу двигать, а по идее надо через iodelay на каждом выводе. У этого ацп есть тестовый режим, по нему легко фазу подстроить динамически. У меня s6 принимает в режиме 2-х линий, частота выборки 800 мгц, запас по фазе где-то 8 делений iodelay, и даже при идеально выровненных парах оптимальная фаза отличается до 2-х делений.
Цитата(TRILLER @ Nov 26 2013, 16:59)
А вы входные триггеры в "лапы" поместили?
Что есть "лапы"?
Цитата(maxics @ Nov 26 2013, 16:21)
Что есть "лапы"?
лапы = пины = ножки = выводы ПЛИС
IO логика имеется ввиду для каждого вывода ПЛИС
Цитата(Maverick @ Nov 26 2013, 17:33)
лапы = пины = ножки = выводы ПЛИС
IO логика имеется ввиду для каждого вывода ПЛИС
IO логика имеется ввиду для каждого вывода ПЛИС
надо засадить входной регистр в ноги плиса. к регистру примени атрибут IOB = "true"
Цитата(maxics @ Nov 26 2013, 20:39)
Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.
Нажмите для просмотра прикрепленного файла
Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
Нажмите для просмотра прикрепленного файла
1. Пропишите в UCF файле OFFSET constraint, описывающий вашу ситуацию. Примеры есть в Constraints guide.
2. Вместо того АДа, что у вас в коде используйте примитивы IDDR для работы с LVDS сигналом по двум фронтам. В итоге сигнал будет проходить вот так : IBUFGDS -> IDDR -> ваша дальнейшая логика демультиплексирования.
3. На таких частотах в принципе можно и без DCM обойтись если грамотно использовать рекмендации Xilinx по source synchronous clocking, тут выбор за вами.
4. В вашем модуле данные идут с 2-х АЦП, а DCO - всего один, почему?
Цитата(maxics @ Nov 26 2013, 18:21)
Что есть "лапы"?
IO timing из даташита гарантируется только для случая, когда входные/выходные регистры располагаются в IO-cell. Это достигается атрибутом IOB=true на соответствующих регистрах проекта. При этом между регистром и пином никакой дополнительной логики быть не должно.
Сделал все как было написано выше. Такт пускаю через BUFIO2 и затем на PLL, где делаю такт для IDDR.
Нажмите для просмотра прикрепленного файла
Стабильности не прибавилось.
Не выполняются тайминги для констрейнтов описанных в UCF:
В чем может быть причина ошибок?
Нажмите для просмотра прикрепленного файла
Стабильности не прибавилось.
Не выполняются тайминги для констрейнтов описанных в UCF:
Код
NET "out2a_p" LOC = L3;
NET "out2a_n" LOC = L1;
NET "FR_p" LOC = K2;
NET "FR_n" LOC = K1;
NET "DCO_p" LOC = J3;
NET "DCO_n" LOC = J1;
NET "reset" LOC = D13;
INST "x_ADC2195_receiver/ibuf_2a" IOB =TRUE;
INST "x_ADC2195_receiver/IBUFGDS_inst2" IOB =TRUE;
#INST "x_ADC2195_receiver/ibuf_FR" IOB =TRUE;
INST "x_ADC2195_receiver/IDDR2_inst_a" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_b" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_c" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_d" IOB =TRUE;
#
NET "DCO_p" TNM_NET = "DCO_p";
TIMESPEC TS_DCO_p = PERIOD "DCO_p" 5 ns HIGH 50 %;
#NET "x_ADC2195_receiver/DCO" TNM_NET = DCO;
NET "x_ADC2195_receiver/CLK0" TNM_NET = CLK0_GRP;
NET "x_ADC2195_receiver/CLK180" TNM_NET = CLK180_GRP;
NET "out2a*" TNM = "out2a";
TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "DCO_p" TIMEGRP "CLK0_GRP";
TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "DCO_p" TIMEGRP "CLK180_GRP";
NET "Data_SV_out_I[0]" LOC = b20;
NET "Data_SV_out_I[1]" LOC = b21;
NET "Data_SV_out_I[2]" LOC = b22;
NET "Data_SV_out_I[3]" LOC = d20;
NET "Data_SV_out_I[4]" LOC = d21;
NET "Data_SV_out_I[5]" LOC = d22;
NET "Data_SV_out_I[6]" LOC = c20;
NET "Data_SV_out_I[7]" LOC = c22;
NET "Data_SV_out_I[8]" LOC = f20;
NET "Data_SV_out_I[9]" LOC = h19;
NET "Data_SV_out_I[10]" LOC = h18;
NET "Data_SV_out_I[11]" LOC = e20;
NET "Data_SV_out_I[12]" LOC = e22;
NET "Data_SV_out_I[13]" LOC = f21;
NET "Data_SV_out_I[14]" LOC = f22;
NET "Data_SV_out_I[15]" LOC = h20;
NET "test[0]" LOC = k16;
NET "test[1]" LOC = j16;
NET "test[2]" LOC = h16;
NET "test[3]" LOC = h17;
////////////////////////////////////////////////////
Timing constraint: TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE COMP "DCO_p" TIMEGRP CLK0_GRP;
For more information, see Offset In Analysis in the Timing Closure User Guide (UG612).
2 paths analyzed, 1 endpoint analyzed, 1 failing endpoint
1 timing error detected. (1 setup error, 0 hold errors)
Minimum allowable offset is 2.404ns.
--------------------------------------------------------------------------------
Paths for end point x_ADC2195_receiver/IDDR2_inst_a (ILOGIC_X0Y83.D), 2 paths
--------------------------------------------------------------------------------
Slack (setup path): -1.154 ns (requirement - (data path - clock path - clock arrival + uncertainty))
Source: out2a_n (PAD)
Destination: x_ADC2195_receiver/IDDR2_inst_a (FF)
Destination Clock: x_ADC2195_receiver/clk0 rising at 1.111ns
Requirement: 1.250ns
Data Path Delay: 2.975ns (Levels of Logic = 3)(Component delays alone exceeds constraint)
Clock Path Delay: -0.236ns (Levels of Logic = 4)
Clock Uncertainty: 0.304ns
Clock Uncertainty: 0.304ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.050ns
Discrete Jitter (DJ): 0.132ns
Phase Error (PE): 0.233ns
NET "out2a_n" LOC = L1;
NET "FR_p" LOC = K2;
NET "FR_n" LOC = K1;
NET "DCO_p" LOC = J3;
NET "DCO_n" LOC = J1;
NET "reset" LOC = D13;
INST "x_ADC2195_receiver/ibuf_2a" IOB =TRUE;
INST "x_ADC2195_receiver/IBUFGDS_inst2" IOB =TRUE;
#INST "x_ADC2195_receiver/ibuf_FR" IOB =TRUE;
INST "x_ADC2195_receiver/IDDR2_inst_a" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_b" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_c" IOB =TRUE;
#INST "x_ADC2195_receiver/IDDR2_inst_d" IOB =TRUE;
#
NET "DCO_p" TNM_NET = "DCO_p";
TIMESPEC TS_DCO_p = PERIOD "DCO_p" 5 ns HIGH 50 %;
#NET "x_ADC2195_receiver/DCO" TNM_NET = DCO;
NET "x_ADC2195_receiver/CLK0" TNM_NET = CLK0_GRP;
NET "x_ADC2195_receiver/CLK180" TNM_NET = CLK180_GRP;
NET "out2a*" TNM = "out2a";
TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "DCO_p" TIMEGRP "CLK0_GRP";
TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "DCO_p" TIMEGRP "CLK180_GRP";
NET "Data_SV_out_I[0]" LOC = b20;
NET "Data_SV_out_I[1]" LOC = b21;
NET "Data_SV_out_I[2]" LOC = b22;
NET "Data_SV_out_I[3]" LOC = d20;
NET "Data_SV_out_I[4]" LOC = d21;
NET "Data_SV_out_I[5]" LOC = d22;
NET "Data_SV_out_I[6]" LOC = c20;
NET "Data_SV_out_I[7]" LOC = c22;
NET "Data_SV_out_I[8]" LOC = f20;
NET "Data_SV_out_I[9]" LOC = h19;
NET "Data_SV_out_I[10]" LOC = h18;
NET "Data_SV_out_I[11]" LOC = e20;
NET "Data_SV_out_I[12]" LOC = e22;
NET "Data_SV_out_I[13]" LOC = f21;
NET "Data_SV_out_I[14]" LOC = f22;
NET "Data_SV_out_I[15]" LOC = h20;
NET "test[0]" LOC = k16;
NET "test[1]" LOC = j16;
NET "test[2]" LOC = h16;
NET "test[3]" LOC = h17;
////////////////////////////////////////////////////
Timing constraint: TIMEGRP "out2a" OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE COMP "DCO_p" TIMEGRP CLK0_GRP;
For more information, see Offset In Analysis in the Timing Closure User Guide (UG612).
2 paths analyzed, 1 endpoint analyzed, 1 failing endpoint
1 timing error detected. (1 setup error, 0 hold errors)
Minimum allowable offset is 2.404ns.
--------------------------------------------------------------------------------
Paths for end point x_ADC2195_receiver/IDDR2_inst_a (ILOGIC_X0Y83.D), 2 paths
--------------------------------------------------------------------------------
Slack (setup path): -1.154 ns (requirement - (data path - clock path - clock arrival + uncertainty))
Source: out2a_n (PAD)
Destination: x_ADC2195_receiver/IDDR2_inst_a (FF)
Destination Clock: x_ADC2195_receiver/clk0 rising at 1.111ns
Requirement: 1.250ns
Data Path Delay: 2.975ns (Levels of Logic = 3)(Component delays alone exceeds constraint)
Clock Path Delay: -0.236ns (Levels of Logic = 4)
Clock Uncertainty: 0.304ns
Clock Uncertainty: 0.304ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.050ns
Discrete Jitter (DJ): 0.132ns
Phase Error (PE): 0.233ns
В чем может быть причина ошибок?
Судя по этим строкам в отчете -
Цитата
Data Path Delay: 2.975ns (Levels of Logic = 3)(Component delays alone exceeds constraint)
Clock Path Delay: -0.236ns (Levels of Logic = 4)
у вас между IDDR2 и его данными (да и клоком тоже) по 3-4 уровня логики, а их вообще быть не должно.
Clock Path Delay: -0.236ns (Levels of Logic = 4)
Цитата(maxics @ Dec 6 2013, 10:33)
Сделал все как было написано выше. Такт пускаю через BUFIO2 и затем на PLL, где делаю такт для IDDR.
Стабильности не прибавилось.
Не выполняются тайминги для констрейнтов описанных в UCF:
В чем может быть причина ошибок?
Стабильности не прибавилось.
Не выполняются тайминги для констрейнтов описанных в UCF:
В чем может быть причина ошибок?
Почитайте в документации Xilinx-а про source synchronous IO vs system synchronous IO. IMHO, у Вас проблема в неправильном выборе типа.
Цитата(XVR @ Dec 6 2013, 13:48)
Судя по этим строкам в отчете -
у вас между IDDR2 и его данными (да и клоком тоже) по 3-4 уровня логики, а их вообще быть не должно.
у вас между IDDR2 и его данными (да и клоком тоже) по 3-4 уровня логики, а их вообще быть не должно.
А на схему Вы смотрели? Эти уровни логики - просто количество компонентов по дороге. Например, для клокового пути: ibufgds, bufio2, pll, bufg.
Цитата(o_khavin @ Dec 8 2013, 12:43)
А на схему Вы смотрели?
Смотрел, и на отчет тоже смотрелЦитата
Эти уровни логики - просто количество компонентов по дороге. Например, для клокового пути: ibufgds, bufio2, pll, bufg.
Буфера не входят в уровни логики. Уровни логики - это количество LUT'ов на пути сигнала. Буфера в LUT'ы не заходят.Посмотрите в Technology View как у вас на самом деле подключились сигналы
Цитата(XVR @ Dec 8 2013, 18:00)
Смотрел, и на отчет тоже смотрел
Буфера не входят в уровни логики. Уровни логики - это количество LUT'ов на пути сигнала. Буфера в LUT'ы не заходят.
Посмотрите в Technology View как у вас на самом деле подключились сигналы
Буфера не входят в уровни логики. Уровни логики - это количество LUT'ов на пути сигнала. Буфера в LUT'ы не заходят.
Посмотрите в Technology View как у вас на самом деле подключились сигналы
Во первых, это не мой дизайн. Во вторых, я ни разу не видел, чтобы схематик с явно нарисованными примитивами и соединениями между ними, самопроизвольно пополнялся LUT-ми. В третьих, покажите мне пример дизайна с 4-мя уровнями LUT-ов на клоковом пути (если следовать Вашей логике при чтении отчёта), и без трёхэтажных матюков в логе роутера.
Цитата(o_khavin @ Dec 8 2013, 19:20)
Во первых, это не мой дизайн.
Пардон, это был совет для ТСЦитата
Во вторых, я ни разу не видел, чтобы схематик с явно нарисованными примитивами и соединениями между ними, самопроизвольно пополнялся LUT-ми.
Я тоже, но отчет синтезатора говорит явно и не двусмысленно, что логика там есть. Я подозреваю, что схематик не соотвествует действительности (или ругань относится к другому элементу схемы)Цитата
В третьих, покажите мне пример дизайна с 4-мя уровнями LUT-ов на клоковом пути (если следовать Вашей логике при чтении отчёта), и без трёхэтажных матюков в логе роутера.
ТС не показал нам лога роутера - возможно они там и были 
Пока ТС не покажет нам, как на самом деле развелась схема, о чем то спорить бессмысленно
Извините, со спартанами не работал, но.. каким образом обеспечивается офсет из уцфника? Чего-то я там иоделэев не увидел. Вот, наверное, протягиванием сингала через логику и обеспечивается офсет. Конечно, возможно и путаю чего..
Цитата(XVR @ Dec 9 2013, 13:44)
Пока ТС не покажет нам, как на самом деле развелась схема, о чем то спорить бессмысленно
Ок, подождём.
Цитата(TRILLER @ Dec 9 2013, 14:19)
каким образом обеспечивается офсет из уцфника?
Строго говоря, офсет должен контролироваться, а вот его обеспечение нигде не обещается.
Между IDDR2 и данными никакой доп. логики нет. Это видно из схемы. Проблему решил, убрав BUFG для clk0 и clk180 между PLL и IDDR2, т.е такт завожу напрямую от PLL. После этого констрейнты стали выполняться.
Хм.. А в обратной связи, значит, оставили? Может просто компенсация неправильно в ДЦМе настроена?
Здравствуйте.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.
Нашел документ xapp1071_v6_adc_dac_lvds.pdf
там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)
А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?
Спасибо.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.
Нашел документ xapp1071_v6_adc_dac_lvds.pdf
там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)
А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?
Спасибо.
Цитата(Mityan @ Dec 20 2013, 20:01)
Здравствуйте.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.
Нашел документ xapp1071_v6_adc_dac_lvds.pdf
там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)
А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?
Спасибо.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.
Нашел документ xapp1071_v6_adc_dac_lvds.pdf
там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)
А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?
Спасибо.
Это немного другие 300МГц. Дело в том, что макросу IODELAY для работы ещё необходим блок упарвления IODELAY_CTRL, которому как раз для успешной работы нужны независимые клоки в районе 200МГц.
Ну а цифра 300 - это похоже верхний предел для этих клоков.
Цитата(Bad0512 @ Dec 22 2013, 07:01)
Это немного другие 300МГц. Дело в том, что макросу IODELAY для работы ещё необходим блок упарвления IODELAY_CTRL, которому как раз для успешной работы нужны независимые клоки в районе 200МГц.
Ну а цифра 300 - это похоже верхний предел для этих клоков.
Ну а цифра 300 - это похоже верхний предел для этих клоков.
То есть правильно ли я понимаю, что внутри IODELAY линия задержки с 32 отводами обеспечивает задержку входного сигнала от 1/64 до 1/2 периода опорной тактовой частоты?
Если я не могу завести на тактовый вход 448 непосредственно, как примере, то можно, разделив ее на 2 (в BUFR), завести 224 МГц и получить 32 отвода ЛЗ уже не на полпериода, а на целый период интересующей частоты 448 (от 1/32 до 1)?
Цитата(Mityan @ Dec 23 2013, 01:31)
То есть правильно ли я понимаю, что внутри IODELAY линия задержки с 32 отводами обеспечивает задержку входного сигнала от 1/64 до 1/2 периода опорной тактовой частоты?
Если я не могу завести на тактовый вход 448 непосредственно, как примере, то можно, разделив ее на 2 (в BUFR), завести 224 МГц и получить 32 отвода ЛЗ уже не на полпериода, а на целый период интересующей частоты 448 (от 1/32 до 1)?
Если я не могу завести на тактовый вход 448 непосредственно, как примере, то можно, разделив ее на 2 (в BUFR), завести 224 МГц и получить 32 отвода ЛЗ уже не на полпериода, а на целый период интересующей частоты 448 (от 1/32 до 1)?
Не совсем правильно. Задержка , насколько я понял, фиксированная, то есть не зависит от частоты никак. Частота 200МГц нужна для каких-то внутренних дел (калибровок или чего-то ещё).
Почему вы не можете завести 448МГц напрямую в ПЛИС? Какую ПЛИС использовать планируете?
И какая АЦП у вас? Дело в том, что частота на DCO как правило в 2 раза ниже частоты сэмплирования, так как данные передаются по обоим фронтам (DDR).
Цитата(Bad0512 @ Dec 23 2013, 06:51)
Не совсем правильно. Задержка , насколько я понял, фиксированная, то есть не зависит от частоты никак. Частота 200МГц нужна для каких-то внутренних дел (калибровок или чего-то ещё).
Почему вы не можете завести 448МГц напрямую в ПЛИС? Какую ПЛИС использовать планируете?
И какая АЦП у вас? Дело в том, что частота на DCO как правило в 2 раза ниже частоты сэмплирования, так как данные передаются по обоим фронтам (DDR).
Почему вы не можете завести 448МГц напрямую в ПЛИС? Какую ПЛИС использовать планируете?
И какая АЦП у вас? Дело в том, что частота на DCO как правило в 2 раза ниже частоты сэмплирования, так как данные передаются по обоим фронтам (DDR).
ПЛИС XC6VLX240T-1FFG1156.
Если я правильно понял, то эта схема на IODELAY нужна для компенсации доп. задержки, которую вносит BUFR. Конечно, поскольку временные диаграммы сигналов на выходе АЦП (а значит и на входе ПЛИС) как раз такие, как нужно, было бы идеально их завести через одинаковые буферы IBUFDS. Но поскольку DCO используется для тактирования преобразователя последовательных данных в параллельные, он должен быть подан в цепи тактирования (region clock) на специальные входы (clock capable). Через буфер. И вот тут-то временные соотношения и поплывут при высоких входных частотах. Верно? Или я чего-то недопонял?
В документе харр1071 (см. картинку выше) изображена именно обратная связь - выходной тактовый сигнал с BUFR заводится в блок IODELAY1 на опорный вход С. И задержка блока выражается именно в долях данного тактового (ниже привожу картинку из документа v6_DC_and_Switching_Characteristics).
Или мне нужно некий сторонний сигнал REF CLK обеспечить, и это должно быть либо 200 либо 300 МГц ровно?
По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).
Цитата(Mityan @ Dec 23 2013, 10:35)
По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).
ISERDES нужен только для понижения входной частоты, которая слишком высока для софтлогики. 1 к 4 достаточно, окончательная десериализация должна выполняться на софтлогике, так что больше одного ISERDES на входную линию не требуется.
Цитата(Mityan @ Dec 23 2013, 13:35)
ПЛИС XC6VLX240T-1FFG1156.
Если я правильно понял, то эта схема на IODELAY нужна для компенсации доп. задержки, которую вносит BUFR. Конечно, поскольку временные диаграммы сигналов на выходе АЦП (а значит и на входе ПЛИС) как раз такие, как нужно, было бы идеально их завести через одинаковые буферы IBUFDS. Но поскольку DCO используется для тактирования преобразователя последовательных данных в параллельные, он должен быть подан в цепи тактирования (region clock) на специальные входы (clock capable). Через буфер. И вот тут-то временные соотношения и поплывут при высоких входных частотах. Верно? Или я чего-то недопонял?
В документе харр1071 (см. картинку выше) изображена именно обратная связь - выходной тактовый сигнал с BUFR заводится в блок IODELAY1 на опорный вход С. И задержка блока выражается именно в долях данного тактового (ниже привожу картинку из документа v6_DC_and_Switching_Characteristics).
Или мне нужно некий сторонний сигнал REF CLK обеспечить, и это должно быть либо 200 либо 300 МГц ровно?
По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).
Если я правильно понял, то эта схема на IODELAY нужна для компенсации доп. задержки, которую вносит BUFR. Конечно, поскольку временные диаграммы сигналов на выходе АЦП (а значит и на входе ПЛИС) как раз такие, как нужно, было бы идеально их завести через одинаковые буферы IBUFDS. Но поскольку DCO используется для тактирования преобразователя последовательных данных в параллельные, он должен быть подан в цепи тактирования (region clock) на специальные входы (clock capable). Через буфер. И вот тут-то временные соотношения и поплывут при высоких входных частотах. Верно? Или я чего-то недопонял?
В документе харр1071 (см. картинку выше) изображена именно обратная связь - выходной тактовый сигнал с BUFR заводится в блок IODELAY1 на опорный вход С. И задержка блока выражается именно в долях данного тактового (ниже привожу картинку из документа v6_DC_and_Switching_Characteristics).
Или мне нужно некий сторонний сигнал REF CLK обеспечить, и это должно быть либо 200 либо 300 МГц ровно?
По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).
Если задержка возникает именно в клоковой цепи, то логично было бы её компенсировать добавлением доп. задержки в канал данных, т.е. добавить IODELAY в data lane. Хотя возможно и предложенная в XAPP схема тоже работает. Тут ещё многое зависит от качества разводки вашей платы. Если все дифф. пары на плате у вас выровнены по длине, то достаточно порулить задержкой по клоку для нахождения устойчивого состояния приёма данных (абсолютная фаза тут не очень важна - задержка на целое число бит далее скомпенсируется логикой подстройки по фрейму).
В принципе в вашем случае чем выше частота на клоках IODELAY тем лучше разрешение по времени задержки.
Десериализатор вам нужен только один на каждый канал данных. Достаточно режима 1:4, весь дальнейший демультиплекс данных и выравнивание по фрейму можно делать на частоте 224МГц. Для frame adjustment также можно пользовать bitslip логику десериализаторов.
Большое спасибо за идею по поводу понижения тактовой и использования только одного ISERDESE1.
Ковыряю дальше, и встретил вот что (в документе ug361_Select_IO):
Если используется IODELAY, значит должен быть также объявлен экземпляр (instance) IDELAYCTRL.
Он используется для калибровки всех ЛЗ (в регионе - IOBank). Я английский понимаю очень хорошо, но есть в документе фраза, которая ломает мне моск.
То есть, независимо от всего остального дизайна, если я использую IODELAY, одна из глобальных тактовых частот у меня должна быть 200 МГц? В таком случае независимо от частоты сигнала, подаваемого на ЛЗ, каждый отвод ЛЗ будет составлять 78 пс (1/64 от опорного)?
Ладно, если так, это приемлемо (хотя это, вроде, идет вразрез с обратной связью в документе харр1071).
Но может ли кто-либо объяснить следующую игру слов:
"clock must be driven by a global clock buffer --- can be supplied directly from a user-supplied source"
и "must be routed on a global clock buffer"
Или я могу все-таки взять опорный со своего входа (как в харр1071), но подавать надо еще и на выводы global clock, чтобы запитать этот IDELAYCTRL?
Что-то я запутался...
Ковыряю дальше, и встретил вот что (в документе ug361_Select_IO):
Если используется IODELAY, значит должен быть также объявлен экземпляр (instance) IDELAYCTRL.
Он используется для калибровки всех ЛЗ (в регионе - IOBank). Я английский понимаю очень хорошо, но есть в документе фраза, которая ломает мне моск.
Цитата
REFCLK - Reference Clock
The reference clock (REFCLK) provides a timereference to IDELAYCTRL to calibrate all
IODELAYE1 modules in the same region. This clock must be driven by a global clock
buffer (BUFGCTRL). REFCLK must be FIDELAYCTRL_REF ± the specified ppm tolerance
(IDELAYCTRL_REF_PRECISION) to guarantee a specified IODELAYE1 resolution
(TIDELAYRESOLUTION). REFCLK can be supplied directly from a user-supplied source or the
MMCM and must be routed on a global clock buffer.
The reference clock (REFCLK) provides a timereference to IDELAYCTRL to calibrate all
IODELAYE1 modules in the same region. This clock must be driven by a global clock
buffer (BUFGCTRL). REFCLK must be FIDELAYCTRL_REF ± the specified ppm tolerance
(IDELAYCTRL_REF_PRECISION) to guarantee a specified IODELAYE1 resolution
(TIDELAYRESOLUTION). REFCLK can be supplied directly from a user-supplied source or the
MMCM and must be routed on a global clock buffer.
То есть, независимо от всего остального дизайна, если я использую IODELAY, одна из глобальных тактовых частот у меня должна быть 200 МГц? В таком случае независимо от частоты сигнала, подаваемого на ЛЗ, каждый отвод ЛЗ будет составлять 78 пс (1/64 от опорного)?
Ладно, если так, это приемлемо (хотя это, вроде, идет вразрез с обратной связью в документе харр1071).
Но может ли кто-либо объяснить следующую игру слов:
"clock must be driven by a global clock buffer --- can be supplied directly from a user-supplied source"
и "must be routed on a global clock buffer"
Или я могу все-таки взять опорный со своего входа (как в харр1071), но подавать надо еще и на выводы global clock, чтобы запитать этот IDELAYCTRL?
Что-то я запутался...
Нашел еще один несколько похожий документ - харр881 Virtex-6 FPGA LVDS 4X Asynchronous Oversampling at 1.25 Gb/s
Из него становится понятно, что действительно надо отдельный сигнал фиксированной частоты (200 или 300 МГц) заводить на IDELAYCTRL (рисунок прилагаю). Выход IDELAYCTRL - RDY, собственно, никуда больше не идет, но сам примитив нужен.
У меня тогда вот такой вопрос по документации.
К документу харр881 на сайте прилагается зип-архив с reference design files. Скачали и посмотрели.
А в тексте интересующего меня документа харр1071 приводится адрес, по которому находятся те же reference design files, но при переходе по данной ссылке требуется подробный ввод данных аккаунта Xilinx, после чего появляется сообщение с извинениями, что данный аккаунт не прошел проверку (failed US export compliance verification).
Вопрос: как мне его достать - искать друзей в америке, симулировать американский IP, чо-то в аккаунте поправить или есть тут на форуме добрые люди с таким доступом?
Спасибо
Из него становится понятно, что действительно надо отдельный сигнал фиксированной частоты (200 или 300 МГц) заводить на IDELAYCTRL (рисунок прилагаю). Выход IDELAYCTRL - RDY, собственно, никуда больше не идет, но сам примитив нужен.
У меня тогда вот такой вопрос по документации.
К документу харр881 на сайте прилагается зип-архив с reference design files. Скачали и посмотрели.
А в тексте интересующего меня документа харр1071 приводится адрес, по которому находятся те же reference design files, но при переходе по данной ссылке требуется подробный ввод данных аккаунта Xilinx, после чего появляется сообщение с извинениями, что данный аккаунт не прошел проверку (failed US export compliance verification).
Вопрос: как мне его достать - искать друзей в америке, симулировать американский IP, чо-то в аккаунте поправить или есть тут на форуме добрые люди с таким доступом?
Спасибо
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.