[1891ВМ12Я 0]

Делаю ресинхронизатор в виде цепочки, надеюсь это правильно. Как правильным образом задать это через set_false_path?

set_false_path -from [get_pins {src_path/some_reg/C}] -to [get_pins {dst_path/resync_bla_bla/dt_reg[*]/D}]

Задал ровно это, а оно мне все равно в репорте пишет что тут сбой тайминга. И ровно этими же названиями регистров и с теми же путями. Включение других цепей в этот же XDC файл позволило устранить проблему, а с некоторыми почему то не выходит. Может я не понял как же правильно заставить его забыть про эту цепь, как то более обощенно? Может прописать вовсе:

set_false_path -from [get_pins {src_path_to_some_reg/*}] -to [get_pins {dst_path/resync_bla_bla/*}]

То есть со звездочками?

И правильно ли я понимаю что если не устранить эту непонятку для анализатора в месте ресинхронизатора, то оно может в тщетных попытках подстроить схему, сломать ее вовсе? Хотя мне подсказывали что если high fanout параметр в отчете единичный, то и влияния на схему не будет.

 

Ниже код ресинхронизатора:

module resync1b(
input clock,
input in,
output out);
reg [7:0] dt;
assign out = dt[7];
always @(posedge clock) begin
	dt[0] <= in;
	dt[1] <= dt[0];
	dt[2] <= dt[1];
	dt[3] <= dt[2];
	dt[4] <= dt[3];
	dt[5] <= dt[4];
	dt[6] <= dt[5];
	dt[7] <= dt[6];
end
endmodule

[des00 25]

прописать эксклюзивные группы между тактовыми, а не вот это все)

[1891ВМ12Я 0]

3 hours ago, des00 said:

прописать эксклюзивные группы между тактовыми, а не вот это все)

Что это, и не исключит ли это из анализа те цепи, которые всё же стоит анализировать? Читаю ALTERA_TimeQuest.pdf, может речь про set_clock_groups?

[andrew_b 14]

4 hours ago, des00 said:

прописать эксклюзивные группы между тактовыми, а не вот это все)

Раз Xilinx, написать (* ASYNC_REG = "TRUE" *), и всё.

[RobFPGA 27]

6 hours ago, 1891ВМ12Я said:

Что это, и не исключит ли это из анализа те цепи, которые всё же стоит анализировать? Читаю ALTERA_TimeQuest.pdf, может речь про set_clock_groups?

Для правильного написания констрейнов  нужно  четко понимать структуру вашего дизайна и структуру клоков в нем.   
Если  клок  источника сигнала на входе in  асинхронен к клоку clock то,  как выше предлагал @des00, указание эксклюзивной (или асинхронной) группы для этих клоков более правильное решение. 
Если  эти  клоки связанные  и их нельзя назвать асинхронными,  или источник in не имеет клока  и вы хотите исключить этот путь   то правильно указать false-path  для конкретной цепи от источника  до входа (или только до входа) только  первого регистра в цепи,  а не их всех.
 

2 hours ago, andrew_b said:

Раз Xilinx, написать (* ASYNC_REG = "TRUE" *), и всё.

Этот  атрибут применяется к регистрам в цепочке синхронизации и находящихся  в одном клоке, и служит для указания P&R размещать эти регистры определенным образом для улучшения CDC MTBF, а не для исключения их из временного анализа.    

[1891ВМ12Я 0]

13 hours ago, RobFPGA said:

Если  клок  источника сигнала на входе in  асинхронен к клоку clock то,  как выше предлагал @des00, указание эксклюзивной (или асинхронной) группы для этих клоков более правильное решение

У меня этот сценарий. Что такое эксклюзивная группа? https://docs.xilinx.com/r/en-US/ug903-vivado-using-constraints/Exclusive-Clock-Groups - верно?

[des00 25]

18 hours ago, 1891ВМ12Я said:

Что это, и не исключит ли это из анализа те цепи, которые всё же стоит анализировать? Читаю ALTERA_TimeQuest.pdf, может речь про set_clock_groups?

ну у вас все равно тактовые асинхронные, т.е. нет передачи даных между доменами, за исключением синхронизатров и асинхронных фифо. Вам нужно set_clock_groups, да и в целом обзорное что-то почитать по констрейнам и подходам к синхронному анализу, можно начать с материала для "чайников" :)

ЗЫ. Я немного не правильно выразился, с точки зрения констрейнов асинхронные/эксклюзивные тактовые одинаковы, но с точки зрения логики здравого смысла нет, я ввел вас в заблужение). Асинхронные уже описал, эксклюзивные те которые существуют сами по себе, тогда как других может не быть (а могут и быть)

UPD. @RobFPGA прав, точеченые констрейны обычно применяются там, где надо расслабить временные ограничения локально. Например, есть какой нибудь сигнал, который ставится раз в пятилетку и его метастабильное состояние, при изменении, 146% будет обработано верно (ну или стробик результата какой будет). Вот чтобы не нагружать роутер, расслабляют по нему требования мультициклами или ложными путями применяемыми точечно.

 

[dmitry-tomsk 0]

On 10/4/2022 at 4:20 PM, 1891ВМ12Я said:

Делаю ресинхронизатор в виде цепочки, надеюсь это правильно. Как правильным образом задать это через set_false_path?

set_false_path -from [get_pins {src_path/some_reg/C}] -to [get_pins {dst_path/resync_bla_bla/dt_reg[*]/D}]

Задал ровно это, а оно мне все равно в репорте пишет что тут сбой тайминга. И ровно этими же названиями регистров и с теми же путями. Включение других цепей в этот же XDC файл позволило устранить проблему, а с некоторыми почему то не выходит. Может я не понял как же правильно заставить его забыть про эту цепь, как то более обощенно? Может прописать вовсе:

set_false_path -from [get_pins {src_path_to_some_reg/*}] -to [get_pins {dst_path/resync_bla_bla/*}]

То есть со звездочками?

И правильно ли я понимаю что если не устранить эту непонятку для анализатора в месте ресинхронизатора, то оно может в тщетных попытках подстроить схему, сломать ее вовсе? Хотя мне подсказывали что если high fanout параметр в отчете единичный, то и влияния на схему не будет.

 

Ниже код ресинхронизатора:

module resync1b(
input clock,
input in,
output out);
reg [7:0] dt;
assign out = dt[7];
always @(posedge clock) begin
	dt[0] <= in;
	dt[1] <= dt[0];
	dt[2] <= dt[1];
	dt[3] <= dt[2];
	dt[4] <= dt[3];
	dt[5] <= dt[4];
	dt[6] <= dt[5];
	dt[7] <= dt[6];
end
endmodule

В вивиадо эти уже давно никто не пользуется. Там для этого теперь xpm макросы, зайдите в language templates, cdc ищите, там разны есть, на все случаи жизни

 

   xpm_cdc_single #(
      .DEST_SYNC_FF(8),   // DECIMAL; range: 2-10
      .INIT_SYNC_FF(0),   // DECIMAL; 0=disable simulation init values, 1=enable simulation init values
      .SIM_ASSERT_CHK(0), // DECIMAL; 0=disable simulation messages, 1=enable simulation messages
      .SRC_INPUT_REG(1)   // DECIMAL; 0=do not register input, 1=register input
   )
   xpm_cdc_single_inst (
      .dest_out(dest_out), // 1-bit output: src_in synchronized to the destination clock domain. This output is
                           // registered.

      .dest_clk(dest_clk), // 1-bit input: Clock signal for the destination clock domain.
      .src_clk(src_clk),   // 1-bit input: optional; required when SRC_INPUT_REG = 1
      .src_in(src_in)      // 1-bit input: Input signal to be synchronized to dest_clk domain.
   );
 

[RobFPGA 27]

On 10/5/2022 at 5:42 PM, dmitry-tomsk said:

В вивиадо эти уже давно никто не пользуется. Там для этого теперь xpm макросы, зайдите в language templates, cdc ищите, там разны есть, на все случаи жизни

Ну не так уж и "никто", я вот в основном своими CDC пользуюсь, причем одними и теми же что в Vivado что в Quartus.   
Но в папочке где лежат xpm_cdc  порыться полезно, хотя бы на предмет посмотреть как  описаны констрейны для этих модулей      

[1891ВМ12Я 0]

On 10/5/2022 at 6:42 PM, dmitry-tomsk said:

xpm_cdc_single

Ничоси, я искал это два года назад но не нашел. Если там констрейны прописаны, то это отлично. А есть многоразрядная версия? С гарантией одновременности всех бит или даже без нее?

 

Стоп, минутку, это Families: UltraScale, UltraScale+ Это причина почему я не видел это для Kintex 7 - а для Kintex 7 и Spartan 7 такого не сделали?

[RobFPGA 27]

29 minutes ago, 1891ВМ12Я said:

Ничоси, я искал это два года

Не там значит искали ...

29 minutes ago, 1891ВМ12Я said:

А есть многоразрядная версия

Выбирайте: 

xpm_cdc.sv: xpm_cdc_single
xpm_cdc.sv: xpm_cdc_gray
xpm_cdc.sv: xpm_cdc_handshake
xpm_cdc.sv: xpm_cdc_pulse
xpm_cdc.sv: xpm_cdc_array_single
xpm_cdc.sv: xpm_cdc_sync_rst
xpm_cdc.sv: xpm_cdc_async_rst
xpm_cdc.sv: xpm_cdc_low_latency_handshake

 

[dmitry-tomsk 0]

6 hours ago, 1891ВМ12Я said:

Ничоси, я искал это два года назад но не нашел. Если там констрейны прописаны, то это отлично. А есть многоразрядная версия? С гарантией одновременности всех бит или даже без нее?

 

Стоп, минутку, это Families: UltraScale, UltraScale+ Это причина почему я не видел это для Kintex 7 - а для Kintex 7 и Spartan 7 такого не сделали?

Для всех семейств, с гарантией всех бит handshake или асинхронное fifo на srl.  В вивадо такая гарантия редко нужна, s_axi_lite может на любой частоте работать, вивадо автоматом синзронизацию добавляет.

[1891ВМ12Я 0]

On 10/28/2022 at 1:33 PM, RobFPGA said:

Не там значит искали ...

Выбирайте: 

xpm_cdc.sv

Спасибо, нашел через Language Templates! Поиск по слову CDC. Что примечательно, вивадо их не воспринял как модули, а ошибки таймингов испарились, видимо оно для себя что то знает что там тайминги не анализировать и там всё путем! 🙂

Заявлена поддерка 7-Series в том числе

[dxp 32]

13 часов назад, 1891ВМ12Я сказал:

Спасибо, нашел через Language Templates! Поиск по слову CDC. Что примечательно, вивадо их не воспринял как модули, а ошибки таймингов испарились, видимо оно для себя что то знает что там тайминги не анализировать и там всё путем! 🙂

Заявлена поддерка 7-Series в том числе

Там при использовании этих модулей автоматом подтягиваются нужные констрейны, поэтому всё получается консистентно . Констрейны лежат там же (директория относительно Vivado: data/ip/xpm/xpm_cdc/tcl), можно посмотреть, как и что реализовано в зависимости от модуля, который используется. Механизм этого автоматического подтягивания описывал уважаемый @RobFPGA, но я уже позабыл, как это делается. 🙂

[RobFPGA 27]

19 minutes ago, dxp said:

... но я уже позабыл, как это делается

Для этого файл констрейна "привязываются" к соответствующему модулю устанавливая property SCOPED_TO_REF именем нужного модуля.
Тогда такой констрейн будут применятся ко всем включениям этого модуля в дизайне, без учета иерархии.