Digi

Который месяц бьюсь уже над проблемой подружить похожую 8ми канальную плату c ADS42LB49 и ПЛИС Intel Cyclone 10. При изменении проекта, слетают времянки и приходится тратить очень много времени на приведение проекта в чувства. Слетают времянки. Может направите на путь истинный, как и через какие элементы правильно подключить АЦП в QDR режиме и как это всё законстрейнить ?

С обратным знаком вроде выглядит как надо. Но IO DELAY всёравно надо ставить руками, иначе он угоняет его в максимум. На работоспособность не проверял. SDC такой 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 input_clock <clock_name>; # Name of input clock set input_clock_period 2.500; # Period of input clock (full-period) set dv_bre 0.300; # Data valid before the rising clock edge set dv_are 0.300; # Data valid after the rising clock edge set dv_bfe 0.300; # Data valid before the falling clock edge set dv_afe 0.300; # Data valid after the falling clock edge # Input Delay Constraint set_input_delay -clock ADC1_CLK -max -[expr $input_clock_period/2 - $dv_bfe] [get_ports {ADC1_D[*]}]; set_input_delay -clock ADC1_CLK -min -$dv_are [get_ports {ADC1_D[*]}]; set_input_delay -clock ADC1_CLK -max -[expr $input_clock_period/2 - $dv_bre] [get_ports {ADC1_D[*]}] -clock_fall -add_delay; set_input_delay -clock ADC1_CLK -min -$dv_afe [get_ports {ADC1_D[*]}] -clock_fall -add_delay;

Если я правильно понял, то эта запись указывает, что всё что тактируется ADC1_CLK , не должно анализироваться с другими клоками. Или она совсем не то означает ? У меня большой проект и в нем много разных тактов и если не писать такой констрейн, то время компиляции возрастает до полутора часов на мощном компе. Если такты я выделяю в группы и в проекте выполняю межклоковую синхронизацию необходимых данных, то время компиляции сокращается до 20 минут и исчезают различные глюки, связанные с запаздываниями сигналов. то в отчете идет привязка к правильному клоку, но только проблема в Т.е. где-то неточность в описании констрейнов на входах ПЛИС? Да, правильно. # Center-Aligned Double Data Rate Source Synchronous Inputs # # For a center-aligned Source Synchronous interface, the clock # transition is aligned with the center of the data valid window. # The same clock edge is used for launching and capturing the # data. The constraints below rely on the default timing # analysis (setup = 1/2 cycle, hold = 0 cycle). # # input ____________________ # clock _____________| |_____________ # | | # dv_bre | dv_are dv_bfe | dv_afe # <------>|<------> <------>|<------> # _ ________|________ ________|________ _ # data _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_ # #set input_clock <clock_name>; # Name of input clock #set input_clock_period 2.500; # Period of input clock (full-period) #set dv_bre 0.300; # Data valid before the rising clock edge #set dv_are 0.300; # Data valid after the rising clock edge #set dv_bfe 0.300; # Data valid before the falling clock edge #set dv_afe 0.300; # Data valid after the falling clock edge #set input_ports {ADC1_D[*] ADC2_D[*] ADC3_D[*] ADC4_D[*]}; # List of input ports # ## Input Delay Constraint #set_input_delay -clock ADC1_CLK -max [expr $input_clock_period/2 - $dv_bfe] [get_ports {ADC1_D[*]}]; #set_input_delay -clock ADC1_CLK -min $dv_are [get_ports {ADC1_D[*]}]; #set_input_delay -clock ADC1_CLK -max [expr $input_clock_period/2 - $dv_bre] [get_ports {ADC1_D[*]}] -clock_fall -add_delay; #set_input_delay -clock ADC1_CLK -min $dv_afe [get_ports {ADC1_D[*]}] -clock_fall -add_delay; Вот такое описание начинает влиять на IO DELAY но с ними задержки, которые устанавливает компилятор становятся неадекватными.

В примерах от Altera так и есть, его привязывают к условному нулю. У меня фактически тоже так и есть. Я ADC*_CLK указываю что он со сдвигом на 90 град, а ADC*_FRM и данные ADC*_D (которые описываю virual_clock) и начинаются от 0. create_clock -name virtual_clock_adc -period 2.500 create_clock -name {ADC2_CLK} -period 2.500 [get_ports {ADC1_CLK}] -waveform { 0.625 1.875 } create_clock -name {ADC1_FRM} -period 5.000 [get_ports {ADC1_FRM}]

