Перейти к содержанию
    

Вопрос к асиководам по async fifo

Так вы сами себе и ответили.

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

:bb-offtopic: on

Диалог выше как раз пример плохого асинхронного FIFO

TC на своей "частоте" вроде пишет в FIFO данные вопроса. Но сами данные в "память" так и не попали - потерялись где то. Виден только сам факт записи вопроса - указатель записи перемещен кудато.

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

Далее процесс повторяется ... задержки/"тормознутости" на стороне записи ... не "gray-code" кодировка ответа ... результата нет. :(

:bb-offtopic: off

 

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

 

Удачи! Rob.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Так весь вопрос в том, с каких позиций лично Вы вели эту дискуссию.

Если это ОН сказал, что "синхронизаторы и грэй это фуфло и ничего не гарантируют",

то надо было просто ответить что каждая отдельная деталька в Мерседесе это тоже фуфло, и спорить не о чем.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос: к счетчикам Грея пересекающим домены это тоже относится?

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...