[makc 212]

Всем привет!

Имеется ПЛИС GW1NR-LV9QN88PC6/I5 (Tang Nano 9K). В документации от Gowin (SUG283-1.5E, 11/15/2018) указано наличие примитива BUFG:

Я инстанцирую его в модуле верхнего уровня и в нетлисте после синтеза он ожидаемо присутствует. Однако в сгенерированном после pnr файле vo его нет. Нет его и в путях прохождения тактового сигнала Timing Analyzer. Т.е. складывается впечатление, что этот примитив BUFG на самом деле не существует на кристалле ПЛИС. Или я что-то делаю не так?

Если использовать в качестве входов тактовых сигналов пины GCLKT, то проблем нет и ругани в PNR на эту тему тоже нет. Но мне интересен вариант использования глобального буфера, на вход которого сигнал подаётся не с выделенного пина, а с любого другого. Я понимаю, что это даёт дополнительную задержку, но в ряде случае это допустимо и может быть даже вполне оправдано. Получается, что такой вариант с Gowin невозможен?

 

 

[_4afc_ 25]

On 6/24/2022 at 2:43 PM, makc said:

В документации от Gowin (SUG283-1.5E, 11/15/2018) указано наличие примитива BUFG:

Я инстанцирую его в модуле верхнего уровня и в нетлисте после синтеза он ожидаемо присутствует. Однако в сгенерированном после pnr файле vo его нет. Нет его и в путях прохождения тактового сигнала Timing Analyzer. Т.е. складывается впечатление, что этот примитив BUFG на самом деле не существует на кристалле ПЛИС. Или я что-то делаю не так?

Если использовать в качестве входов тактовых сигналов пины GCLKT, то проблем нет и ругани в PNR на эту тему тоже нет. Но мне интересен вариант использования глобального буфера, на вход которого сигнал подаётся не с выделенного пина, а с любого другого. Я понимаю, что это даёт дополнительную задержку, но в ряде случае это допустимо и может быть даже вполне оправдано. Получается, что такой вариант с Gowin невозможен?

Я делал BUFGCE называемый у них DQCE

DQCE    Pll_DQCE (.CLKIN(PLL_48M), .CE(PLL_Lock), .CLKOUT(CLK48) );

 

Главное клок прописать в констрейны - тогда вроде появиться должен

create_generated_clock -name Clock48CE -source [get_pins {ClkCore1/Pll_48/rpll_inst/CLKOUT}] -multiply_by 1  [get_pins {ClkCore1/Pll_DQCE/CLKOUT}]

 

В файле .VG есть строка

  DQCE Pll_DQCE (
    .CLKOUT(CLK48M),
    .CLKIN(PLL_48M),
    .CE(PLL_Lock)
);

 

в путях сигнала

 

 

[makc 212]

1 час назад, _4afc_ сказал:

Главное клок прописать в констрейны - тогда вроде появиться должен

Не понял связи. Этого ведь совершенно на первый взгляд не связанные вещи. Но хуже точно не будет.

1 час назад, _4afc_ сказал:

В файле .VG есть строка

У меня BUFG там тоже есть. Смотреть нужно на файл VO из PNR, но чтобы он генерировался нужно включить опцию в настройках Place and Route.

В понедельник попробую DQCE и его собратьев, хотя в моём понимании BUFG это и есть DQCE с .CE(1)

[DanilinS 4]

Если Вы хотите указать что, например, сигнал clk должен разводиться через глобальный буфер, то пишете в cst-файле:

CLOCK_LOC "clk" BUFG = CLK;

С начало обычно идет предупреждение типа: 
Found signal identified as System clock which controls 8 sequential elements including out[7:0]. Using this clock, which has no specified timing constraint, can prevent conversion of gated or generated clocks and can adversely impact design performance.
а далее идет 
Warning (PR1014) : Generic routing resource will be used to clock signal 'clk' by the specified constraint. And then it may lead to the excessive delay or skew

Но есть нюансы при генерации тактовых сигналов:
1) если не назначать принудительно clk на BUFG, то P&R достаточно сообразителен, чтобы сделать это самому.
2) если назначить констрейнтом clk на BUFG, то так и будет сделано.
3) если назначить констрейнтом clk на LOCAL_CLOCK, то BUFG использоваться не будет. 

