[makc 192]

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

Да это то понятно, просто ЕМНП для сдвигов момента семплирования нужно указывать только -setup к -end клоку. Hold там двигается автоматически.

Не нахожу ни одного упоминания, что hold сдвигается автоматически. Можете дать источник этой информации?

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

Если задать setup/hold 2/1 как у вас это вариант анализа, когда -end клок идет в 2 раза реже.

Мне кажется, что мы по-разному понимаем логику работы set_multicycle_path. В моём понимании все констрейнты по-умолчанию для анализа setup/hold используют два последовательных фронта тактового (тактовых) сигналов, запускающего и защёлкивающего. set_multicycle_path позволяет отнести защёлкивающий фронт во времени на заданное число тактов в будущее, при условии, что в железе это обрабатывается соответствующим образом. Получается своеобразный конвейер для фронтов тактовых сигналов, который при всём при этом не влияет на их частоту, т.е. это не значит, что клок идёт в N раз реже. В данном случае, применительно к set_output_delay, это позволяет определить корректный порядок следования выдающего и защёлкивающего фронтов тактовых сигналов, т.к. среда сама не понимает, что на выходе у нас source synchronous интерфейс. У Xilinx для этого случая у set_output_delay предусмотрен параметр ‑reference_pin:

Цитата

-reference_pin <arg> - (Optional) Specifies that the delay is relative to the active edge of a clock appearing on the specified pin or port rather than a clock.

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

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

Почему, потому что source synchronous должен констрейниться относительно выхода клока - порта (выхода физического пада микросхемы), а не какого то баффера внутри.

Здесь так и есть - источником сигнала является выходной порт тактового сигнала. С тем же успехом можно было описать [get_ports clk_o], т.к. по своей природе выходной пин буфера ввода-вывода эквивалентен пину на корпусе с точки зрения STA.

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

Собственно, надо использовать этот констрейнт из примера Альтеры в первом посте, посколько он правильный де-юро, т.е. как в учебнике. С говин не работал, но шансов что они свою трактовку в туле сделали - ноль.

Если бы это работало, то вопросов бы не было. Но это не работает так, как предусмотрено у Альтеры. При этом, поскольку похоже корнями среда Gowin уходит в софт от Lattice, то там те же самые проблемы и я ни нашёл пока ни одного примера правильного описания констрейнтов source synchronous для Lattice. Может быть плохо искал и кто-то видел подобные примеры?

[des00 25]

28 minutes ago, makc said:

Не нахожу ни одного упоминания, что hold сдвигается автоматически. Можете дать источник этой информации?

Сейчас не под рукой, брал информацию из документов на TQ от альтеры. Там про мультициклы указано что они задаются как 

set_multicycle_path -from [<names>] -to [<names>] -setup <-end/begin> <setup_edge> 
set_multicycle_path -from [<names>] -to [<names>] -hold <-end/begin> <hold_edge_offset>

а само смещение 

hold_edge = setup_edge - 1 - hold_edge_offset

по умолчанию hold_edge_offset равен нулю, параметры setup_edge/hold_edge_offset для одноциклового обмена 1/0, для двухциклового 2/1 и т.д. Сдвиг на 1 такт 2/0, на два такта 3/0.  У зайлинкса вроде точно также, как у говина не знаю. Не работал. 

[makc 192]

2 минуты назад, des00 сказал:

а само смещение 

hold_edge = setup_edge - 1 - hold_edge_offset

по умолчанию hold_edge равен нулю, параметры setup/hold для одноциклового обмена 1/0, для двухциклового 2/1 и т.д. 

У меня так и задано, только с иным смыслом, чем это применяется для случая multicycle внутри ПЛИС.

[Yaahoo 0]

On 6/5/2023 at 11:31 AM, makc said:

Здесь так и есть - источником сигнала является выходной порт тактового сигнала. С тем же успехом можно было описать [get_ports clk_o], т.к. по своей природе выходной пин буфера ввода-вывода эквивалентен пину на корпусе с точки зрения STA.

