FIFO (CPLD+SRAM) Опции

[uragan90]

Доброго времени суток уважаемые!!!
Есть задача построить модуль FIFO на связке CPLD+SRAM. Это образно говоря решение будет использоваться как простое FIFO для передачи данных в микроконтроллер. Мозги кипят и требуется помощь знающих людей которые смогут помочь разобраться в проблеме.
Вопрос коммутационного плана на выложенной схеме дело в том что мк и плис работают на разных тактовых частотах и тут то и проблема.
Я думаю так сделать:
Данные со входа IN_DATA[15..0] поступают во внешнюю sram и там фиксируются сигналом (wd_sram) по адресу схемы которая тут не представлена в принципе это не важно. Начало работы начинается с того что мк подаёт запрос на то чтоб данные записались в регистр (inst5) сигналом (request) и если sram находится в режиме чтения то данные записываются в регистр при этом выставляется флаг регистр загружен -(confirmation) и сбрасывается регистр запроса на запись данных из sram. По приходу следующего запроса записи из sram в регистр (inst5) флаг (confirmation) сбрасывается в ноль и мк ожидает загрузки регистра (inst5) из него потом сдвиговым регистром будут выгружены данные в мк. Так я предположил выйти из проблемы пересечения клоковых доменов асинхронной фифо. Подскажите в правильном ли я направлении двигаюсь?

Прикрепленные файлы

 FIFO.pdf ( 1.19 мегабайт ) Кол-во скачиваний: 59

 

[krux]

Просто криво возможно как то но возможно ведь?

я полагаю, никто до сих пор не понял какого конечного результата вы хотите добиться =)

[Gorby]

я полагаю, никто до сих пор не понял какого конечного результата вы хотите добиться =)

Значит, у Вас такой задачи не стояло

Автору топика: вполне заурядная задача, смелее делайте и будет всё работать.
Не забудьте про довольно большие счетчики адресов, их сравнение, и результат этого сравнения.

Тут правильно советуют - операция записи в ОЗУ имеет приоритет перед чтением.
Работу с ОЗУ разбиваем на циклы. Цикл состоит из записи и потом чтения.
Если есть запрос на запись - пишем. Если есть запрос на чтение - читаем, пока не появится запрос на запись или не кончится чтение.
Если одновременно присутствует и запрос на запись, и на чтение, то в каждом цикле одно слово должно записаться, и одно-вычитаться.
Тут надо кропотливо поработать с таймингами ОЗУ.
Очень помогает моделирование в Моделсиме или что там у Вас есть.

[uragan90]

Тут правильно советуют - операция записи в ОЗУ имеет приоритет перед чтением.
Работу с ОЗУ разбиваем на циклы. Цикл состоит из записи и потом чтения.
Если есть запрос на запись - пишем. Если есть запрос на чтение - читаем, пока не появится запрос на запись или не кончится чтение.
Если одновременно присутствует и запрос на запись, и на чтение, то в каждом цикле одно слово должно записаться, и одно-вычитаться.
Тут надо кропотливо поработать с таймингами ОЗУ.

Так получается тут нужно реализовывать конечный автомат состояний?
Проблема видимо в том что у меня два клоковых домина и я не соображу как мне преодалеть эту проблему. У меня есть основной клок в CPLD 100Mhz. Частота записи 50Mhz а частота чтения 10Mhz. Эти частоты я реализовал делителями.
Была идея:
Запись в абсолютном приоритете!! Если поступил запрос на чтение то мы ждём пока кончится запись и как только это произойдёт то мы прочитаем данные на выход и выставим флаг готовности данных, сбросив при этом флаги запроса. Но при таком раскладе у меня в RTL модели видны защёлки, а это явная ошибка проекта.
Как же быть?

Я просто чувствую что это вполне реализуемо, но нет идей и помощи более опытных товарищей.

[Gorby]

Так получается тут нужно реализовывать конечный автомат состояний?
Я просто чувствую что это вполне реализуемо, но нет идей и помощи более опытных товарищей.

Да, конечный автомат нужен. Но он простой, один-два триггера.

Вы с частотами-то поосторожнее. Тщательно просчитайте, возможно ли в принипе добиться от Вашей памяти такой растактовки. Тут нужен в клеточку лист бумаги, карандаш и мозг. Оно само всё покажет. Если основной клок 100МГц и данные поступают на каждом втором такте - то у Вас просто нет шансов даже на запись - каким образом сформировать управляющие сигналы? Или делать асинхронщину на RC цепях. У Вас нету системного подхода. Сначала - растактовка памяти (управляющие сигналы формируются из виртуального клока, и это будет явно не 100МГц, а 180, 166 или рядом). Критерий - максимально выжать быстродействие ОЗУ при условии, что управление идет почти на макс скорости (половина системного клока).

Вижу сам, что сумбурно. Вы сами сразу всё увидите, как растактовку ОЗУ нарисуете.

[EvgenyNik]

Если основной клок 100МГц и данные поступают на каждом втором такте - то у Вас просто нет шансов даже на запись - каким образом сформировать управляющие сигналы?

Но данные приходят по 8 бит, а ширина шины данных ОЗУ 16 бит, что даёт ему возможность накопить слово и записать его одним махом. А пока оно копится - прочитать 16 бит для выдачи.

[uragan90]

Но данные приходят по 8 бит, а ширина шины данных ОЗУ 16 бит, что даёт ему возможность накопить слово и записать его одним махом. А пока оно копится - прочитать 16 бит для выдачи.

Именно так я и делаю!!! На частоте 100 я собераю данные по 8 бит, в регистр 16 бит. И того частота делится надвое. получается 50 Mhz. Память у меня 16ти разрядная и тем самым частота записи снижается. Читать я буду на частоте 10Mhz вот такой расклад получается, но проблема то в том что у меня 2 клоковых домина пересекающийся между собой!