Подскажите, может чего-то не учел.

Использую true dual block memory сгенеренный из сoregen Xilinx под spartan3e, клок на кристалле 50МГц.
В порт А пишется инфа внешним устройством (частота меньше 25мгц).
Из порта В чтение и запись FSMкой на частоте 50мгц.
Т.к память синхронная на порт A подан клок прямой, на блок B через инвертор.
По идее setup\hold time выдержаны, коллизий не должно быть.

Сообщение отредактировал des00 - Oct 21 2014, 07:34

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

не большой и памяти не много понадобиться...

PS Совет не используйте инверсию частот - на данном этапе без этого можно обойтись и глюков в дальнейшем меньше будет...

Есть ли рекомендации по синхронизации с двунаправленной шиной?
Достаточно ли сигналы cs, we, oe, addr, data положить в один триггер по системному клоку в плисе?

В ПЛИС уже давно внутри не может быть двунаправленной шины. Только на входах-выходах, но это не имеет никакого отношения к блочной памяти.

В моем случае внешнее устройство (арм) общается с плис как с памятью.

Нет, недостаточно. Глючить будет, особенно если клок ПЛИС не синхронен с клоком, тактирующим интерфейс памяти у процессора.

наиболее простой вариант такой:
Надо data защелкивать сигналом WE (использованным в качестве клока), с разрешением, сделанным логикой из CS, addr. этим же клоком и разрешением "взводить" флаг наличия данных. Затем, этот флаг через два триггера перегнать в домен клока ПЛИС, и по нему уже использовать данное дальше, и асинхронно сбросить этот флаг.

Чтение, это уже посложнее. Можно реализовать по аналогии - по активному фронту OE и правильных данных на CS/ADDR взвести некий флаг, пропустить его через два триггера, и по этому синхронизированному флагу асинхронно сбросить исходный флаг, и выставить данные наружу.

Почему удобно использовать OE и WE в качестве клоков на входныхх триггерах-флагах, это потому, что времянки WE/OE относитлеьно CS/ADDR/DATA всегда документированы и легко констрейнятся, и такой расклад позволяет сократить длительность цикла записи, за счет того, что проход данных в основной домен может идти уже после окончания чикла записи на самой шине (все уже защелкнуто по WE)

Если использовать WE как клок и адрес меняется синхронно с WE (судя по осциллу), можем словить не тот адрес? Надо цепляться за фронт WE при переключении в неактивное состояние.
Как "асинхронно сбросить этот флаг"? Или сформировать строб, что есть новые адрес и данные?

Сообщение отредактировал gotcha - Oct 21 2014, 08:09

так сделайте автомат эмулирущий память в плис - навскидку для примера общение через контролер памяти только наоборот

посмотрите SSRAM - преимущество в синхронности

какие виды памяти поддерживает арм процессор?
может достаточно вывести выводы блочной памяти (один порт) наружу к процессору?
скорость обмена какая должна быть?


формировать строб - есть новые данные - отдельный пин у плис и арм

Э. Я то думал, что у Вас асинхронный интерфейс к памяти. При этом фронт ~WE (задний, нарастающий ) соответствует моменту, когда CS/ADDR/DATA гарантировано стабильны.


Ну да, три триггера последовательно - два первых - синхронизаторы, третий - запоминает состояние выхода синхронизатора. И когда на втором единица, а на третьем еще ноль - формируется импульс асинхронного сброса триггера, работающего на клоке "WE", и этот же импульс является сигналом "защелкнутые по WE данные можно использовать в этом тактовом домене".

Сделал так
io буфер управляется напрямую

далее сигналы cs, oe, we пропускаются через два триггера, после формируются стробы

соответственно iAddr, ioData обрабатываются в fsmке по стробам, далее в 3 такта происходит работа (чтение\запись) с блочной памятью

Maverick, напрямую с блочной работало как часы, но еще нужна конфигурация через регистры. Скорость обмена около 20ms на чтение\запись 8 каналов и конфигурацию.

Сообщение отредактировал gotcha - Oct 24 2014, 06:56

Если нет цели максимально поднять быстродействие по записи (конвейеризировать, чтобы работать около предела скорости асинхронной шины для Вашей тактовой), то такая схема вполне нормальная.