Привет, коллеги. Возникла в уменя дискуссия с ASIC'овцем про Async FIFO.
Утверждает, что стандартного Async dual clock FIFO c счётчиками Грея и синхронизаторами недостаточно для стабильной работы.
Моё мнение - достаточно, а если что, надо брать более длинные синхронизаторы.

Что посоветуете, где правда?
Речь, разумеется, не идёт про rad grade и всё такое.

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


Посоветую привести аргументы обоих сторон.


Точно не в ногах!

Удачи! Rob.

Михаил, привет!

https://habrahabr.ru/post/321674/ вот этот пост интересен, там еще народ в комментариях нашел ошибку у автора и приводит кучу аргументов и ссылок

Лексика не понравилась. Resync - правильно, Reclock - допустимо, Retact - это уже какой-то язык с Брайтон-Бич ("Вам чиз как - послайсить или целым писом?" - отвратно же). И потом они утонули, обсуждая изобретённый автором велосипед вместо кода Грея. То ли он про него не знает, то ли знает и не применяет, не охото в это погружаться. Это как начать решать систему уравнений и погрязнуть в дискуссиях о формуле дискриминанта.
"Запись в FIFO одновременно со сбросом...." - а нафига расставлять себе грабли и потом удивляться... Надо просто аккуратно писать код.

p.s.
Надо читать знаменитые 2 pdf от Клиффорда Саммингса, вот код на примере его статей:
http://subversion.assembla.com/svn/ecpe-29...ll_async_fifo.v

Так вот, мой вопрос - этого достаточно для ASIC, или надо что-то ещё. Мой визави утверждает, что _недостаточно_, и надо мониторить FIFO на предмет дублирования и пропадания данных на выходе. Моё короткое мнение - это чушь собачья, т.к. FIFO - это не трёхрегистровый синхронизатор.

И все же, вопрос непонятен. Что значит - достаточно или недостаточно?
1. Для начала, любая память глубоко внутри полностью асинхронна. Компилятор памяти может ее упаковать по Вашему желанию - с триггерами по адресу, триггерами по входу данных, триггеру по выходу данных, либо вообще безо всяких триггеров. Кроме того, память бывает многопортовая. В Вашем случае, речь видимо идет о двупортовой памяти с двумя взаимо-асинхронными синхронными интерфейсами. Итак, когда с памятью стало понятно, следующий вопрос - управление этой памятью
2. Поскольку контроллер записи в память работает на одном клоке, а контроллер чтения на другом, получаем два асинхронных клоковых домена. Для них справедливо правило - ставить два триггера на любой сигнал, пересекающий границу доменов. В общем случае, это статусы FIFO_Full и FIFO_Empty, но в зависимости от реализации могут быть и другие сигналы.
Делаю вывод, что вопрос касался пункта 2 - сколько триггеров ставить на пересинхронизацию сигналов управления между клоковым доменом записи, и клоковым доменом чтения. Ответ - в общем случае достаточно 2 триггеров, но если частоты под гигагерц, то лучше ставить 3.

Без претензии на теорию, мегафункции FIFO от Altera у меня глючили на CYCLONE 3 постоянно - то не успевают, то двоят, занимают вдвое больше памяти, чем требуется, то еще что-нибудь. Пришлось написать свой без претензий на общность, но на тех же принципах - код Грея в счетчиках, пересинхронизация на 2 триггерах - и о чудо - никаких сбоев и все влезает по объему. Так что, вопрос - что имелось ввиду при разговоре о "достаточно".

Согласен с доводами, считаю ваш ответ -- "достаточно"




В старые и не очень времена у обоих вендоров было много косяков. С DDR-контроллером, PLLями, трансиверами, да бог знает с чем ещё, возможно и с FIFO. Я вот нашёл Sim-Syn mismatch для Xilinx FIFO последних версий (годичной давности). Но в целом я про то, надо ли вводить доп. контроль или нет. Прихожу к выводу, что нет.

Несколько лет назад сталкивались с тем, что Quartus вставляет собственную логику в контроллер фифо, после чего фифо перестает работать. Название этой логики не помню, но она блокировала чтение из того же адреса, куда велась запись. О вставке этой логики была соответствующая строка в логе: inferred что там. Проблема вылечилась тем, что в настройках Quartus просто запретили вставлять эту логику. После чего все заработало.

Вопрос: к счетчикам Грея пересекающим домены это тоже относится?
И ещё вопрос: нет ли требования на разброс задержек между разрядами счетчика при пересечении доменов?

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

С вашими карандашом и бумагой какие ответы получаются?

1) да
2) есть

Можно узнать что значит Async FIFO?
Фифо с независимыми клоками?

Вообще же вопрос на уровне "достаточно ли иметь голову и 4 конечности чтобы быть человеком".
Фифо это чуть больше чем счётчик грея и синхронизаторы, которые в любом случае есть всегда.

Ответ на 1й вопрос в 1м посте:

Да, с двумя независимыми клоками. На что это ещё похоже?


Не понял, поясните.


Спасибокэп.

Так вы сами себе и ответили.
Если очевидно, что фифо это большая конструкция, включающая в себя "синхронизаторы" и "грея" как малые части,
то почему родился такой наивный вопрос?

Так я же в начале написал, что у меня была долгая дискуссия с одним рук-лем проекта, по asic'ам. И он утверждал, что async dcfifo - штука в asic'е ненадёжная, и что надо писать проверяющий модуль снаружи. Чем меня здорово удивил.

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

on
Диалог выше как раз пример плохого асинхронного FIFO
TC на своей "частоте" вроде пишет в FIFO данные вопроса. Но сами данные в "память" так и не попали - потерялись где то. Виден только сам факт записи вопроса - указатель записи перемещен кудато.
Далее пошел процесс синхронизации на сторону чтения. И опять же - кодировка события явно не "gray-code" поэтому в зависимости от задержек/"тормознутости" на стороне чтения возникает неоднозначность восприятия. Появляющаяся мета-стабильность чтения (да еще и в купе с отсутствующими в памяти FIFO реальными данными вопроса) вызывает неопределенные ответы/фантазии на сторону записи.
Далее процесс повторяется ... задержки/"тормознутости" на стороне записи ... не "gray-code" кодировка ответа ... результата нет.
off

Попробую ресетнуть это "FIFO" - TC: Все же каковы были конкретные аргументы Вашего визави с которыми Вы были несогласны?

Удачи! Rob.

Так весь вопрос в том, с каких позиций лично Вы вели эту дискуссию.
Если это ОН сказал, что "синхронизаторы и грэй это фуфло и ничего не гарантируют",
то надо было просто ответить что каждая отдельная деталька в Мерседесе это тоже фуфло, и спорить не о чем.

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

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

Проблема уже не важна, но комментарии ценны. )