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

 

[_Anatoliy]

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

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

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

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

[des00]

Приложен минимальный проект: 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 клок семплирования подвинуть ?

[_Anatoliy]

Вот пример для 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 "**********************************************************"

[des00]

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

брррр.

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

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

[_Anatoliy]

брррр.

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

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

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

[des00]

А это к кому вопрос,ко мне или к ТС?

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

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

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

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

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

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

 

[_Anatoliy]

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

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

[des00]

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

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

[andrew_b]

Всё странно :
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.

[_Anatoliy]

Если не сложно, расскажите как вы считаете, что считаете и самое главное зачем?

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

[Anton1990]

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

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

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

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

[des00]

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

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

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

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

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

[andrew_b]

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

К сожалению, плата у же есть. Во-вторых, DCO будет меняться в зависимости от режима работы всего устройства. 250 МГц -- это его максимальное значение, но может быть и меньше.

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

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

 

[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]

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

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

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

 

[des00]

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

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

картинка да, но сразу идет логическая цепочка : производитель чипа гарантирует выравнивание clk_out и data_out во всех режимах эксплуатации чипа -> зачем создавать виртуальный клок и вписывать кучу параметров, если все можно сделать проще?

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

 

[andrew_b]

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

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

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

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

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

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

[_Anatoliy]

Думаю что нельзя сказать что один метод хорош,другой плох. Тут видимо дело вкуса(физический смысл от метода не зависит). А сама Альтера говорит так:

Код

You can create
input delay constraints relative to the input clock instead of the virtual clock, but
using a virtual clock makes the constraining of the interface easier and more accurate.
A virtual clock makes it easy to constrain inputs with the skew-based FPGA-centric
approach. You can use the positive and negative skew requirement values for the
input maximum and minimum delay constraints with no other calculations. Even if
the source or destination clock is shifted, the input maximum and minimum delay
values do not change.

Вобщем, я тоже глубоко не копал.

И таки шо делать?

А подвигать фазу клока не пробовали?

[des00]

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

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

[andrew_b]

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

Если делать так, то немедленно появляются hold slack'и непосредственно в IOCELL. И мне не удалось подобрать сдвиг, чтобы их не было. Это в дополнение в setup slack'ам на прежних местах. То есть всё становится ещё хуже.

Если DCO заводить на IO, а выход PLL в ALM, то получаем то же самое, что и начальная ситуация. И тоже не удаётся компенсировать все slack'и сдвигом тактовой.

В общем, ситуация такая: сдвиги тактовой (одной или обеих) лечат одни slack'и, но дают другие. При некоторых сдвигах в дополнение к setup slack'ам появляются hold slack'и.

Минус в использовании PLL я вижу в том, что DCO может быть разной. Как PLL на это будет реагировать?

[_Anatoliy]

Если PLL не переконфигурировать то допустимые частоты будут определяться коэффициентом перестройки частоты ГУН.
С IOCELL отдельная песня,не пытайтесь сразу решить две проблемы. А в принципе вам удаётся подобрать такую фазу что слэки в регистрах уходят? Вместо ФАПЧ ещё можно попробовать цепочку LCELL нужной длины, но тут есть риск и он должен быть осознанным.

[alexadmin]

