[Digi 0]

Пытаюсь вникнуть в TimeQuest. Есть АЦП ads42lb69 8 каналов, работающие на частоте 200 Мгц с выходом в режиме QDR. ПЛИС Cyclone 10 GX. У АЦП есть выходы ADC_CLK (DxCLK)   (400МГц)   ADC_FRM (DxFRAMEM)  (200МГц)  ADC_D[n]. Эти сигналы поключены к корке altera_gpio работающей в режиме HalfRate, DDIO, 4 bit.

Тут я пытался описать допустимую задержку прихода данных относительно ADC_FRM, это в принципе не правильно, так как задержку необходимо описывать относительно ADC_CLK, с ней я вообще не добился никаких положительных результатов. Но при таком описании проект заработал за исключением одного канала. 

Тем не менее я так и не понял, как правильно описать констрейны для случая с QDR когда данные выставляются по сдвинутому на 90град клоку, приходит клок и Frame?

Констрейны описал вот так (таковая CLK200 МГц FRM-100 МГц):

#-------------------  ADC timing definition -------------------------

set adc_data_period 5.000
set adc_frame_preiod [expr $adc_data_period * 2]

set frm_min_delay 0.3

set max_data_delay  0.31
set min_data_delay  0.29

#set adc_tsu 0.31
#set adc_th 0.29

create_clock -name virtual_clock_adc -period $adc_data_period -waveform { 1.250 3.750 }
create_clock -name {ADC1_CLK} -period $adc_data_period [get_ports  {ADC1_CLK}] 
create_clock -name {ADC1_FRM} -period $adc_frame_preiod [get_ports {ADC1_FRM}]

set_input_delay -clock virtual_clock_adc -max $max_data_delay  [get_ports {ADC1_D[*]}] -add_delay
set_input_delay -clock virtual_clock_adc -min $min_data_delay  [get_ports {ADC1_D[*]}] -add_delay

set_input_delay -clock {ADC1_CLK}  $frm_min_delay  [get_ports {ADC1_FRM}] -add_delay
set_input_delay -clock {ADC1_CLK} $frm_min_delay [get_ports {ADC1_FRM}]  -add_delay -clock_fall
  
set_false_path -fall_from virtual_clock_adc -rise_to ADC*_CLK
set_false_path -rise_from virtual_clock_adc -fall_to ADC*_CLK

 

[Digi 0]

Попробовал описать по другому. Не пойму, что не устраивает его по времянкам и по какой причине возникают задержки.

Собственно то, что по моему мнению я хотел указать в sdc файле

Задаём частоту CLK и FRAME. Так как CLK фактически смещён на 90 градусов, а данные приходятся на его середину, я не стал указывать сдвиг CLK Считаю что фронт я укажу в set_input_delay -max который равен (половине периода CLK - tSetup). min

set_clock_groups я указал связные клоки. Т.е.  CLK и FRAME с каждого из АЦП.

 

Направьте на путь истинный. Куда копать, куда смотреть и как достичь того, чтобы Данные приходили на регистры за требуемое время ?

 

 

set adc_data_period 5.000
set adc_frame_preiod [expr $adc_data_period * 2]

set max_data_delay  2.19
set min_data_delay  0.29

#set adc_tsu 0.31
#set adc_th 0.29

create_clock -name {ADC1_CLK} -period $adc_data_period [get_ports  {ADC1_CLK}] 
create_clock -name {ADC1_FRM} -period $adc_frame_preiod [get_ports {ADC1_FRM}]

# Front edge of adc data
set_input_delay -clock ADC1_CLK -max $max_data_delay  [get_ports {ADC1_D[*]}] 
set_input_delay -clock ADC1_CLK -min $min_data_delay  [get_ports {ADC1_D[*]}] -add_delay

# Back edge of adc data
set_input_delay -clock ADC1_CLK -max $max_data_delay  [get_ports {ADC1_D[*]}] -add_delay -clock_fall
set_input_delay -clock ADC1_CLK -min $min_data_delay  [get_ports {ADC1_D[*]}] -add_delay -clock_fall

set_clock_groups -exclusive -group [get_clocks  {ADC1_CLK ADC1_FRM} ] 
  
  
  