Я считал, что я задаю сигнал, который соответствует моментам установки данных на АЦП, т.е. те, которые приходят на входы ADC*_D[*] В файле верхнего уровня он заходит на вход D_CLK модуля ADS42LB69 (в комментарии я написал сигналы, которые в него приходят из верхнего уровня). Таких модулей там 8 штук, соответственно сигналы от каждого канала АЦП содержат х, где х - цифра от 1 до 8. ADCx_CLK -> ADC1_CLK ,ADC2_CLK ... ADC8_CLK

Может это конечно и самообман, но основная задача - запустить опытный образец на том что есть и параллельно разобраться, как должны работать констрейны. Меня вполне устраивает работа того что есть, но не устраивает то что при изменении проекта может не зарабоать. Пока что, то что я пытаюсь задавать никак не влияет на анализ и разводку. Или я не правильно задаю или не то ожидаю увидеть. Например из моего примера. Я задал virtual_clock и относительно него задал input_delay. После анализа я Ожидаю увидеть ADC1_CLK, который будет защёлкивать данные синхронные с Virtual Clock. Но этого не происходит. При анализе почему то вообще нет ADC1_CLK. Если я задаю input_delay относительно ADC1_CLK, то он его анализирует, при этом ожидает данные относительно нулевой шкалы + тот delay, который я ему задал.... вроде как. Дальше мне совсем непонятно его поведение. Он показывает, что данные приходят слишком поздно, но ко всему этому он у IO порта выкручивает задержку до максимума. Если задержку прописать руками, то всё у него складывается и слаков нет. Зачем он увеличивает задержку, когда её наоборот нужно уменьшать ?

Да, клоки действительно заведены не туда куда необходимо. Но тем не менее, вручную удается выставить необходимые задержки, чтобы это всё работало. При правильных задержках и тестовый паттерн принимается нормально и сигнал нормальный. А вот по поводу констрейнов, я считал, что Quartus будет стараться разводить так, чтобы выполнялись необходимые условия, и сам же установить необходимые задержки на буферах IO (в другом проекте, он их ставит, правда констрейны тоже неправильно прописаны и проект не работает) . Я даже согласен выставить вручную задержки один раз, но чтобы при изменениях проекта их не приходилось больше менять. А так я даже не вижу, что не попадаю в нужные мне времянки, ADC_CLK не анализируется никак.... Оценить работоспособность проекта могу только лишь посмотрев на Path report. В том что я выложил, принципиальные ошибки какие либо есть ? Почему он их игнорирует ? Как правильно описать set_input_delay, для случая когда данные сдвинуты от клока на 90 град ? Вот так ? max_delay = unit_interval - tsu min_delay = th или max_delay = tco min_delay = - tco (tco считать примерно равной tsu)