Меня сейчас растопчут ногами, но я давно уже махнул рукой на временной анализ I/O для взаимодействия с АЦП/ЦАП. Ибо гарантированной работоспособности так толком добиться и не смог. Где-то тут на форуме были мои страдания на эту тему. Вместо этого делаю регулируемую задержку в пине и выбираю оптимальное значение задержки путем натурных испытаний (или кручу фазу клока PLL как альтернативный вариант.

[andrew_b]

А в принципе вам удаётся подобрать такую фазу что слэки в регистрах уходят?

В принципе нет.
Вот какая штука получается.
Я экспериментировал с такой схемой: IO тактируются напрямую DCO, регистры -- клоком с выхода PLL, фазу которого я подбирал. PLL работает в режиме source synchronous.
При фазе 0 слаки лежат в диапазоне -2.056...-1..771 нс. Этих слаков 18 из 24.
Далее начинаем двигать фазу клока с шагом 15 градусов (1/24 периода или 4/24 ~ 0.17 нс).
При сдвиге +15 градусов в слаках оказываются все 28 триггеров, диапазон слаков -5.890...-3.417 нс. Ну, оно и понятно: -5.890 = -2.056 - 4 * 23/24.
Дальнейшие сдвиги приводят к уменьшению слаков пропорционально величине сдвига, но в пределе получаем те же изначальные -2.056...-1..771.

Если приглядеться к диапазону -5.890...-3.417 нс, то можно увидеть, что часть слаков меньше периода клока, а часть больше. То есть задержки по данным таковы, что часть шины таксть "лежит" в одном периоде, а часть в другом. И тут как клок ни двигай, ничего не получится.

Втыкание LCELL -- это крайний случай, НЗ. Очень бы не хотелось его использовать.

[_Anatoliy]

[attachment=95765:sms2.png]

Если приглядеться к диапазону -5.890...-3.417 нс, то можно увидеть, что часть слаков меньше периода клока, а часть больше. То есть задержки по данным таковы, что часть шины таксть "лежит" в одном периоде, а часть в другом. И тут как клок ни двигай, ничего не получится.

Я правильно нарисовал ситуацию которую вы описали?

Код

____||----|____|----|____
ххххххxxxxxххх<=>xxxxxxx
---|____|----|____||----|____

Здесь || - фронт-источник и фронт-приёмник. Может просто ввести мультициклы? Это не ваша ситуация?На картинке задержки превышают период тактовой,это не страшно, здесь главное чтобы разброс задержек в шине был меньше тактового периода,а подбором фазы уже обеспечить надёжный приём.

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

 

[_Anatoliy]

Меня сейчас растопчут ногами, но я давно уже махнул рукой на временной анализ I/O для взаимодействия с АЦП/ЦАП.

Раз уважаемая общественность молчит то есть повод думать что втихаря все понемногу делают это.

[andrew_b]

Начал наконец смотреть распиновку.

Код

Din [0] DFFIO_RX_B75/B_DQS_3
Din [1] DFFIO_RX_B82/B_DQ33 *
Din [2] DFFIO_RX_B71
Din [3] DFFIO_RX_B70/B_DQ21 *
Din [4] DFFIO_RX_B78/B_DQ29 *
Din [5] DFFIO_RX_B66/B_DQ17 *
Din [6] DFFIO_RX_B62/B_DQ13 *
Din [7] DFFIO_RX_B74/B_DQ25 *
Din [8] DFFIO_RX_B79
Din [9] DFFIO_RX_B51/B_DQS_0
Din [10] DFFIO_RX_B58/B_DQ9 *
Din [11] DFFIO_RX_B50/B_DQ1 *
Din [12] DFFIO_RX_B54/B_DQ4 *
Din [13] DFFIO_RX_B67/B_DQS_2

Слаки на сигналах, помеченных звёздочками, т. е. DQ[*].
Начал прочёсывать интернет. И выяснилось:

http://www.alteraforum.com/forum/showthrea...9491#post189491

Cyclone V DQ pin used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE. this routing element would cause almost 2ns differnece between setup and hold. no way to bypass it.
so never use DQ pins as high speed input or output in cyclone V

С одной стороны, эти 2 нс мы как раз и наблюдаем.
С другой -- как это сформулировано. Ведь "DQ pin used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE" -- это один смысл, а "DQ pin is used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE" -- несколько иной. И "never used" как бы намекает на второй.

[des00]

И "never used" как бы намекает на второй.

ИМХО главное тут "no way to bypass it." Казлы.

ЗЫ. в свое время на подобное (т.е. не рекомендуется для высокоскоростного интерконнекта) поведение напоролся с пинами VREFB.

PPS. ИМХО лечите PLLкой. клоки с разными фазами для разных линий. Собираете в регистры. Замена частоты тактирования через автомат реконфигурации PLL. Во второй ревизии поправить ноги плиса.

[andrew_b]

лечите PLLкой. клоки с разными фазами для разных линий. Собираете в регистры.

Не вопрос.
Вопрос в другом. У части шины задержки получаются больше периода. Лишним регистром я их выровняю. Но как объяснить это TA? Мультициклы писать? Я думал, что мультициклы пригодны только для сигналов, длительность которых больше периода. А АЦП данные приходят каждый клок.

[des00]

Вопрос в другом. У части шины задержки получаются больше периода. Лишним регистром я их выровняю. Но как объяснить это TA? Мультициклы писать? Я думал, что мультициклы пригодны только для сигналов, длительность которых больше периода. А АЦП данные приходят каждый клок.

мультициклами сдвигаете фронты анализа. т.е. говорите что сетап сдвинут на 2 фронт, а hold не на нулевой (как в классическом мультицикле), а на 1 фронт.

[andrew_b]

Отпишусь по результатам натурных испытаний.

HMCPHY_RE упоминает в хэндбуке на C V только один раз. Не заметить этот малюсенький абзац проще простого. Увидеть наличие HMCPHY_RE я смог только в одном месте: в отчёте TimeQuest и то только при выставленной галке Show Routing. Всё. Ни в Chip planner, ни в нетлисте после разводки никаких HMCPHY_RE нет.

Самое странное вот что. Часть шины по отчёту TQ имеет задержки больше периода, поэтому на остальную часть вроде бы как надо поставить дополнительный регистр, чтобы компенсировать задержки в HMCPHY_RE. Так вот, если этого не делать, то данные принимаются правильно. Если регистр всё-таки поставить, то данные неправильные.

До экспериментов с железкой ситуацию могло бы прояснить моделирование с задержками после разводки, но

Post-synthesis and post-fit gate-level simulations run significantly slower than RTL simulation. Altera
recommends that you verify your design using RTL simulation for functionality and use the TimeQuest
timing analyzer for timing. Timing simulation is not supported for Arria V, Cyclone V, Stratix V, and
newer families.

Гады.

[otv116]

Добрый день.
Делаю прошивку под C-III как раз с АЦП AD9634, который тут упоминался.
Все работает нормально, но хочу навести порядок в голове с констрейнами по входу.
Вопрос возник по примеру sdc, что предоставил des00.
Сначала опишу что сделал сам.
Решил тоже не юзать виртуальный клок, а описывать непосредственно от DCO.
По даташиту фронт DCO запаздывает за данными на Tskew (0.3 : 0.7 нс).
Соответственно:

CODE

set_input_delay -max -clock [get_clocks {ADC1DCO}] -0.3 [get_ports {ADC1Data[*]}]
set_input_delay -max -clock [get_clocks {ADC1DCO}] -clock_fall -0.3 [get_ports {ADC1Data[*]}] -add_delay

set_input_delay -min -clock [get_clocks {ADC1DCO}] -0.7 [get_ports {ADC1Data[*]}] -add_delay
set_input_delay -min -clock [get_clocks {ADC1DCO}] -clock_fall -0.7 [get_ports {ADC1Data[*]}] -add_delay

set_false_path -rise_from [get_clocks {ADC1DCO}] -fall_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}]
set_false_path -fall_from [get_clocks {ADC1DCO}] -rise_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}]