Вариант с портом более читаем, гибок, переносим и вообще хрестоматиен. Конечно, если не работает, то увы.

Еще плохое решение - указавать цепь (net) в сорцах дженерейтек клока. По учебнику если, должен быть указан выходной пин. Вероятно, тул и сам может протрейсить драйвер цепи, но я бы все же советовал делать по учебнику.

Просили критику малтисайклов. Обьясню, в чем смысл их в приведенной доке. Обычно ss интерфейс независим - передаваемые данные тактуются передаваемым же клоком. В результате такой независимости летенси передаваемого клока по отношению к источнику клока может получиться оочень большим. Как это летенси ограничить в ПЛИС - можно использовать в т.ч. и малтисайклы, хотя это не решение, а костыль, причем препаршивый. Но в плис это может быть единственным решением ввиду того что sdc поддерживается не полностью. Важный момент: если дизайн не требует подобного ограничения летенси, то вы этим констрейнтом только мешаете тулу работать, поскольку малтисайкл только лишь ужесточает ограничения. А у вас и без того ситуация не очень. Поэтому, советую убрать малтисайклы и разобраться с дженерейтед клоком: он, по всей видимости, воспринимается тулом неадекватно по прежнему.

[makc 192]

Только что, Yaahoo сказал:

Вариант с портом более читаем, гибок, переносим и вообще хрестоматиен. Конечно, если не работает, то увы.

Согласен, перепишу его и проверю, что он работает также. Это был один экспериментов, который остался жить.

1 минуту назад, Yaahoo сказал:

Еще плохое решение - указавать цепь (net) в сорцах дженерейтек клока. По учебнику если, должен быть указан выходной пин. Вероятно, тул и сам может протрейсить драйвер цепи, но я бы все же советовал делать по учебнику.

Чем это плохо, если во-первых корректно с точки зрения документации на STA, во-вторых наглядно и в-третьих работает? Учебник учебником, но в документации это регламентировано и я не понимаю, зачем мне создавать себе сложности прибивая sdc гвоздями к конкретному инстансу, а не использовать более общее описание в виде имени цепи? Вы же сами немного выше предлагаете использовать более общее имя порта, а не имя пина буфера, который им управляет.

3 минуты назад, Yaahoo сказал:

Просили критику малтисайклов. Обьясню, в чем смысл их в приведенной доке. Обычно ss интерфейс независим - передаваемые данные тактуются передаваемым же клоком. В результате такой независимости летенси передаваемого клока по отношению к источнику клока может получиться оочень большим. Как это летенси ограничить в ПЛИС - можно использовать в т.ч. и малтисайклы, хотя это не решение, а костыль, причем препаршивый.

Я понимаю, что это костыль и он препаршивый. Поэтому и был вопрос - как обойтись без этого костыля в случае Gowin?

5 минут назад, Yaahoo сказал:

Важный момент: если дизайн не требует подобного ограничения летенси, то вы этим констрейнтом только мешаете тулу работать, поскольку малтисайкл только лишь ужесточает ограничения. А у вас и без того ситуация не очень. Поэтому, советую убрать малтисайклы и разобраться с дженерейтед клоком: он, по всей видимости, воспринимается тулом неадекватно по прежнему.

Хм, как раз multicycle даёт тулу вполне конкретный запас для анализа с учётом оффсета и математически всё хорошо сходится. Но проблема не в неадекватном восприятии generated clock, а в непонимании STA связи между этим выходным тактовым сигналом и данными, которые им стробируются на приёмной стороне. В идеале он должен был понять, что на выходе ODDR получается тот же тактовый сигнал, что и исходный clk, но сдвинутый на величину задержки переключения ODDR + задержки по выходу, а далее, исходя из этого вычисленного значения сдвига по фазе проконтролировать выходы ПЛИС, учитывая при этом очерёдность фронтов (запускающего и защёлкивающего). Но... Как я уже писал выше, Gowin не знает про параметр reference_pin и никакого эквивалента его у него тоже нет, если судить по документации. У Lattice (предка Gowin) тоже нет ничего подобного (или я не нашёл). Соответственно я не понимаю, как ещё задать параметры в формуле расчёта setup/hold на приёмной стороне, которые задаются с помощью set_output_delay, кроме как с помощью дубового offset для generated clock и multicycle. Поэтому критика критикой, а альтернативы нет.