Бьюсь с выравниванием времянок в QDR интерфейсе, пока безуспешно. Прошу помощи. Сделал проект в котором реализован приёмник двух каналов АЦП по QDR интерфейсу. И выходы с приемников АЦП поключены к SignalTap, который тактируется ADC1_FRM. АЦП формирует удвоенную ADC_CLK, её фронты приходятся на середину данных. (Т.е ADC_CLK сдвинута относительно данных на 90 град) Тактовая частота ADC_FRM приходится на фронт данных. Констрейны прописал по описанию из AN433. После компиляции вижу в TimeQuest следующую картину: Клоки Почему то только анализирует ADCx_FRM. Почему нет ADCx_CLK ? Setup ADC2_FRM И самое, то из-за чего не работает и пытаюсь разобраться с констрейнами - это то что для данных и клоков получаются разные времянки прохождения сигнала до триггера. report_path -from ADC*_CLK -npaths 128 -panel_name {Report Path} ADC1_CLK - 4.4 нс, а ADC2_CLK - 8.6 нс и соответственно тоже самое и для данных ADC1_D* - 1.5 нс, ADC2_D* - 1.5 нс Ниже привожу код приемника QDR и SDC файл. В принципе я могу эти задержки выровнять при помощи настройки DelayChain но при изменениях в проекте базовые времена ADC*_CLK изменяются, и приходится настраивать заново. Помогите правильно прописать констрейны, чтобы при перекомпиляции не слетали времянки. // ПРИЕМНИК ДАННЫХ С АЦП module ADS42LB69 ( reset, // (in) reset clk, // (out) data clk d_out, // (out) data output // --------------chip interface ---------------------// D_CLK, // (in) QDR data clk FRAME, // (in) QDR data frame D // (in) QDR data ); input reset; input D_CLK; // ADCx_CLK input FRAME; // ADCx_FRM input [3: 0] D; // ADCx_D[] output clk; output reg [15: 0] d_out; wire [15: 0] gpio_d; gpiox4_in gpio_inst ( .aclr (sys_rst), .ck_fr (D_CLK), .ck_hr (FRAME), .pad_in (D), .dout ({gpio_d[3: 0], gpio_d[7: 4], gpio_d[11: 8], gpio_d[15: 12]}) ); assign clk = FRAME; always @(negedge FRAME) d_out[15:0] = gpio_d[15:0]; endmodule set_time_format -unit ns -decimal_places 3 derive_clock_uncertainty set adc_data_period 2.500 set adc_frame_preiod [expr $adc_data_period * 2] # max_delay = unit_interval - tsu # min_delay = th #set_input_delay -max [expr <unit interval> - <setup time>] -clock [get_clocks input_clock] -add_delay [get_ports data_in] #set_input_delay -min <hold time> -clock [get_clocks input_clock] -add_delay [get_ports data_in] #set adc_tsu 0.31 #set adc_th 0.29 // Так же пробовал ставить max 0.2 min -0.2 Эффекта не заметил set max_data_delay 1.05 set min_data_delay 0.2 create_clock -name virtual_clock_adc -period $adc_data_period create_clock -name {ADC1_CLK} -period $adc_data_period [get_ports {ADC1_CLK}] -waveform { 0.625 1.875 } create_clock -name {ADC2_CLK} -period $adc_data_period [get_ports {ADC2_CLK}] -waveform { 0.625 1.875 } create_clock -name {ADC1_FRM} -period $adc_frame_preiod [get_ports {ADC1_FRM}] create_clock -name {ADC2_FRM} -period $adc_frame_preiod [get_ports {ADC2_FRM}] set_input_delay -clock [ get_clocks virtual_clock_adc] -min $min_data_delay [get_ports {ADC1_D[*]}] set_input_delay -clock [ get_clocks virtual_clock_adc] -max $max_data_delay [get_ports {ADC1_D[*]}] set_input_delay -clock [ get_clocks virtual_clock_adc] -min $min_data_delay [get_ports {ADC1_D[*]}] -add_delay -clock_fall set_input_delay -clock [ get_clocks virtual_clock_adc] -max $max_data_delay [get_ports {ADC1_D[*]}] -add_delay -clock_fall set_input_delay -clock [ get_clocks virtual_clock_adc] -min $min_data_delay [get_ports {ADC2_D[*]}] set_input_delay -clock [ get_clocks virtual_clock_adc] -max $max_data_delay [get_ports {ADC2_D[*]}] set_input_delay -clock [ get_clocks virtual_clock_adc] -min $min_data_delay [get_ports {ADC2_D[*]}] -add_delay -clock_fall set_input_delay -clock [ get_clocks virtual_clock_adc] -max $max_data_delay [get_ports {ADC2_D[*]}] -add_delay -clock_fall set_false_path -setup -fall_from [get_clocks virtual_clock_adc] -rise_to [get_clocks ADC1_CLK] set_false_path -setup -rise_from [get_clocks virtual_clock_adc] -fall_to [get_clocks ADC1_CLK] set_false_path -hold -rise_from [get_clocks virtual_clock_adc] -rise_to [get_clocks ADC1_CLK] set_false_path -hold -fall_from [get_clocks virtual_clock_adc] -fall_to [get_clocks ADC1_CLK] set_false_path -setup -fall_from [get_clocks virtual_clock_adc] -rise_to [get_clocks ADC2_CLK] set_false_path -setup -rise_from [get_clocks virtual_clock_adc] -fall_to [get_clocks ADC2_CLK] set_false_path -hold -rise_from [get_clocks virtual_clock_adc] -rise_to [get_clocks ADC2_CLK] set_false_path -hold -fall_from [get_clocks virtual_clock_adc] -fall_to [get_clocks ADC2_CLK] set_clock_groups -exclusive -group [get_clocks {ADC1_CLK } ] set_clock_groups -exclusive -group [get_clocks {ADC2_CLK } ] set_clock_groups -exclusive -group [get_clocks {ADC1_FRM } ] set_clock_groups -exclusive -group [get_clocks {ADC2_FRM } ]