# Пример был такой
#create_clock –period $_period –name CLK1x [get_ports clkin]
#set_input_delay -clock CLK1X -max [expr $_period / 2 – 0.4] din
#set_input_delay -clock CLK1X -min 0.2 din -add_delay
#set_input_delay -clock CLK1X -max [expr $_period / 2 – 0.4] din -add_delay -clock_fall
#set_input_delay -clock CLK1X -min 0.2 din -add_delay -clock_fall
  

 

[Kronac 0]

Недавно воевал с этим же цапом, правда на XILINX... натерпелся я от него конечно.. У меня было 4 таких ЦАПа (8 каналов). В Xilinx для управления задержками используется определённая мегафункция "IDELAYE3". Устанавливается она на вход DATA и FRAME и двигает данные и фрейм относительно опорного клока. Я наивно полагал, что задав один раз правильные значения, система будет стабильно работать. На практике же оказалось, что кристал огромный, а загрузка ПЛИС небольшая. От компиляции к компиляции элементы по кристалу раскидывало так, что у меня от прошивки к прошивке работали то одни, то другие каналы. Иногда от нагрева вылетали некоторые каналы в процессе работы.. Иногда просто клок вставал не в то место и данные терялись.. Пришлось городить механизм калибровки, при котором процессор через регистры подставлял разные задержки до тех пор, пока канал не начнёт принимать данные верно. Могу только сказать, что задержки для данных и фрейма я в итоге ставил одинаковые. По Quartus, к сожалению, ничего подсказать не смогу по данной теме, могу только пожелать удачи.

[Digi 0]

Сейчас пытаюсь всё-же разобраться, как влияют set_input_delay и set_max_delay  на времянки. Пока не понял. 

У меня на плате тоже 4 АЦП. Дорожки выровнены по длине с точностью 0,5мм. Ради интереса попробовал завести только один таккт и фрейм с первого канала на все приёмники. Работает нормально, кроме одной микросхемы.  Но это не дело.

 

Кстати пробовал тайминги прописать из примера этой корки и FAST_RESGISTERS тоже включил. Не помогло.

Еще меня наводит на мысль то, что включив FAST_REGISTERS , timequest игнорирует задание каких либо задежек по входным  линиям данных. Так ли это ?

 

[Flip-fl0p 4]

Я бы вообще забил на констрейны. Я бы загнал АЦП в тестовый режим. И по тестовым паттернам откалибровался в центр окна данных. А потом бы просто выровнял каналы АЦП. 

Автомат калибровки я скидывал: https://electronix.ru/forum/applications/core/interface/file/attachment.php?id=127214 Правда он для DVI, но сути не меняет. Его легко под себя переделать.

[Digi 0]

19 minutes ago, Flip-fl0p said:

Я бы вообще забил на констрейны. Я бы загнал АЦП в тестовый режим. И по тестовым паттернам откалибровался в центр окна данных. А потом бы просто выровнял каналы АЦП. 

Автомат калибровки я скидывал: https://electronix.ru/forum/applications/core/interface/file/attachment.php?id=127214 Правда он для DVI, но сути не меняет. Его легко под себя переделать.

Снимаю шляпу за проделанную работу и хорошее описание. Думаю для моих задач это круто будет. К тому же повторяемость есть. Нужно только подвинуть некоторые каналы. И PLL не хотелось бы использовать.

[Flip-fl0p 4]

2 часа назад, Digi сказал:

Снимаю шляпу за проделанную работу и хорошее описание. Думаю для моих задач это круто будет. К тому же повторяемость есть. Нужно только подвинуть некоторые каналы. И PLL не хотелось бы использовать.

Не уверен. Но вроде в Altera были delay_chain на входных ножках. Хотя в даташите было написано, что для нахождения центра "окна" их применять нельзя. Но а вдруг ? 

А почему ну хотите PLL использовать. Если это позволит решить Вашу задачу, то почему бы и да ?)

 

[Digi 0]

38 minutes ago, Flip-fl0p said:

А почему ну хотите PLL использовать. Если это позволит решить Вашу задачу, то почему бы и да ?)

Если это делать по правильному, то нужно 8 CLK.  У PLL нет такого количества выходов. К тому же всё равно придётся описывать времянки FRAME.  Поэтому хотелось бы разобраться с правильным описанием времянок.

 

[litv 0]