[Yaahoo 0]

On 6/5/2023 at 9:14 PM, makc said:

Чем это плохо, если во-первых корректно с точки зрения документации на STA, во-вторых наглядно и в-третьих работает? Учебник учебником, но в документации это регламентировано и я не понимаю, зачем мне создавать себе сложности прибивая sdc гвоздями к конкретному инстансу, а не использовать более общее описание в виде имени цепи? Вы же сами немного выше предлагаете использовать более общее имя порта, а не имя пина буфера, который им управляет.

Насколько помню, синтаксис этой команды требует пин, а не цепь. Но, не спорю: главное чтобы работало.

 

Просто для информации, используя команды sdc можно писать следующие конструкции:

get_pins -of [get_nets clk] -filter direction==out

Эта строка позволяет автоматически находить драйвер цепи. Универсально, гибко, удобно, можно вставлять в констрейнты, и использовать интерактивно из консоли тула.

[makc 192]

6 минут назад, Yaahoo сказал:

Насколько помню, синтаксис этой команды требует пин, а не цепь. Но, не спорю: главное чтобы работало.

Да, обычно так. Но у Gowin свой путь.

8 минут назад, Yaahoo сказал:

Просто для информации, используя команды sdc можно писать следующие конструкции:

get_pins -of [get_nets clk] -filter direction==out

Всё бы ничего, только Gowin про такое не знает и выдаёт ошибку:

ERROR  (TA2000) : "constraints/timing.sdc":8 | 'syntax error' near token '-'

 

9 минут назад, Yaahoo сказал:

Эта строка позволяет автоматически находить драйвер цепи. Универсально, гибко, удобно, можно вставлять в констрейнты, и использовать интерактивно из консоли тула.

Полностью с вами согласен и в Xilinx, где есть консоль, это удобно и прекрасно работает. Но у Gowin это не так. Если ввести в консоль TCL эту команду, то опять же получим ошибку:

% get_pins -of [get_nets clk] -filter direction==out
invalid command name "get_nets"

У них sdc не sdc, а жалкое подобие и консоль очень сильно урезана.

[honinbo 1]

On 6/4/2023 at 3:04 PM, makc said:

В итоге получается приблизительно следующее описание:

create_generated_clock -name clk -source [get_ports {sys_clk_i}] -multiply_by 12 -divide_by 5 [get_pins {main_pll_inst/rpll_inst/CLKOUT}]
create_generated_clock -name clk_o -source [get_nets {clk}] -offset 2.819 [get_pins {clk_o_obuf/O}]
set_output_delay -clock [get_clocks {clk_o}] -max 2.2 -rise [get_ports {dio[*]}]
set_multicycle_path -setup 2 -from [get_clocks {clk}] -to [get_ports {dio[*]}]
set_multicycle_path -hold 1  -from [get_clocks {clk}] -to [get_ports {dio[*]}]
report_timing -setup -max_paths 100 -from_clock [get_clocks {clk}] -to_clock [get_clocks {clk_o}]

2.819 ns это оценочное значение задержки по выходу clk_o_obuf/O от выхода Q0 ODDR до пина корпуса. Его в принципе не сложно вытащить.
2.2 ns это требуемое значение Tsu на стороне приёмника данных.

Прошу покритиковать найденное решение.

А set_clock_propagated gowin понимает?

Тогда бы и задержки брались автоматически для нужных углов.

А synplify к gowin можно прикрутить?

[makc 192]

42 минуты назад, honinbo сказал:

А set_clock_propagated gowin понимает?

К сожалению нет, такого он не знает. 😞

43 минуты назад, honinbo сказал:

А synplify к gowin можно прикрутить?

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