[maxics 0]

Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.

Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).

В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?

Файл с исходным кодом:

ADC2195_receiver.vhd

[TRILLER 0]

А вы входные триггеры в "лапы" поместили?

[dmitry-tomsk 0]

Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.

Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).

В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?

Файл с исходным кодом:

ADC2195_receiver.vhd

Да уж. Во-первых, смотрите xapp645. Принимать надо входными serdes, инвертировать после триггера или serdes. Если разводка и правильная, то можно и dcm фазу двигать, а по идее надо через iodelay на каждом выводе. У этого ацп есть тестовый режим, по нему легко фазу подстроить динамически. У меня s6 принимает в режиме 2-х линий, частота выборки 800 мгц, запас по фазе где-то 8 делений iodelay, и даже при идеально выровненных парах оптимальная фаза отличается до 2-х делений.

[maxics 0]

А вы входные триггеры в "лапы" поместили?

 

Что есть "лапы"?

[Maverick_ 15]

Что есть "лапы"?

лапы = пины = ножки = выводы ПЛИС

IO логика имеется ввиду для каждого вывода ПЛИС

[elzaro 0]

лапы = пины = ножки = выводы ПЛИС

IO логика имеется ввиду для каждого вывода ПЛИС

 

надо засадить входной регистр в ноги плиса. к регистру примени атрибут IOB = "true"

[Bad0512 2]

Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.

Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).

В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?

Файл с исходным кодом:

ADC2195_receiver.vhd

1. Пропишите в UCF файле OFFSET constraint, описывающий вашу ситуацию. Примеры есть в Constraints guide.

2. Вместо того АДа, что у вас в коде используйте примитивы IDDR для работы с LVDS сигналом по двум фронтам. В итоге сигнал будет проходить вот так : IBUFGDS -> IDDR -> ваша дальнейшая логика демультиплексирования.

3. На таких частотах в принципе можно и без DCM обойтись если грамотно использовать рекмендации Xilinx по source synchronous clocking, тут выбор за вами.

4. В вашем модуле данные идут с 2-х АЦП, а DCO - всего один, почему?

[o_khavin 0]

Что есть "лапы"?

IO timing из даташита гарантируется только для случая, когда входные/выходные регистры располагаются в IO-cell. Это достигается атрибутом IOB=true на соответствующих регистрах проекта. При этом между регистром и пином никакой дополнительной логики быть не должно.

[maxics 0]

Сделал все как было написано выше. Такт пускаю через BUFIO2 и затем на PLL, где делаю такт для IDDR.

Стабильности не прибавилось.

Не выполняются тайминги для констрейнтов описанных в 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

В чем может быть причина ошибок?

[xvr 12]

Судя по этим строкам в отчете -

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 уровня логики, а их вообще быть не должно.

[o_khavin 0]

Сделал все как было написано выше. Такт пускаю через BUFIO2 и затем на PLL, где делаю такт для IDDR.

Стабильности не прибавилось.

Не выполняются тайминги для констрейнтов описанных в UCF:

В чем может быть причина ошибок?

Почитайте в документации Xilinx-а про source synchronous IO vs system synchronous IO. IMHO, у Вас проблема в неправильном выборе типа.

 

Судя по этим строкам в отчете -

у вас между IDDR2 и его данными (да и клоком тоже) по 3-4 уровня логики, а их вообще быть не должно.

А на схему Вы смотрели? Эти уровни логики - просто количество компонентов по дороге. Например, для клокового пути: ibufgds, bufio2, pll, bufg.

 

[xvr 12]

А на схему Вы смотрели?

Смотрел, и на отчет тоже смотрел

Эти уровни логики - просто количество компонентов по дороге. Например, для клокового пути: ibufgds, bufio2, pll, bufg.

Буфера не входят в уровни логики. Уровни логики - это количество LUT'ов на пути сигнала. Буфера в LUT'ы не заходят.

Посмотрите в Technology View как у вас на самом деле подключились сигналы

 

[o_khavin 0]

Смотрел, и на отчет тоже смотрел

Буфера не входят в уровни логики. Уровни логики - это количество LUT'ов на пути сигнала. Буфера в LUT'ы не заходят.

Посмотрите в Technology View как у вас на самом деле подключились сигналы

Во первых, это не мой дизайн. Во вторых, я ни разу не видел, чтобы схематик с явно нарисованными примитивами и соединениями между ними, самопроизвольно пополнялся LUT-ми. В третьих, покажите мне пример дизайна с 4-мя уровнями LUT-ов на клоковом пути (если следовать Вашей логике при чтении отчёта), и без трёхэтажных матюков в логе роутера.

[xvr 12]

Во первых, это не мой дизайн.

Пардон, это был совет для ТС

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

Я тоже, но отчет синтезатора говорит явно и не двусмысленно, что логика там есть. Я подозреваю, что схематик не соотвествует действительности (или ругань относится к другому элементу схемы)

В третьих, покажите мне пример дизайна с 4-мя уровнями LUT-ов на клоковом пути (если следовать Вашей логике при чтении отчёта), и без трёхэтажных матюков в логе роутера.

ТС не показал нам лога роутера - возможно они там и были :)

 

Пока ТС не покажет нам, как на самом деле развелась схема, о чем то спорить бессмысленно

 

[TRILLER 0]

Извините, со спартанами не работал, но.. каким образом обеспечивается офсет из уцфника? Чего-то я там иоделэев не увидел. Вот, наверное, протягиванием сингала через логику и обеспечивается офсет. Конечно, возможно и путаю чего..

Изменено 9 декабря, 2013 пользователем TRILLER