Проверьте внимательно ноги, на которые заведены сигналы. Работают ли они на такой большой частоте?

Бился как-то с похожей проблемой (правда, у альтеры). Оказалось, что шина АЦП была заведена на специфичные ножки ПЛИС, которые не могут в большие частоты в режиме user i/o. Могу наврать, но вроде это были ноги DQ/DQS, которые заводятся на memory controller и так же могут быть использованы как пользовательские вводы-выводы. (это nice_vladi советовал)

[Digi 0]

Если я всё правильно понял, то Report Path  показывает путь сигнала от вывода м/с до регистра. В данном случае я смотрю путь от вывода данных до первого регистра, работающего на CLK (400 МГц). Задержка составила 1,515 нс. На всех каналах порядок примерно такой же. CLK приходят на выделенные ноги и данные на выводы DQ/DQS.

На второй картинке я смотрю Report Path от CLK. Но не пойму, почему он составляет 4.4 нс. Я правильно понимаю, что путь сигнала ADC1_CLK  от вывода до входа регистра ddio.clk составляет 4.4 нс ?

На последнем скрине показаны задержки сигнала от ADC*_CLK до одного из входных регистров. Так как время получается разное, то это и объясняет, почему эта конструкция не работает как ожидалось. 

Посмотрел путь сигнала FRAME - он у для всех равен и составляет около 7.5 нс.

 

Это опять же при условии, что я смотрю именно то что нужно и правильно интерпретировал результаты.

 

 

PS: А так это и есть Альтера. По поводу частотки должно быть всё нормально, так как часть каналов работает стабильно и на 250 МГц. Так же если для всех использовать только CLK и FRAME от первого канала, то ситуация значительно лучше.

 

[des00 25]

32 minutes ago, Digi said:

На последнем скрине показаны задержки сигнала от ADC*_CLK до одного из входных регистров. Так как время получается разное, то это и объясняет, почему эта конструкция не работает как ожидалось. 

Посмотрел путь сигнала FRAME - он у для всех равен и составляет около 7.5 нс.

пин то AC16, судя по распиновке это DQS пин. @litv ответил.

1 hour ago, litv said:

Проверьте внимательно ноги, на которые заведены сигналы. Работают ли они на такой большой частоте?

Бился как-то с похожей проблемой (правда, у альтеры). Оказалось, что шина АЦП была заведена на специфичные ножки ПЛИС, которые не могут в большие частоты в режиме user i/o. Могу наврать, но вроде это были ноги DQ/DQS, которые заводятся на memory controller и так же могут быть использованы как пользовательские вводы-выводы. (это nice_vladi советовал)

плату в переразводку или как то по другому увязывать АЦП

[Digi 0]

12 minutes ago, des00 said:

пин то AC16, судя по распиновке это DQS пин. @litv ответил.

Да. Это такты от второго канала микросхемы. Они точно такие же как и от первого. И при подключении на DDIO второго канала, тактов от первого канала, картина становится лучше. Что собственно и подтверждают времянки.

 

 

[Digi 0]

Есть ли в TimeQuest возможность посмотреть графически, как я описал входные сигналы ? 

Например в моём пером описании я задал virtual_clock, по которому выставляются данные ADC*_D[*]. ADC*_CLK - фактический сигнал CLOCK и ADC*_FRM - FRAME. Можно ли увидеть, как эти сигналы будут приходить на входы элементов ? Если да, то как ?

PS: Удалось прописать требуемые задержки для входных сигналов. В результате АЦП работает в QDR режиме, в диапазоне частот от 170 до 215 МГц. Требуемая 200 МГц. Такой узкий диапазон связан с тем, что сигнал FRM имеет задержку около 6 нс и защелкивает данные со смещением на такт. С чем это связано, пока не разобрался.

[Digi 0]

Продолжаю причёсывать проект и разбираться с TimeQuest. Чтобы не плодить темы, продолжу здесь.

  Сейчас описываю входной порт DDR Link порта. 

Кусок кода входного блока выглядит так:
 

  reg [11:0] 	 datain_pos;
  reg [11:0] 	 datain_neg;

  always @(posedge P1_CLKO or negedge rst_n)
    if (~rst_n)
      datain_pos <= 12'b0;
    else
      datain_pos <= {P1_DO, datain_pos[11:4]};

  always @(negedge P1_CLKO or negedge rst_n)
    if (~rst_n)
      datain_neg <= 12'b0;
    else
      datain_neg <= {P1_DO, datain_neg[11:4]};

  

