Добрый день!

Простая задача: ввод данных с АЦП в MachXO2. АЦП тактируется от PLL ПЛИС:


В Quartus/TimeQuest временные ограничения для шины данных можно было бы задать так:

При этом учитывается как задержка данных на входных буферах ПЛИС, так и разность времен распространения клока от выхода PLL через кристалл наружу и от выхода PLL до регистров внутри ПЛИС.

В Lattice Diamond SDC не поддерживается (во всяком случае, в Place & Route и I/O Timing Analysis). Задавать временные ограничения нужно в LPF. В LPF ничего похожего на create_generated_clock нет. Аналогом set_input_delay является INPUT_SETUP. Вроде бы естественно написать:

Однако при этом, судя по отчету, в расчет берется только PADI_DEL + ROUTE данных минус ROUTE клока от PLL к регистру. Задержка вывода клока от PLL наружу не учитывается, что делает такой анализ бессмысленным.

Вопрос: как правильно задать временные ограничения для этого интерфейса в Diamond?

Про CLOCK_TO_OUT preference , CLKSKEWDIFF и прочее: Timing Closure 3.10
Вы этот документ смотрели?

Timing Closure 3.10 смотрел. Зачем CLKSKEWDIFF в данном случае? CLOCK_TO_OUT констрейнит выход, вопрос про вход...

Собственно, как раз CLOCK_TO_OUT сделан правильно — там есть параметр CLKOUT PORT, который позволяет указать, с какой ножки генерируется клок для внешнего мира. Как раз такого параметра явно не хватает INPUT_SETUP...

Пока в голову приходить только что-то типа такого:

где INPUT_DELAY - это сумма задержки вывода клока от PLL наружу, board trace и clock-to-output АЦП.

задайте в Synplify sdc, а он сгенерит lpf файл для p&r, можно его либо руками подправить (я так делал), либо загонять напрямую - наверно, в даймоновской среде это сделано автоматом при использовании batch mode, но я предпочитаю синтез выполнять в симплифайной оболочке, поэтому не знаю как

Я попробовал. Synplify из SDC сгенерировал LPF с констрейнами вида
INPUT_SETUP "adc_data[7]" 40.0 NS CLKPORT = "adc_clk";
...
На это Map выдал
WARNING: Semantic error in "INPUT_SETUP PORT "adc_data[7]" 40.00000 ns CLKPORT "adc_clk" ;": "adc_clk" matches no clock ports in the design. This preference has been disabled.
Соответственно, дальше анализ этих констрейнов не выполнялся. Я так понимаю, в качестве CLKPORT обязательно должна быть ножка с входным внешним клоком, сгенерированные клоки CLOCK_TO_OUT не понимает.


Ну да, против лома... Задержку вывода клока от PLL наружу даже получается удобно сосчитать в Diamond — у меня есть выходной сигнал, который выдается относительно того же adc_clk, и величина задержки, оказывается, есть в отчете соответствующего CLOCK_TO_OUT. Криво это, но похоже нормального способа нет. Странно, задача ведь совершенно стандартная...

кроме CLKPORT есть CLKNET - пробовали?
мне казалось, что из sdc генерится правильный lpf....

Пробовал — по отчету видно, что задержка вывода клока не учитывается. Synplify может и старается, но в LPF это скорее всего описать нельзя. Примеров констрейнов для "FPGA-synchronous input" в материалах Lattice я не нашел.

Вот синтезируемый пример:
(Diamond сам создает клоки clk_c и pll_clk_c в соответствии с настройками PLL, как бы неявно выполняет derive_pll_clocks -create_base_clocks)

Из post-fit отчета Trace видно следующее:
1) Для входа d1, который мы хотим тактировать сгенерированным клоком, рассчитывается PADI_DEL + ROUTE данных от ножки d1 к регистру rd1, ROUTE клока от PLL к регистру rd1, и все… Задержка сгенерированного клока от PLL к ножке и наружу не рассчитывается. Дополнительных параметров, аналогичных CLKOUT PORT для CLOCK_TO_OUT, INPUT_SETUP не поддерживает.
2) Для входа d2 с тактированием от внешнего клока на d2_clk все правильно: PADI_DEL + ROUTE данных от ножки к регистру и PADI_DEL + ROUTE клока от ножки к регистру.
3) Для выхода q1 с тактированием сгенерированным клоком тоже все правильно: ROUTE клока от PLL к регистру, ROUTE + OP0PAD_DEL от регистра к ножке, ROUTE + DOPAD_DEL от PLL до ножки для сгенерированного клока.

Во вложении архив проекта.