Перейти к содержанию

    

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

 

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

 

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

slacks.qar.txt

Поделиться сообщением


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

 

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

 

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

Если в первом процессе заменить falling на rising то отрицательные слеки уходят.

Поделиться сообщением


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

Всё странно :

1. В этом АЦП есть специальный пин DCO (digital clock output), выровненный к данным, как раз что бы не иметь проблем с захватом сигнала с АЦП. Вы его не используете.

2. В ячейке ввода вывода сыклона 5, есть специальный, дополнительный триггер, для инверсного канала. Специально что бы выравнивать данные. Как _Anatoliy указал, полярность тактовой бы сменить.

3.1 Если вы не используете DCO, то неясно соотношение сдвига тактовых на АЦП и ПЛИС. При этом не понятно как учитывается tdco = 6.7нс для этого чипа.

3.2 Если ваш клок это и есть DCO, то вы должны были учитывать обе границы tskew [0.4:1.0]нс.

3.3 Что мешает на PLL клок семплирования подвинуть ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот пример для AD9634.

#**************************************************************
# Set Input Delay
#**************************************************************
create_clock -period $tDCO -name {virt_clk_in}
set_clock_groups -asynchronous -group {virt_clk_in} -group {ClkAdc}
# clock source to source clock pin delay
set clkAs_delay_max 0.0 
#[expr 30.0*0.010]
set clkAs_delay_min 0.0
#[expr 30.0*0.005]
# clock source to destination clock pin delay
# 30mm 0.010 ns/mm
set clkAd_delay_max [expr 30.0*0.010]
set clkAd_delay_min [expr 30.0*0.005]
# source to destination data pins delay
set bdA_delay_max [expr 30.0*0.010]
set bdA_delay_min [expr 30.0*0.005]
#ADC parameters AD9634
set tPD_min 4.1
set tPD_max 5.2
set tDCO_min 4.7
set tDCO_max 5.8
set tCLK     9.3
set Tco_max [expr $tCLK/2 - $tDCO_min + $tPD_max]
set Tco_min [expr $tCLK/2 - $tDCO_max + $tPD_min]
#set Tco_max 6.5
#set Tco_min 2.5
set usedTsu [expr $clkAs_delay_max + $Tco_max + $bdA_delay_max - $clkAd_delay_min]
set usedTh [expr $clkAs_delay_min + $Tco_min + $bdA_delay_min - $clkAd_delay_max]
set_input_delay -clock {virt_clk_in} -max $usedTsu [get_ports {InAdc[*]}]
set_input_delay -clock {virt_clk_in} -min $usedTh [get_ports {InAdc[*]}]
post_message "**********************************************************"
post_message "***Tco_max = $Tco_max ns"
post_message "***Tco_min = $Tco_min ns"
post_message "***usedTsu = $usedTsu ns"
post_message "***usedTh = $usedTh ns"
post_message "**********************************************************"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Вот пример для AD9634.

брррр.

 

Так. Еще раз. Как у вас сделано :

1. АЦП тактируется от генератора который заходит на CLK ADC. Этот же генератор заходит на ПЛИС. DCO остался висеть в воздухе.

2. АЦП тактируется от генератора который заходит на CLK ADC. На плис заходит DCO.

 

Какой именно вариант у вас ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
брррр.

 

Так. Еще раз. Как у вас сделано :

1. АЦП тактируется от генератора который заходит на CLK ADC. Этот же генератор заходит на ПЛИС. DCO остался висеть в воздухе.

2. АЦП тактируется от генератора который заходит на CLK ADC. На плис заходит DCO.

 

Какой именно вариант у вас ?

А это к кому вопрос,ко мне или к ТС? У меня в плис заходит сигнал DCO. Ведь времянки в даташите на АЦП приведены относительно его.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А это к кому вопрос,ко мне или к ТС?

Хмм, обчитался. получается вопрос к обоим :)

У меня в плис заходит сигнал DCO.

Если заходит то почему он у вас виртуальный?

Ведь времянки в даташите на АЦП приведены относительно его.

может я даташиты читаю по другому. В атаче все относительно CLK. И для схемы с использованием DCO актуальны времена tskew

post-3453-1443442909_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
может я даташиты читаю по другому. В атаче все относительно CLK. И для схемы с использованием DCO актуальны времена tskew

Зная Tdco времянки легко пересчитать. Одного tskew недостаточно для задания сетапа и холда.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Зная Tdco времянки легко пересчитать. Одного tskew недостаточно для задания сетапа и холда.

На плис приходит поток данных и клок выровненный с ними, внутри ацп уже с учетом tdco, до небольшого перекоса. Если не сложно, расскажите как вы считаете, что считаете и самое главное зачем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Всё странно :

1. В этом АЦП есть специальный пин DCO (digital clock output), выровненный к данным, как раз что бы не иметь проблем с захватом сигнала с АЦП. Вы его не используете.

Использую. Clk он и есть.

 

2. В ячейке ввода вывода сыклона 5, есть специальный, дополнительный триггер, для инверсного канала.
Ну так в ddio три триггера и используются.

 

Специально что бы выравнивать данные. Как _Anatoliy указал, полярность тактовой бы сменить.
Я пробовал по-разному. Слаки были во всех случаях, но были разные.

 

3.2 Если ваш клок это и есть DCO, то вы должны были учитывать обе границы tskew [0.4:1.0]нс.
В самих IO слаков нет. Я вижу слаки у DinHi_f и DinLo_f, то есть не в IO, а в ALM.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Если не сложно, расскажите как вы считаете, что считаете и самое главное зачем?

А зачем? У меня как раз вопросов нет, всё работает с хорошими слэками, просто хотел помочь ТС.

Поделиться сообщением


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

 

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

 

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

 

Я использую примерно такуюже микросхему от TexasInstr. Были аналогичные проблемы. Так вот очень советую использовать не сигнал DCO rjnjhsq bltn bp АЦП а завести сигнал тактирования АЦП прямо с генератора на другую ножку ПЛИС ею и защелкивать регистры. Результат стал стабильный и хороший.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А зачем? У меня как раз вопросов нет, всё работает с хорошими слэками, просто хотел помочь ТС.

Помочь мне решить противоречие с моей логикой здравого смысла. TQ вещь предельно тупая, манипуляцией задаваемых цифр я могу выполнить любые констрейны. Смотрю на ваш sdc, вижу что вместо реального, настоящего DCO клока, приходящего на ПЛИС, который может быть адекватно посчитан, вы используете сферического коня в вакууме (виртуальный клок). И вот тут мой принцип физической обоснованности и логики здравого смысла дает сбой.

 

Думаю в любом случае климатическая камера нас рассудит.

 

Использую. Clk он и есть.

теперь стало яснее, покручу вашу болванку

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Так вот очень советую использовать не сигнал DCO rjnjhsq bltn bp АЦП а завести сигнал тактирования АЦП прямо с генератора на другую ножку ПЛИС ею и защелкивать регистры. Результат стал стабильный и хороший.
К сожалению, плата у же есть. Во-вторых, DCO будет меняться в зависимости от режима работы всего устройства. 250 МГц -- это его максимальное значение, но может быть и меньше.

 

Upd. Пара скриншотов.

post-1757-1443508251_thumb.png

post-1757-1443508261_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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ке

post-3453-1443510150_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация