[RobFPGA 27]

9 hours ago, des00 said:

On 10/25/2023 at 8:57 AM, Burenkov said:

Попробуйте SPI_READY через два триггера пропустить перед использованием. Может быть s_spi_ready_1 оказывается в метастабильном состоянии 

на современных плис не актуально, там время выхода из этого состояния меньше 1нс, все советы про 2-3 триггера, в плис, относятся к плис времен царя гороха. Даже статьи такие есть с времянками. ЕМНП у тогоже 7 Series время выхода триггера из метастабильного состония порядка 100-200пс.

Странно это читать. 
Уменьшение времени восстановления триггера не влияет на необходимость с этой метастабильностью боротся. 
Метастабильность как раз и возникает на выходе s_spi_ready_1 и использование его (без второго триггера) в качестве источника данных и для логических операций грубейшая ошибка CDC.

 

9 hours ago, des00 said:

это делается для предотвращения упаковки в SRL примитив(чего уже не будет судя по описанной логике) и ограничения времени передачи, но для типовых тактовых 200МГц = 5нс, с учетом того что роутер минимизирует длинну трасс по умолчанию, эти 5нс это порядка четверти плис уровня 200ки артикса/300ки кинтекса. Судя по постам ТС, у него частота порядка 100-150МГц и мелкая ПЛИС. Резюмирую, по красоте вы абсолютно правы, но 99.9% что у ТС проблема не в этом.

Роутер не минимизирует задержки по умолчанию.  По умолчанию он делает задержки которые должны укладывается в  заданные констрены (период).   
А вот атрибут async_reg="true" как раз и говорит P&R  разместить регистры как можно ближе с минимальной задержкой роутинга, а не использовать констрейн на клоке которым питаются регистры CDC.       

[des00 25]

13 minutes ago, RobFPGA said:

Странно это читать. 
Уменьшение времени восстановления триггера не влияет на необходимость с этой метастабильностью боротся. 

я ни говорил что не надо с ней бороться, вы не внимательно читаете. наверное потому вам и странно.

13 minutes ago, RobFPGA said:

Метастабильность как раз и возникает на выходе s_spi_ready_1 и использование его (без второго триггера) в качестве источника данных и для логических операций грубейшая ошибка CDC.  

возникла, после этого через 100-200пс ушла, для тактовой 200МГц есть еще целых 4.8нс на то что бы все устаканилось на входе следующего (щих) триггеров до следующего фронта тактовой частоты.

[RobFPGA 27]

25 minutes ago, des00 said:

вы не внимательно читаете. наверное потому вам и странно.

Тогда как понять это:

9 hours ago, des00 said:

на современных плис не актуально, там время выхода из этого состояния меньше 1нс, все советы про 2-3 триггера, в плис, относятся к плис времен царя гороха

Подавление метастабильности зависит не только от времени выхода из метастабильности первого триггера.  А и от того  когда эта метастабильность уйдет на входе следующего! 

25 minutes ago, des00 said:

возникла, после этого через 100-200пс ушла, для тактовой 200МГц есть еще целых 4.8нс на то что бы все и устаканилось на входе следующего (щих) триггеров до следующего такта.

Вот и получается  -  чрез  100-200пс первый триггер вышел из X (метастабильности) и это состояние 0/1 пошло  распространятся по роутингу  до получателей. А так как обычным констрейном время роутинга  может быть  почти равным периоду клока то на входе  следующего регистра этот X может уйти аккурат в момент или после следующего фронта клока. Finita la commedia ... 
А если у вас трасс (да с разными задержками) от выхода первого триггера несколько (fanout > 1) это еще более усугубляет ситуацию ...

Именно поэтому и для самых современных и быстрых FPGA остается актуальным минимум два триггера в цепочке CDC и запрет использования fanout>1 в цепочке CDC.
А также по этому  специальными атрибутом  заставляют P&R размещать эти 2 и более триггеров как можно ближе и с минимальным роутингом и контролем DRC ситуации с fanout>1 для этих регистров. 

[des00 25]

30 minutes ago, RobFPGA said:

Тогда как понять это:

Так и понимать, что линейки из 3 и более триггеров (Как советовали выше, можно и 4 и 8 поставить, но ТС это не поможет с вероятностью 99.9%) на гражданских частотах и современных плис уже не актуальны.

30 minutes ago, RobFPGA said:

Подавление метастабильности зависит не только от времени выхода из метастабильности первого триггера.  А и от того  когда эта метастабильность уйдет на входе следующего! 

Вы же лучше меня знаете, что метастабильность возникает не сама по себе, а именно при нахождении сигнала на входе триггера в промежуточном состоянии в узком окне th-tsu, в момент действия фронта тактовой частоты. Если нет фронта тактовой частоты она не возникнет никогда.  Без триггера метастабильности нет. Время выхода из этого состояния определеляется технологическими параметрами и чем скоростнее и тоньше плис тем это время меньше. Справочные таблицы можно найти на сайте вендоров, там указано это время. И для современных плис порядок этого времени я указал.

30 minutes ago, RobFPGA said:

Вот и получается  -  чрез  100-200пс первый триггер вышел из X (метастабильности) и это состояние 0/1 пошло  распространятся по роутингу  до получателей. А так как обычным констрейном время роутинга  может быть  почти равным периоду клока то на входе  следующего регистра X может уйти аккурат в момент или после следующего фронта клока. Finita la commedia ... 

А может и не быть равным, если логика стоит тут рядом, а не тянется через всю плис. У ТС детектор фронта на входе КА, который делается на соседних логических блоках, с задержками до пары нс, при его тактовой порядка 100-150МГц. Времени для устаканивания сигналов вагон. 

ЗЫ. Роутер по умолчанию минимизирует задержку, может конечно в ваших проектах он и тянет сигнал в случае детектора фронта кольцами вокруг ультраскейла сотки, но вот я ни разу не видел что бы он был настолько туп. В таких схемах он делает по максимально короткому пути в соседний логический блок.

[RobFPGA 27]

12 minutes ago, des00 said:

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

Да именно так. И повторю что именно из за этого для  подавления метастабильности важно и время распространения/снятия этого X с выхода регистра где оно возникает до входов следующих получателей. 

2 minutes ago, des00 said:

А может и не быть равным, если логика стоит тут рядом а не тянется через всю плис. У ТС детектор фронта на входе КА, который делается на соседних логических блоках, с задержками до пары нс, при его тактовой порядка 100-150МГц. Времени для устаканивания сигналов вагон.

Какие там у TC времянки и где стоят надо не гадать, а смотреть логи и floorplan, репорты, ... 
Но и без всяких логов понятно то что схема с одним триггером в CDC является грубой ошибкой часто приводящей к похожим эффектам.
Поэтому первое что надо сделать это убрать этот источник проблем.  И проще всего это сделать, как и советовали выше, использовав готовый CDC, так как эти кролики модули не только "мясо" в виде 2-3 регистров но и ценный "мех" в виде ассоциированных к ним констрейнов ... 
Использование просто регистров в коде без сопутствующих констрейнов/атрибутов тоже возможно так как современные тулзы умеют распознавать эти ситуации.
Но IMHO все же спокойние самому контролировать все эти скользкие моменты.     

[des00 25]

9 minutes ago, RobFPGA said:

Какие там у TC времянки и где стоят надо не гадать, а смотреть логи и floorplan, репорты, ... 

Попросите он покажет, вангую что там чип меньше 200го артикса, заполненный на 30% и частоты порядка тех что указал, и задержки роутинга именно этой цепи порядка пары нс.

9 minutes ago, RobFPGA said:

Но и без всяких логов понятно то что схема с одним триггером в CDC является грубой ошибкой часто приводящей к похожим эффектам.

Не согласен, нужно дополнить вашу фразу в вашем любимом стиле: в том случае если задержка распространения до входа следующего тригера(ов)  сравнима с периодом тактовой частоты используемого тактового сигнала

9 minutes ago, RobFPGA said:

