Jump to content
    

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

:bb-offtopic: on

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

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

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

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

:bb-offtopic: off

 

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

 

Удачи! Rob.

 

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...