Digi 0 24 июня, 2021 Опубликовано 24 июня, 2021 · Жалоба Бьюсь с выравниванием времянок в 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 } ] Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nice_vladi 1 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 12 hours ago, Digi said: ... Помогите правильно прописать констрейны, чтобы при перекомпиляции не слетали времянки. ... Встречался с подобной проблемой - сигналы были заведены на низкоскоростные ноги ПЛИС, и все танцы с бубном вокруг констрейнов ни к чему не приводили. Поэтому сначала надо посмотреть, на какие ноги заведены сигналы. Кстати, а тестовый паттерн верно принимается? Нет ошибок? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба Да, клоки действительно заведены не туда куда необходимо. Но тем не менее, вручную удается выставить необходимые задержки, чтобы это всё работало. При правильных задержках и тестовый паттерн принимается нормально и сигнал нормальный. А вот по поводу констрейнов, я считал, что 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) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nice_vladi 1 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 3 hours ago, Digi said: ... вручную удается выставить необходимые задержки, чтобы это всё работало... Тоже руками крутил delay в IO портах. И тоже *иногда* собиралось так, что паттерн передавался без ошибок. После кучи убитого времени пришел к тому, что всё это самообман, и "рабочие" сборки - просто удачно разложенные регистры, чисто случайно. Но, может быть, у вас получится чего-то добиться. Будет интересно прочесть про рабочий вариант. ЗЫ. А тестовый паттерн сколько времени проверяли? Сколько бит тестового паттерна принимается подряд без ошибок? 10^5? 10^9? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба Может это конечно и самообман, но основная задача - запустить опытный образец на том что есть и параллельно разобраться, как должны работать констрейны. Меня вполне устраивает работа того что есть, но не устраивает то что при изменении проекта может не зарабоать. Пока что, то что я пытаюсь задавать никак не влияет на анализ и разводку. Или я не правильно задаю или не то ожидаю увидеть. Например из моего примера. Я задал virtual_clock и относительно него задал input_delay. После анализа я Ожидаю увидеть ADC1_CLK, который будет защёлкивать данные синхронные с Virtual Clock. Но этого не происходит. При анализе почему то вообще нет ADC1_CLK. Если я задаю input_delay относительно ADC1_CLK, то он его анализирует, при этом ожидает данные относительно нулевой шкалы + тот delay, который я ему задал.... вроде как. Дальше мне совсем непонятно его поведение. Он показывает, что данные приходят слишком поздно, но ко всему этому он у IO порта выкручивает задержку до максимума. Если задержку прописать руками, то всё у него складывается и слаков нет. Зачем он увеличивает задержку, когда её наоборот нужно уменьшать ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Yuri124 4 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 18 hours ago, Digi said: анализирует ADCx_FRM Quote выходы с приемников АЦП поключены к SignalTap, который тактируется ADC1_FRM предположу - это идет анализ разводки сигналтапа. 41 minutes ago, Digi said: задал virtual_clock и относительно него задал input_delay а с каким реально сигналом связан этот виртуальный клок? Я что-то не нашел (может - плохо смотрел...). 43 minutes ago, Digi said: При анализе почему то вообще нет ADC1_CLK а где его подключение? - тоже не нашел... Не могли напутать с обозначениями клоков - в тексте программы и в тексте констрейнов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 22 минуты назад, Yuri124 сказал: а с каким реально сигналом связан этот виртуальный клок? Я что-то не нашел (может - плохо смотрел...). Я считал, что я задаю сигнал, который соответствует моментам установки данных на АЦП, т.е. те, которые приходят на входы ADC*_D[*] 24 минуты назад, Yuri124 сказал: а где его подключение? - тоже не нашел... Не могли напутать с обозначениями клоков - в тексте программы и в тексте констрейнов? В файле верхнего уровня он заходит на вход D_CLK модуля ADS42LB69 (в комментарии я написал сигналы, которые в него приходят из верхнего уровня). Таких модулей там 8 штук, соответственно сигналы от каждого канала АЦП содержат х, где х - цифра от 1 до 8. ADCx_CLK -> ADC1_CLK ,ADC2_CLK ... ADC8_CLK Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Yuri124 4 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 19 minutes ago, Digi said: Я считал, что я задаю сигнал, который соответствует моментам установки данных на АЦП но ведь этот виртуальный клок чисто условно привязан к нулю временной шкалы, надо его как-то привязать к реальным клокам, которые имеют задержки при распространении по кристаллу, иначе, как я понимаю, время прихода данных ни к чему не привязано... И тем более Вы отменяете анализ между реальными клоками и этим виртуальным 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] 23 minutes ago, Digi said: В файле верхнего уровня он заходит на вход D_CLK модуля ADS42LB69 (в комментарии я написал сигналы, которые в него приходят из верхнего уровня) Понял, спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 45 минут назад, Yuri124 сказал: но ведь этот виртуальный клок чисто условно привязан к нулю временной шкалы, В примерах от 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}] Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Yuri124 4 25 июня, 2021 Опубликовано 25 июня, 2021 (изменено) · Жалоба 2 hours ago, Digi said: Я задал virtual_clock и относительно него задал input_delay. После анализа я Ожидаю увидеть ADC1_CLK, который будет защёлкивать данные синхронные с Virtual Clock. Но этого не происходит. может быть дело в этом: set_clock_groups -exclusive -group [get_clocks {ADC1_CLK } ] Я правильно понимаю - когда Вы 2 hours ago, Digi said: задаю input_delay относительно ADC1_CLK, то он его анализирует, при этом ожидает данные относительно нулевой шкалы + тот delay, который я ему задал.... вроде как. то в отчете идет привязка к правильному клоку, но только проблема в 2 hours ago, Digi said: совсем непонятно его поведение. Он показывает, что данные приходят слишком поздно, но ко всему этому он у IO порта выкручивает задержку до максимума. Если задержку прописать руками, то всё у него складывается и слаков нет. Зачем он увеличивает задержку, когда её наоборот нужно уменьшать ? Т.е. где-то неточность в описании констрейнов на входах ПЛИС? Изменено 25 июня, 2021 пользователем Yuri124 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба 16 минут назад, Yuri124 сказал: может быть дело в этом: set_clock_groups -exclusive -group [get_clocks {ADC1_CLK } ] Если я правильно понял, то эта запись указывает, что всё что тактируется ADC1_CLK , не должно анализироваться с другими клоками. Или она совсем не то означает ? У меня большой проект и в нем много разных тактов и если не писать такой констрейн, то время компиляции возрастает до полутора часов на мощном компе. Если такты я выделяю в группы и в проекте выполняю межклоковую синхронизацию необходимых данных, то время компиляции сокращается до 20 минут и исчезают различные глюки, связанные с запаздываниями сигналов. 21 минуту назад, Yuri124 сказал: Я правильно понимаю - когда Вы 3 часа назад, Digi сказал: задаю input_delay относительно ADC1_CLK, то он его анализирует, при этом ожидает данные относительно нулевой шкалы + тот delay, который я ему задал.... вроде как. то в отчете идет привязка к правильному клоку, но только проблема в 3 часа назад, Digi сказал: совсем непонятно его поведение. Он показывает, что данные приходят слишком поздно, но ко всему этому он у IO порта выкручивает задержку до максимума. Если задержку прописать руками, то всё у него складывается и слаков нет. Зачем он увеличивает задержку, когда её наоборот нужно уменьшать ? Т.е. где-то неточность в описании констрейнов на входах ПЛИС? Да, правильно. # 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 но с ними задержки, которые устанавливает компилятор становятся неадекватными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Yuri124 4 25 июня, 2021 Опубликовано 25 июня, 2021 (изменено) · Жалоба 33 minutes ago, Digi said: эта запись указывает, что всё что тактируется ADC1_CLK , не должно анализироваться с другими клоками. Да, поэтому я предполагаю - когда Вы привязываете входные сигналы к виртуальному клоку, то нет анализа их взаимодействия с реальным - но это только мое предположение, почему в этом случае отсутствует в отчетах нужная информация с ADC1_CLK... У меня подозрение, что нужно указывать знак минус (т.к. по отношению к данным клок находится в центре) - поэтому квартус пытается "дотянуть" данные с помощью неадекватной задержки до следующего фронта клока... https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/tafs/tafs/tcl_pkg_sdc_ver_1.5_cmd_set_input_delay.htm Изменено 25 июня, 2021 пользователем Yuri124 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Yuri124 4 25 июня, 2021 Опубликовано 25 июня, 2021 (изменено) · Жалоба Или, если привязывать сигналы на входах к виртуальному клоку - то потом добавлять этот клок в каждую группу set_clock_groups вместе с ADCх_CLK Изменено 25 июня, 2021 пользователем Yuri124 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 25 июня, 2021 Опубликовано 25 июня, 2021 · Жалоба С обратным знаком вроде выглядит как надо. Но 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; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 30 июня, 2021 Опубликовано 30 июня, 2021 · Жалоба Продолжаю разбираться с констрейнами. Создал новый проект, в котором кроме GPIO ничего нет. Описываю констрейны как указано в AN433 и снова получаю полную хрень. Вопросы: 1) как в этому случае должен описываться сигнал ADC1_FRM (half rate clock) ? 2) Почему квартус увеличивает задержку на линиях данных ADC1_D[*], когда её необходимо уменьшать ? 3) Какие методы ещё применить для анализа, на что посмотреть ? PS: проект так и не работает. Только вручную удаётся его заставить работать, отключив анализ клоков и данных. Во всех остальных случаях он разводить его так, что это все становится неработоспособным. Видимо что то не так описано. Кстати заметил, что в описании на GPIO half_rate_clk и full_rate_clk нарисованы с совпадающими фронтами а не смещенными на 90 град. У меня с АЦП они выходят смещенные. Сам код: module top ( // ADC1 input [3: 0] ADC1_D, input ADC1_CLK, input ADC1_FRM, input ADC1_OVR, output [7: 4] B_BUSo, output [3: 0] VPX_TX ); wire [15: 0] gpio_d; gpiox4_in gpio_inst ( .aclr (0), .ck_fr (ADC1_CLK), .ck_hr (ADC1_FRM), .pad_in (ADC1_D[3:0]), .dout ({gpio_d[3: 0], gpio_d[7: 4], gpio_d[11: 8], gpio_d[15: 12]}) ); assign {VPX_TX[3:0], B_BUSo[7:4]} = gpio_d[7:0] | gpio_d[15:8]; // Dummy output //-------------------------------------------------------------------------// //-------------------------------------------------------------------------// endmodule SDC файл: 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] set skew 0.3 create_clock -name virtual_clock -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 {ADC1_FRM} -period $adc_frame_preiod [get_ports {ADC1_FRM}] create_clock -name {ADC2_CLK} -period $adc_data_period [get_ports {ADC2_CLK}] -waveform { 0.625 1.875 } create_clock -name {ADC3_CLK} -period $adc_data_period [get_ports {ADC3_CLK}] -waveform { 0.625 1.875 } create_clock -name {ADC2_FRM} -period $adc_frame_preiod [get_ports {ADC2_FRM}] set_input_delay -max $skew -clock [get_clocks virtual_clock] [get_ports {ADC1_D[*]}] set_input_delay -max $skew -clock [get_clocks virtual_clock] -clock_fall [get_ports {ADC1_D[*]}] -add_delay set_input_delay -min -$skew -clock [get_clocks virtual_clock] [get_ports {ADC1_D[*]}] -add_delay set_input_delay -min -$skew -clock [get_clocks virtual_clock] -clock_fall [get_ports {ADC1_D[*]}] -add_delay set_false_path -setup -fall_from [get_clocks virtual_clk] -rise_to [get_clocks ADC1_CLK] set_false_path -setup -rise_from [get_clocks virtual_clk] -fall_to [get_clocks ADC1_CLK] set_false_path -hold -rise_from [get_clocks virtual_clk] -rise_to [get_clocks ADC1_CLK] set_false_path -hold -fall_from [get_clocks virtual_clk] -fall_to [get_clocks ADC1_CLK] #Example 49. from AN433 #set_input_delay -max <skew> -clock [get_clocks virtual_clock] [get_ports data_in] #set_input_delay -max <skew> -clock [get_clocks virtual_clock] -clock_fall [get_ports data_in] -add_delay #set_input_delay -min <negative skew> -clock [get_clocks virtual_clock] [get_ports data_in] -add_delay #set_input_delay -min <negative skew> -clock [get_clocks virtual_clock] -clock_fall [get_ports data_in] -add_delay #Example 52. #set_false_path -setup -fall_from [get_clocks virtual_clk] -rise_to [get_clocks data_clk] #set_false_path -setup -rise_from [get_clocks virtual_clk] -fall_to [get_clocks data_clk] #set_false_path -hold -rise_from [get_clocks virtual_clk] -rise_to [get_clocks data_clk] #set_false_path -hold -fall_from [get_clocks virtual_clk] -fall_to [get_clocks data_clk] Setup ADC1_CLK Hold ADC1_CLK И путь сигнала. Причём Quartus при компиляции сам выкрутил задержку в буфере до значения 42, хотя сам же сообщает, что данные должны быть раньше. Структура GPIO Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