Поэтому первое что надо сделать это убрать этот источник проблем.  И проще всего это сделать, как и советовали выше, использовав готовый CDC, так как эти кролики модули не только "мясо" в виде 2-3 регистров но и ценный "мех" в виде ассоциированных к ним констрейнов ... 

Ну пусть поставит, напишет результат, посмотрим поможет ли и чье вангование сильнее.

9 minutes ago, RobFPGA said:

Использование просто регистров в коде без сопутствующих констрейнов/атрибутов тоже возможно так как современные тулзы умеют распознавать эти ситуации.
Но IMHO все же спокойние самому контролировать все эти скользкие моменты.     

ИМХО лучше понимать что делаешь и почему делаешь именно так, а то форум послушать так и на 1МГц надо ставить обязательно 2-3 регистра, а иначе работать нибудет аяяяй.

[RobFPGA 27]

18 minutes ago, des00 said:

ИМХО лучше понимать что делаешь и почему делаешь именно так, а то форум послушать так и на 1МГц надо ставить обязательно 2-3 регистра, а иначе работать нибудет аяяяй.

Имено так, поэтому я считаю правильно использовать решения гарантирующие  результат, а не зависящий от удачного расположения звёзд регистров, заполнения кристалла, прихоти алгоритмов P&R, ... 

[des00 25]

22 minutes ago, RobFPGA said:

Имено так, поэтому я считаю правильно использовать решения гарантирующие  результат, а не зависящий от удачного расположения звёзд регистров, заполнения кристалла, прихоти алгоритмов P&R, ... 

дадада, а потом начинается нечто подобное: подсобите люди добрые, не могу SPI slave на 100МГц сделать, где взять частоту 300/400МГц (с)

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

UPD. Накину докучи, даже зайлинкс уже отказывается в собственных корках от многотриггерных синхронизаторв, заменя их на "полуасинхронные" (название мое), но нет, мы все же будем ставить по 3 и более триггера ибо это гарантия еще от дидов)

[Plain 168]

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

не могу SPI slave на 100МГц сделать, где взять частоту 300/400МГц (с)

Автор этот SPI уже давно пишет, и очевидно до сих пор мультиплексорами на ходу.

[_4afc_ 25]

32 minutes ago, des00 said:

UPD. Накину докучи, даже зайлинкс уже отказывается в собственных корках от многотриггерных синхронизаторв, заменя их на "полуасинхронные"

А можно пример современного "полуасинхронного" синхронизатора c на чистом verilog? С необходимыми констрейнами и атрибутами.

[RobFPGA 27]

37 minutes ago, des00 said:

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

А я и не предлагаю "гарантированно совать без понимания". Это так же плохо как и "с пониманием надеятся на удачу".      

[Maverick_ 15]

3 hours ago, _4afc_ said:

А можно пример современного "полуасинхронного" синхронизатора c на чистом verilog? С необходимыми констрейнами и атрибутами.

вот взято с темплате vivado2019.1

для verilog

// Asynchronous Input Synchronization
//
// The following code is an example of synchronizing an asynchronous input
// of a design to reduce the probability of metastability affecting a circuit.
//
// The following synthesis and implementation attributes is added to the code
// in order improve the MTBF characteristics of the implementation:
//
//  ASYNC_REG="TRUE" - Specifies registers will be receiving asynchronous data
//                     input to allow tools to report and improve metastability
//
// The following parameters are available for customization:
//
//   SYNC_STAGES     - Integer value for number of synchronizing registers, must be 2 or higher
//   PIPELINE_STAGES - Integer value for number of registers on the output of the
//                     synchronizer for the purpose of improveing performance.
//                     Particularly useful for high-fanout nets.
//   INIT            - Initial value of synchronizer registers upon startup, 1'b0 or 1'b1.

   parameter SYNC_STAGES = 3;
   parameter PIPELINE_STAGES = 1;
   parameter INIT = 1'b0;

   wire <sync_out>;

   (* ASYNC_REG="TRUE" *) reg [SYNC_STAGES-1:0] sreg = {SYNC_STAGES{INIT}};

   always @(posedge clk)
     sreg <= {sreg[SYNC_STAGES-2:0], async_in};

   generate
      if (PIPELINE_STAGES==0) begin: no_pipeline

         assign sync_out = sreg[SYNC_STAGES-1];

      end else if (PIPELINE_STAGES==1) begin: one_pipeline

         reg sreg_pipe = INIT;

         always @(posedge clk)
            sreg_pipe <= sreg[SYNC_STAGES-1];

         assign sync_out = sreg_pipe;

      end else begin: multiple_pipeline

        (* shreg_extract = "no" *) reg [PIPELINE_STAGES-1:0] sreg_pipe = {PIPELINE_STAGES{INIT}};

         always @(posedge clk)
            sreg_pipe <= {sreg_pipe[PIPELINE_STAGES-2:0], sreg[SYNC_STAGES-1]};

         assign sync_out = sreg_pipe[PIPELINE_STAGES-1];

      end
   endgenerate