Входной clock описал так:
create_clock -name {P1_CLKO}     -period 5.0 -waveform { 0.000 2.5 } [ get_ports P1_CLKO]

Задержка P1_CLKO 7.2ns

report_path -from P1_CLKO -npaths 32 -panel_name {Report Path}
Report Path: Found 32 paths. Longest delay is 7.211
    -from [get_keepers {P1_CLKO}]
    -panel_name "Report Path"

Задержка P1_DO[0]   3.8 ns
report_path -from P1_DO[0] -npaths 32 -panel_name {Report Path}

 

Теперь если в *.sdc прописать ,  то задержка P1_DO[*] становится примерно 10.4 ns

# CLKO - 7.18 DO - 10.44
set_input_delay -max -clock [get_clocks {P1_CLKO}]  0.65 [get_ports {P1_DO[*]}]
set_input_delay -min -clock [get_clocks {P1_CLKO}]  0.55 [get_ports {P1_DO[*]}]
set_input_delay -add_delay -max -clock_fall -clock [get_clocks {P1_CLKO}]  0.65 [get_ports {P1_DO[*]}]
set_input_delay -add_delay -min -clock_fall -clock [get_clocks {P1_CLKO}]  0.55 [get_ports {P1_DO[*]}]

 

Если прописать ,  то задержка P1_DO[*] становится примерно 7,4 ns. Всё начинает работать как положено, но вылезают слаки по P1_CLKO на -2,3 нс

# CLKO - 7.18 DO - 7.4  Warning CLKO
set_input_delay -max -clock [get_clocks {P1_CLKO}]  2.65 [get_ports {P1_DO[*]}]
set_input_delay -min -clock [get_clocks {P1_CLKO}]  2.55 [get_ports {P1_DO[*]}]
set_input_delay -add_delay -max -clock_fall -clock [get_clocks {P1_CLKO}]  2.65 [get_ports {P1_DO[*]}]
set_input_delay -add_delay -min -clock_fall -clock [get_clocks {P1_CLKO}]  2.55 [get_ports {P1_DO[*]}]
 

Как для моего случая правильно прописать констрейны ? И почему возникает большая задержка в 10 нс при уменьшении параметра ?

 

 

[Digi 0]

Проект потихоньку разрастается и работа с АЦП начинает напрягать. При небольших изменения проекта начинает разваливаться по времянкам входная часть.  Решил снова заняться правильным описанием констрейнов.

Отключил все входные задержки. Описал констрейны так:

set adc_data_period 2.500
set adc_frame_preiod [expr $adc_data_period * 2]

set data_delay  1.5


create_clock -name {ADC1_CLK} 			-period $adc_data_period   [get_ports  {ADC1_CLK}]   -waveform { 0.625 1.875 }
create_clock -name {ADC1_FRM} 			-period $adc_frame_preiod  [get_ports {ADC1_FRM}] 
  
set_clock_groups -exclusive -group [get_clocks  {ADC1_CLK } ] 
set_clock_groups -exclusive -group [get_clocks  {ADC1_FRM } ]   
  
set_input_delay 						-clock ADC1_CLK $data_delay  [get_ports {ADC1_D[*]}] 
set_input_delay -add_delay -clock_fall -clock ADC1_CLK $data_delay  [get_ports {ADC1_D[*]}]

  

Но Quartus почему то сообщает о слаках на ADC1_CLK и тем не менее сам ставит задержку в буфере ADC1_D[*] на 33.

 

прописываю set_data_delay  -2.5 вижу следующую картину: задержку в буфере Quartus выкрутил на максимум, слаки в пределах -1

 

Мне не понятна его логика работы. Если данные должны прийти раньше, то задержку нужно уменьшать, а он пытается её наоборот, увеличить.

Или я что я не так описал и как исправить ситуацию ?

Как ещё правильно описать сигнал половинной частоты ADC1_FRM ?  Напомню, АЦП работает в режиме QDR

Надеюсь я не единственный, кто использовал QDR режим совместно с АЦП, может есть примеры ?