И есть глобальные ограничения (относительно BUFG - "Synopsys Synplify Pro® for GoWin. User Guide ):

Quote

Limitations
• No DDR inference support.
• No clock buffer (BUFG and BUFS) inference support.

 

[makc 212]

27 минут назад, DanilinS сказал:

Warning (PR1014) : Generic routing resource will be used to clock signal 'clk' by the specified constraint. And then it may lead to the excessive delay or skew

Как раз с этого всё и началось: сначала попробовал прописать констрейнт - безрезультатно, потом инстанцировал BUFG - тоже мимо. Сообщение пропало только после переноса сигнала на контакт типа GCLKT. Изначально он был на GCLKC, но я надеялся обойтись небольшими потерями (задержками) и добавлением глобального буфера.

32 минуты назад, DanilinS сказал:

И есть глобальные ограничения (относительно BUFG - "Synopsys Synplify Pro® for GoWin. User Guide ):

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

[makc 212]

В 24.06.2022 в 16:51, _4afc_ сказал:

Главное клок прописать в констрейны - тогда вроде появиться должен

create_generated_clock -name Clock48CE -source [get_pins {ClkCore1/Pll_48/rpll_inst/CLKOUT}] -multiply_by 1  [get_pins {ClkCore1/Pll_DQCE/CLKOUT}]

 

В файле .VG есть строка

  DQCE Pll_DQCE (
    .CLKOUT(CLK48M),
    .CLKIN(PLL_48M),
    .CE(PLL_Lock)
);

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

[makc 212]

@_4afc_ у меня, судя по отчёту Timing Analyzer, при анализе Setup/Hold для тактового сигнала после DQCE не учитываются задержки (сдвиг по фазе выхода DQCE) относительно входного пина, т.е. оказывается неучтена задержка IOB и задержка в цепи от IOB до DQCE. На сколько я понимаю каки-либо средств заставить его анализировать эти задержки в пути нет. Констрейнты у меня заданы следующим образом:
 

create_clock -name clk -period 66.667 -waveform {0 33.333} [get_ports {clk}]
create_generated_clock -name clk_g -source [get_ports {clk}] -master_clock [get_clocks {clk}] -multiply_by 1 [get_pins {clk_dqce_inst/CLKOUT}]

В итоге при анализе Setup/Hold длина пути тактового сигнала считается исключительно от выхода DQCE при том, что set_input_delay и set_output_delay заданы относительно clk (входного тактового сигнала). ЧЯДНТ?

[Yuri124 2]

On 6/27/2022 at 1:30 PM, makc said:

create_generated_clock -name clk_g -source [get_ports {clk}] -master_clock [get_clocks {clk}] -multiply_by 1 [get_pins {clk_dqce_inst/CLKOUT}]

Мне непонятно последнее выражение 

-multiply_by 1 [get_pins {clk_dqce_inst/CLKOUT}]

В https://docs.xilinx.com/r/en-US/ug835-vivado-tcl-commands/create_generated_clock 

подобного не нашел.

Может случиться такое, что этот generated clock назначается на clk_dqce_inst/CLKOUT, и потом задержки начинают вычисляться относительно этого положения?

[makc 212]

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

Мне непонятно последнее выражение 

-multiply_by 1 [get_pins {clk_dqce_inst/CLKOUT}]

В https://docs.xilinx.com/r/en-US/ug835-vivado-tcl-commands/create_generated_clock 

подобного не нашел.

[get_pins {clk_dqce_inst/CLKOUT}] соответствует значению <objects> (List of clock source ports, pins, or nets). Вроде всё логично.

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

Может случиться такое, что этот generated clock назначается на clk_dqce_inst/CLKOUT, и потом задержки начинают вычисляться относительно этого положения?

Похоже так оно и происходит, но при анализе Setup/Hold относительно входного клока анализатор должен учитывать полный путь прохождения тактового сигнала. А он его не принимает во внимание, точнее анализирует только последний отрезок пути - от DQCE до тактового входа триггеров.

[_4afc_ 25]

On 6/27/2022 at 1:30 PM, makc said:

у меня, судя по отчёту Timing Analyzer, при анализе Setup/Hold для тактового сигнала после DQCE не учитываются задержки (сдвиг по фазе выхода DQCE) относительно входного пина, т.е. оказывается неучтена задержка IOB и задержка в цепи от IOB до DQCE. На сколько я понимаю каки-либо средств заставить его анализировать эти задержки в пути нет. Констрейнты у меня заданы следующим образом:

Я не настолько силен в констрейнах, проблема говинный create_generated_clock глючный не того же плана?

[Yuri124 2]

On 6/27/2022 at 2:11 PM, makc said:

Вроде всё логично

спасибо, разобрался - это я тупанул в синтаксисе.

Когда-то я читал мануал по таймингам от гуру в этом деле - там в Квартусе тоже присутствовало непонятное поведение анализатора времянки - выбрасывал кусок пути из анализа. 

Вполне может и тут быть подобный глюк - как выше уже написали.

 

Е если попробовать убрать этот generated clock...

Изменено 27 июня, 2022 пользователем Yuri124

[makc 212]

18 минут назад, _4afc_ сказал:

Я не настолько силен в констрейнах, проблема говинный create_generated_clock глючный не того же плана?

Да, очень похоже на мой случай. Похоже ничего с тех пор не поменялось.

15 минут назад, Yuri124 сказал:

Е если попробовать убрать этот generated clock...

Если убрать, то он просто игнорирует Setup/Hold, т.к. нет пути тактового сигнала. Так что это не вариант, в том числе и с точки зрения банальной логики.

Похоже пора начинать писать FAQ по приключениям с Gowin...

[_4afc_ 25]

On 6/27/2022 at 2:50 PM, makc said:

Да, очень похоже на мой случай. Похоже ничего с тех пор не поменялось.

Может тогда уважаемый @SM подскажет нам, что прописывать в таких случаях (DQCE ) в констрейны?

[makc 212]

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

Может тогда уважаемый @SM подскажет нам, что прописывать в таких случаях (DQCE ) в констрейны?

Руками, на основании репорта для аналогичных цепей. Но в общем случае это пальцем в небо, т.к. раскладка цепей по кристаллу нигде не задокументирована... Можно ещё попробовать воспользоваться функциями report_* и брать результаты из их выдачи, но я поигравшись с ними большой надежды на них не возлагаю.

[_4afc_ 25]

On 6/27/2022 at 7:50 PM, makc said:

Руками, на основании репорта для аналогичных цепей. Но в общем случае это пальцем в небо, т.к. раскладка цепей по кристаллу нигде не задокументирована... Можно ещё попробовать воспользоваться функциями report_* и брать результаты из их выдачи, но я поигравшись с ними большой надежды на них не возлагаю.

Я для себя хочу понять, если задержки клока от входного пина до выхода DQCE не интересны, т.е. весь проект висит на выходе DQCE  - всё корректно?

Проблемы только если с входного пина ещё что-то тактируется и надо это учесть?