Пытаюсь реанимировать данного мишку FSL-6. Выгорел аттенюатор. Восстановил схему. Как узнать, какие номиналы резисторов там были ? (На схеме обозначены знаком вопроса) На фото, из этой темы два параллельных резистора слева никуда не подключены. Они по 100 Ом каждый. По остальной маркировке не могу разобрать. Оставшиеся обгоревшие резисторы имеют следующие остаточные значения: Слева от реле 83 Ом, и скорее всего ему параллельно был припаян резистор на 100 Ом параллельные справа от реле вверху: 39 Ом и 43 Ом, справа внизу - в обрыве... (Измерял сняв с платы)

Буду очень надеяться, что косяк я всё-же нашел. И как обычно нашлась не проинициализированная переменная. Всем спасибо.

Чистку провёл, теперь все переменные, объявляемые при создании функции, теперь имеют начальные значения. Проект представляет из себя письмо Дяди Фёдора домой )))). Код просто ужасен.... Поэтому не этично будет выкладывать этот кошмар большого объёма ) Cube_MX не использую. Использую SPL. FreeRTOS пробовал изменять размер стека, поведение меняется. Но есть ещё отладочная информация, которая сообщает свободный размер, запас Попробую включить. .

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

Ожидал одинакового поведения при шаговой отладке и работе проца )) В том то и дело, что не используется. Более вероятно, что что-то его взводит....

Пытаюсь перетащить код с STM32F1 на F4 и тут у меня возникают проблемы с работоспособностью кода. Понимаю, что где то косяк у меня, но найти не получатся. Дело в том что при отладке по шагам всё работает правильно, а при запуске - происходят не ожидаемые события. Как пример функция инициализации портов. Если ходить по шагам, то всё работает. А если запустить, то переписывала те биты, которые не должна была бы. void UART_ConfigGPIO(GPIO_TypeDef* GPIO, uint16_t InpPin, uint16_t OutPin) { GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin = InpPin; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; GPIO_Init(GPIO, &GPIO_InitStructure); ... Т.е. GPIO_InitStructure содержала ещё GPIO_Speed, GPIO_OType, GPIO_PuPd, которые я должен был проинициализировать. Но почему то при ходьбе по шагам в них были нули, а при запуске - значение, которое выходило за допустимые. Собственно вопрос. Сейчас, в зависимости от размещения кода, прога сваливается в WWDG_IRQHandler (). Причем если вставить до запуска RTOS какие нибудь не значащие функции (например задержку, или зажечь свтодиодик), то удается заставить её работать без сбоев. Если поставить брекпоинт на vTaskStartScheduler(); войти в функцию по шагам и потом продолжить выполнение, то тоже всё работает. Какие есть способы поиска этого глюка ?

Проект потихоньку разрастается и работа с АЦП начинает напрягать. При небольших изменения проекта начинает разваливаться по времянкам входная часть. Решил снова заняться правильным описанием констрейнов. Отключил все входные задержки. Описал констрейны так: 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 режим совместно с АЦП, может есть примеры ?

Спасибо огромное. Еще нашел вот такой способ, может кому пригодится. MEMORY { rom_boot (rx) : ORIGIN = 0x08000000, LENGTH = 0x0001000 eeprom (r) : ORIGIN = 0x08008000, LENGTH = 0x0004000 main_rom (rx) : ORIGIN = 0x08010000, LENGTH = 0x0020000 ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00010000 } SECTIONS { /* The startup code goes first into FLASH */ .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) /* Startup code */ KEEP(*(.fw_info)) . = ALIGN(4); } >rom_boot /* Flash EEPROM arrea */ /* .flash_eeprom (NOLOAD) : { . = ALIGN (0x08000); KEEP(*(.flash_page_0*)) . = ALIGN (0x04000); KEEP(*(.flash_page_1*)) . = ALIGN (0x04000); } >eeprom */ .text : { *(.text*) KEEP(*(.init)) KEEP(*(.fini)) /* .ctors */ *crtbegin.o(.ctors) .......... } > main_rom