Задержки по плате не учитываю, т.к. АЦП близко к FPGA и их вклад несущественен.
В FPGA ставлю PLL в режиме source synchronous и ей подкручиваю фазу, чтобы TQ не ругался.

С первой потытки выставил так, что слаки по сетапу большие, по холду - на грани: 2.3 нс и 0.2 нс. Залил в плату - все работает.
На плате 4 АЦП, со всеми все ок (на каждый свой pll).
Подвинул фазу так, чтобы сбалансировать сетап и холд. Стали в районе 1.2 нс. Заливаю - не годится.
Получается что я неверно задал констрейны и в первом случае просто пальцем в небо?

ок, беру sdc от des00.
Когда сетап на грани - не работает. Возможно сказываются задержки на плате.
Балансирую сетап и холд. Оба становятся в районе 0.75 нс. Заливаю - порядок.
Как говорится, респект des00.

des00, подскажите, пожалуйста, как вы получили цифры -max 1.0, -min -0.4.
Может подскажете, где я ошибся в своих констрейнах.


Спасибо.

Сообщение отредактировал otv116 - Mar 3 2018, 09:40

[otv116]

Пробовал бороться с задержкой сигнала от DQ пина до LAB через HMCPHY. Как и автор топика.
alt_lvds работает на клоке, сдвинутом относительно ADC_DCO, чтобы защелкивать данные в нужный момент.
В лабе защелкиваю вторым клоком, еще немного сдвинутым. Оба эти клока делаются одной и той же pll в режиме source synchronous.
Между ними добавил мультицикл. Все как предлагал des00.
Ничего толкового не вышло. Из четырех моделей, по которым ведется анализ (комбинации 0С 85С fast slow), всегда какая-то
не проходит. Как я понял, из за того, что путь очень длинный, то его вариации от PVT очень велики в абсолютном значении.
Поэтому подогнав под одну модель, херим другую.

