[RobFPGA 27]

Приветствую!

34 minutes ago, gin said:

А как передача значения счетчика в коде Грея защищает от метастабильности при переходе между клоковыми доменами?

Никак  
Грей защищает от ошибок FIFO из за метастабильности при передачи указателей через CDC.  При последовательном счете  код Грея меняется только в одном бите.  Соответственно если возникнет ошибка из за  метастабильности то она не приведет к фатальному, с точки зрения FIFO, изменению указателя. На приемной стороне указатель всегда будет двигаться в одну сторону (хоть и не равномерно).

Удачи! Rob.

[gin 0]

50 минут назад, RobFPGA сказал:

Грей защищает от ошибок FIFO из за метастабильности при передачи указателей через CDC.  При последовательном счете  код Грея меняется только в одном бите.  Соответственно если возникнет ошибка из за  метастабильности то она не приведет к фатальному, с точки зрения FIFO, изменению указателя. На приемной стороне указатель всегда будет двигаться в одну сторону (хоть и не равномерно).

Удачи! Rob.

Про фатальность - это вопрос)

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

[des00 25]

8 minutes ago, gin said:

Про фатальность - это вопрос)

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

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

[RobFPGA 27]

Приветствую!

19 minutes ago, gin said:

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

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

Удачи! Rob.

[gin 0]

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

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

Удачи! Rob.

Если счетчик Грея передается через цепочку регистров, то вопрос снимается :)

[dsmv 0]

Вообще то в современных условиях счётчик Грея уже не защищает, не смотря на то что он меняется только в одном разряде.

Это происходит, если задержка по разным линиям счетчика различается более чем на период тактовой частоты. Вполне возможна ситуация когда на одной линии 1.5 нс, на второй 2.5 нс. Тактовая 500 МГц.

Так что я выбрал решение при котором двоичный счётчик фиксируется на одной частоте и за несколько тактов передаётся на другую. 

[RobFPGA 27]

Приветствую!

52 minutes ago, dsmv said:

Вообще то в современных условиях счётчик Грея уже не защищает, не смотря на то что он меняется только в одном разряде.

В современных условиях  (да и старину былинную)   вместе с применением  кода Грея также требовалось использование timing constrain  которые задавали (для сигналов синхронизатора грея между клоковыми доменами)  set_max_skew не более минимального периода из wr/rd клоков. Если уж у вас счетчики адресов FIFO умудряется работать на 500 MHz то и обеспечить такой skew линий связи регистр-регистр тоже возможно.
Тогда все работает прекрасно. Не смотря на частоту и современные условия 

Вашим вариантом (handshake-based synchronization) тоже можно пользоваться,  проблем с кросс-clock тут меньше - но при этом  немного увеличивается latency FIFO,  что может увеличивать требуемый объем памяти и может быть критично для  для некоторых применений. 

Удачи! Rob.  

[dsmv 0]

47 minutes ago, RobFPGA said:

В современных условиях  (да и старину былинную)   вместе с применением  кода Грея также требовалось использование timing constrain  ....

Вот, и здесь появляются новые требования, про которые обычно все забывают. И новая область применения - low latency FIFO. Так что можно сформулировать - FIFO на основе счётчика Грея эффективно для небольших размеров, например до 64 слов. 

[RobFPGA 27]

Приветствую!

50 minutes ago, dsmv said:

Вот, и здесь появляются новые требования, про которые обычно все забывают.

Ну так в вашей схеме с handshake-based synchronization эти требования тоже "можно забыть" - ведь вы не можете оставить на произвол P&R  кросс-клок времянку для шины данных счетчика - тоже нужно ограничивать в constraint максимальное допустимое время  задержек роутинга.  

Удачи! Rob.

[dsmv 0]

57 minutes ago, RobFPGA said:

Ну так в вашей схеме с handshake-based synchronization эти требования тоже "можно забыть" -

Да я и забываю. И полагаюсь на произвол P&R  

Но четыре такта задержки перекрывают весь произвол. Или всё-таки три ?

[RobFPGA 27]

Приветствую!

8 minutes ago, dsmv said:

Но четыре такта задержки перекрывают весь произвол. Или всё-таки три ?

Частота  500 MHz - такт 2ns возьмем  4  такта - всего 8 ns  -  если для цепи  в шине синхронизатора  wr_reg[*] -> rd_reg[*]  не объявлен констрэйн и тактовые  асинхронные то времянка для этой цепи не контролируется и  P&R запросто может сделать (и делает) любую веревку из этой шины и 10 ns  и 20 ns. и как ему захочется. И что самое важное - даже не выругается при этом.  

15 minutes ago, dsmv said:

Да я и забываю. И полагаюсь на произвол P&R  

Вы судя  по всему везучий человек!  Ну в таком случае и с Греем также должно везти   без констрейнов  

Удачи! Rob.

[des00 25]

26 minutes ago, RobFPGA said:

Вы судя  по всему везучий человек!  Ну в таком случае и с Греем также должно везти   без констрейнов  

Он просто грея не любит, это из комментов на хабре было понятно ;) 

[RobFPGA 27]

Приветствую!

6 minutes ago, des00 said:

Он просто грея не любит, это из комментов на хабре было понятно ;) 

А мне как раз Грей нравится!  Особенно Earl 

Удачи! Rob.

[Avex 1]

С передачей кода грея, самое главное - не забывать, что в CDC не должно быть никакой логики, т.к. она является источником паразитного свитчинга (глитчей). Другими словами, после шифратора бин2грей надо ставить выходные флопы, а в приемной части (на другой частоте) то же самое - сначала  приемный флоп(или два), а потом дешифратор грей2бин. 

Констрейнты обязательны. Об этом уже написали.

 

p.s.

В принципе, с констрейнтами можно и не использовать код грея, а делать в лоб. И даже, можно транслировать значение счетчика без пересинхронизаторов и правила отсутствия логики в CDC - но только при наличии специального сопровождающего передачу хендшейка, котрый синхронизируется по всем правилам. В этом случае лэтенси так же будет 4-5 тактов (2 такта запрос и 2 такта ответ, плюс смещение приемной и передающей фаз), но понадобится гораздо меньше флопов.

Изменено 17 апреля, 2020 пользователем Aleх

[Plain 168]

В 15.04.2020 в 15:07, RobFPGA сказал:

Наоборот, Джонсон хуже

Об одном ли мы говорим — имелось ввиду по биту квитирования на ячейку на каждой стороне, т.е. "прочитано" / "записано", которые после стробирования становятся разрешением счёта и чтения / записи.