для vhdl

-- Asynchronous Input Synchronization
--
-- The following code is an example of synchronizing an asynchronous input
-- of a design to reduce the probability of metastability affecting a circuit.
--
-- The following synthesis and implementation attributes are added to the code
-- in order improve the MTBF characteristics of the implementation:
--
--  ASYNC_REG="TRUE" - Specifies registers will be receiving asynchronous data
--                     input to allow tools to report and improve metastability
--
-- The following constants are available for customization:
--
--   SYNC_STAGES     - Integer value for number of synchronizing registers, must be 2 or higher
--   PIPELINE_STAGES - Integer value for number of registers on the output of the
--                     synchronizer for the purpose of improveing performance.
--                     Particularly useful for high-fanout nets.
--   INIT            - Initial value of synchronizer registers upon startup, 1'b0 or 1'b1.

-- Insert the following before begin keyword of architecture
constant SYNC_STAGES : integer := 3;
constant PIPELINE_STAGES : integer := 1;
constant INIT : std_logic := '0';

signal <sync_out> : std_logic;  -- Synchronized output

signal sreg : std_logic_vector(SYNC_STAGES-1 downto 0) := (others => INIT);
attribute async_reg : string;
attribute async_reg of sreg : signal is "true";

signal sreg_pipe : std_logic_vector(PIPELINE_STAGES-1 downto 0) := (others => INIT);
attribute shreg_extract : string;
attribute shreg_extract of sreg_pipe : signal is "false";

-- Insert the following in the architecture after the begin keyword
   process(<clk>)
   begin
    if(<clk>'event and <clk>='1')then
       sreg <= sreg(SYNC_STAGES-2 downto 0) & <async_in>;  -- Async Input <async_in>
    end if;
   end process;

   no_pipeline : if PIPELINE_STAGES = 0 generate
   begin
      <sync_out> <= sreg(SYNC_STAGES-1);
   end generate;

   one_pipeline : if PIPELINE_STAGES = 1 generate
   begin
    process(<clk>)
    begin
      if(<clk>'event and <clk>='1') then
        <sync_out> <= sreg(SYNC_STAGES-1);
      end if;
    end process;
   end generate;

   multiple_pipeline : if PIPELINE_STAGES > 1 generate
   begin
    process(<clk>)
    begin
      if(<clk>'event and <clk>='1') then
        sreg_pipe <= sreg_pipe(PIPELINE_STAGES-2 downto 0) & sreg(SYNC_STAGES-1);
      end if;
    end process;
    <sync_out> <= sreg_pipe(PIPELINE_STAGES-1);
   end generate;

				
				

 

[Flip-fl0p 4]

18 часов назад, Maverick_ сказал:

вот взято с темплате vivado2019.1

для verilog

для vhdl

 

Так это обычный синхронизатор. 

[Maverick_ 15]

3 hours ago, Flip-fl0p said:

Так это обычный синхронизатор. 

ответ же на

23 hours ago, _4afc_ said:

А можно пример современного "полуасинхронного" синхронизатора c на чистом verilog? С необходимыми констрейнами и атрибутами.

🙂

[Flip-fl0p 4]

 

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

ответ же на

🙂

Ну так я понял. Только где здесь полу-асинхронный ? Тута обычная цепочка триггеров. 😁