Еще заметил одну вещь.
Я работаю с 5CEBA4F23C7. В нем вообще нет hard memory controller. Но 6 пар из 24 LVDS сигналов АЦП, которые я завел на DQ пины (еще не зная о проблеме), пошли в лаб через HMCPHY. Остальные напрямик, с ними проблемы нет.
Смотрел это в отчете time quest.


Сообщение отредактировал otv116 - Mar 21 2018, 13:07

[_Anatoliy]

Кстати, насчёт HMCPHY, может есть у кого доступ на альтерафорум - помогите скачать:
Using Cylcone V HMCPHY DQ pins as high frequency inputs.pdf
Наверное не только мне будет интересно.

[otv116]

Для интереса поменял CEBA на CEFA, у которого есть HMC.
Ничего не изменилось. Кто шел напрямик, тот и идет. Кто через HMCPHY, так и идет через HMCPHY.

-> _Anatoliy
см. аттач.

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

 Using_Cylcone_V_HMCPHY_DQ_pins_as_high_frequency_inputs.pdf ( 1.36 мегабайт ) Кол-во скачиваний: 12

 

[_Anatoliy]

Спасибо, коллега!
Тоже сталкивался с подобной ситуацией, только не с АЦП а с ЦАП и на Циклоне-3. Два бита из шины данных никак не удавалось усмирить. Прободавшись некоторое время решил забить на это дело, так как нарушений работоспособности не увидел. Изделие выпускается уже 12 лет без нареканий, может мне "повезло" наткнуться на глюк самого STA.

[Flip-fl0p]

Спасибо, коллега!
Тоже сталкивался с подобной ситуацией, только не с АЦП а с ЦАП и на Циклоне-3. Два бита из шины данных никак не удавалось усмирить. Прободавшись некоторое время решил забить на это дело, так как нарушений работоспособности не увидел. Изделие выпускается уже 12 лет без нареканий, может мне "повезло" наткнуться на глюк самого STA.

Подстройкой фазы, можно добиться стабильного приёма практически на всем диапазоне частот. Во всяком случае 5 циклон С6 имеет ограничение на прием 800Mb/s. Однако я на этих DQ пинах вполне стабильно вытягивал - 780 Mb/s. А пути между DDR регистрами и логикой - я исключил из анализа времянок.
P.S. Однако данный способ очень кривой и нестабильный, поскольку по какой-то неизвестной мне причине добавление в этот проект дополнительных блоков сбивает стабильный прием, и выше 500 Mb/s уже скорость не поднимается. Думаю тут надо как-то хитро задать времянки.