ADC DDR and setup slacks Опции

[andrew_b]

Имееется ADC AD6649, выдающая 14-разрядные данные в DDR-режиме на частоте до 250 МГц. Приёмником выступает Cyclone V.

Не получается разводка без ошибок в STA. Причём ошибки в одном и том же месте: на пути от выхода ddio до ближайшего триггера. Там небегает какое-то дикая задержка по данным, что никак не укладывается в 4-нс тактовую. Что с этим делать, я уже не знаю. LogicLock ситуацию не спасает. Задержки меньше, чем без него (естественно), но слаки не уходят.

Приложен минимальный проект: ddio->регистры->выход. Буду признателен, если кто-то взглянет.

Прикрепленные файлы

 slacks.qar.txt ( 3.38 килобайт ) Кол-во скачиваний: 50

 

[des00]

Мне удобнее с верилогом работать. Поправил код :

Код

module slacks #(parameter pDAT_W = 14) (input Clk, input [pDAT_W-1 : 0] Din, output logic [pDAT_W-1 : 0] dout_re, dout_im);

  logic [pDAT_W-1 : 0] ddio__dataout_h;
  logic [pDAT_W-1 : 0] ddio__dataout_l;
  logic [pDAT_W-1 : 0] dat_re [2];
  logic [pDAT_W-1 : 0] dat_im [2];

  altddio_in
  #(
    .intended_device_family ( "Cyclone V"  ) ,
    .invert_input_clocks    ( "OFF"         ) ,
    .lpm_hint               ( "UNUSED"     ) ,
    .lpm_type               ( "altddio_in" ) ,
    .power_up_high          ( "OFF"        ) ,
    .width                  ( pDAT_W       )
  )
  ddio
  (
    .datain     ( Din             ),
    .inclock    ( Clk             ),
    .dataout_h  ( ddio__dataout_h ),
    .dataout_l  ( ddio__dataout_l ),
    .aclr (1'b0),
    .aset (1'b0),
    .inclocken (1'b1),
    .sclr (1'b0),
    .sset (1'b0)
  );

  always_ff @(posedge Clk) begin
    {dat_re[1], dat_re[0]} <= {dat_re[0], ddio__dataout_h};
    {dat_im[1], dat_im[0]} <= {dat_im[0], ddio__dataout_l};
    //
    dout_re <= dat_re[1];
    dout_im <= dat_im[1];
  end

endmodule

Сделал, адекватный, по моему мнению, sdc

Код

set_time_format -unit ns -decimal_places 3

set CLK_PERIOD 4.0

create_clock -name {Clk} -period $CLK_PERIOD [get_ports {Clk}]

set tskew_min 0.4
set tskew_max 1.0

# setup
set_input_delay -clock {Clk}                     -rise -max  1.0   [get_ports {Din[*]}] -add_delay
set_input_delay -clock {Clk} -clock_fall     -fall -max  1.0     [get_ports {Din[*]}] -add_delay

# hold
set_input_delay -clock {Clk}                     -rise -min -0.4     [get_ports {Din[*]}] -add_delay
set_input_delay -clock {Clk} -clock_fall     -fall -min -0.4     [get_ports {Din[*]}] -add_delay

# remove incorrect from-to paths
set_false_path -rise_from [get_clocks {Clk}] -through [get_pins -compatibility_mode ddio*\|datain] -fall_to [get_clocks {Clk}]
set_false_path -fall_from [get_clocks {Clk}] -through [get_pins -compatibility_mode ddio*\|datain] -rise_to [get_clocks {Clk}]

И вот дальше не понимаю чем занимается квартус. Пути до регистров, одного вектора, отличаются на 2 нс (см. скрин). Картинка в чип эдиторе и просмотрщике ресурсов, вызывает подозрение на багу софта. Я не понимаю как так происходит.

из вариантов вижу подвинуть клок на PLLке или на lcell. Либо сделать все на PLLке

Эскизы прикрепленных изображений

 

[_Anatoliy]

Скомпилировал исходный проект в двух квартусах, результат во вложении. Верхняя картинка Q12.1, нижняя картинка Q15.0.2. Вы в каких квартусах пробовали?.

Прикрепленные файлы

 quest.doc ( 247 килобайт ) Кол-во скачиваний: 25

 

[andrew_b]

Скомпилировал исходный проект в двух квартусах, результат во вложении. Верхняя картинка Q12.1, нижняя картинка Q15.0.2. Вы в каких квартусах пробовали?.

У меня 13, у des00 -- 14.
Предлагаете откатиться на 12?

[_Anatoliy]

У меня 13, у des00 -- 14.
Предлагаете откатиться на 12?

Ну я пока с 12.1 не соскакиваю...
Стоп,вспомнил - в новых версиях Квартуса поставили уточнённые задержки,поэтому времянки и валятся. Так что ,похоже, синие слэки в Q12.1 ещё не факт что всё будет гут в железе...

вы используете сферического коня в вакууме (виртуальный клок).

А вы читали альтеровский документ "Implementing a Source Synchronous Interface between Altera FPGAs"? Они для подобного интерфейса совсем не брезгуют виртуальным клоком.

[des00]

А вы читали альтеровский документ "Implementing a Source Synchronous Interface between Altera FPGAs"? Они для подобного интерфейса совсем не брезгуют виртуальным клоком.

Читал, физику и логику этого решения тоже не понял, потому и прошу объяснить. Мой вариант основан на физике процесса и логике здравого смысла.

[_Anatoliy]

Читал, физику и логику этого решения тоже не понял, потому и прошу объяснить. Мой вариант основан на физике процесса и логике здравого смысла.

Эта картинка вам понятна?

Эскизы прикрепленных изображений

 

[andrew_b]

Эта картинка вам понятна?

Из неё непонятно, зачем использовать какой-то виртуальный клок, если есть вполне реальный clock_out.

Стоп,вспомнил - в новых версиях Квартуса поставили уточнённые задержки,поэтому времянки и валятся.

Ну так в логе и пишется: временные характеристики чипа предварительные.

Так что ,похоже, синие слэки в Q12.1 ещё не факт что всё будет гут в железе...

У меня тоже есть эти сомнения. И таки шо делать?

[des00]

У меня тоже есть эти сомнения. И таки шо делать?

пропустить DCO через PLL, на ней сформировать 2 клока: для IO регистров и для регистров на чипе.