Перетягиваю прогу на STM32F405, среда разработки TrueStudio. Мне необходимо в Sector 3 разместить пользовательские данные (типа EEPROM). Со стороны программы работа с ними осуществляется как областью памяти. Проблема возникла в том, что я не пойму как прописать в *.ld файле секцию .isr_vector по адресу 0x800_0000 а остальные - начиная с адреса 0x801_0000. Подскажите, как это прописать ?

Продолжаю причёсывать проект и разбираться с 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 нс при уменьшении параметра ?

10 мс ждал )))) Ещё поковыряю, 100% что то не так накодил ) Само собой. Да и код написан так, что доступ к драйверу разграничивается семафорами.

Я пробовал выводить все флаги до передачи и потом через некоторое время после передачи и везде считывал нули. Считывал так же как и в примере. Хотя очень вероятно, что где то что то не учёл... Хотел привести, но похоже я где то запутался. ))) Распутаюсь, думаю вопрос снимется ))

Передачу (DMA_RD) запустил, спасибо огромное за помощь. Думаю и DMA_WR тоже заработает. Но не пойму, почему не выставляются флаги завершения операции. А почему во всех примерах заполняют сразу 128 дескрипторов одним и тем же значением, за исключением номера ? По идее необходимо заполнить только следующий дескриптор, от текущего ?

Продолжаю ковырять DMA. Возникли непонятки с описанием регистров Имею в наличии AN829 (который кстати, если его прошить, не запустился не даёт загрузиться Linux загрузчику. Причём Windows стартует нормально.), и несколько описаний Нашел на интеловском форуме пример описания адресов, которое по смыслу вроде правильное. Система В исходниках AN829 написано совершенно не так как советуют на форуме, (да ещё и с опечаткой в исходниках вместо RD_CTRL_BUF_BASE_HI написали WR_CTRL_BUF_BASE_HI ) Но суть не в этом, а в том что адреса в QSys прописаны как 0x8000_0000 для RD и 0x8000_2000 для WR, а в define драйвера прописаны значения, которые указывают на верхний и нижний граничный адрес. В описании от Intel тоже я не сильно понял, написано что сначала нужно прописать адрес по смещению 0x000c, то есть после записи самого себя. И а регистр 0x0008 после того как он же будет прописан. Ну ещё как вариант я сильно туплю и не дружу с английским. Причём в примере AN829 пишется сначала LOW, затем HIGH. . Сам я пробовал делать по разному, но DMA обмен не стартует. Флаги завершения передачи не выставляются. Первый раз читался как 0xff , после - то что записал. Программировал только один канал, на запись из host в avalon. Соответственно для DMA контроллера использовал регистры RD. К контроллеру и шине подключена однопортовая on-chip память одновременно к BAR2, к dma_wr_master и dma_rd_master. Так собственно вопрос к прошедшим это, какие должны быть адреса ? И кто первым должен записаться ?

Есть ли в TimeQuest возможность посмотреть графически, как я описал входные сигналы ? Например в моём пером описании я задал virtual_clock, по которому выставляются данные ADC*_D[*]. ADC*_CLK - фактический сигнал CLOCK и ADC*_FRM - FRAME. Можно ли увидеть, как эти сигналы будут приходить на входы элементов ? Если да, то как ? PS: Удалось прописать требуемые задержки для входных сигналов. В результате АЦП работает в QDR режиме, в диапазоне частот от 170 до 215 МГц. Требуемая 200 МГц. Такой узкий диапазон связан с тем, что сигнал FRM имеет задержку около 6 нс и защелкивает данные со смещением на такт. С чем это связано, пока не разобрался.

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

Если я всё правильно понял, то 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 от первого канала, то ситуация значительно лучше.