Для Вашего МК (по даташиту) я бы делал так (пока в общих чертах, завтра если будет время - постараюсь набросать):
на внешних портах ПЛИС имеем
- we, заводим на клоковый вход регистра записи (данные и адрес записи, МК -> ПЛИС);
- bls (один из них, скорей всего младший), заводим на клоковый вход регистра чтения (данные и адрес чтения, ПЛИС -> МК);
- oe заводим на управление двунаправленой шиной данных, и на вход разрешения регистра чтения (а может и записи);
- двунаправленную шину данных;
- шину адреса;
- cs (а вдруг Вы не к ПЛИС обращаетесь?).
Внутренним клоком стробируем выход регистра записи и вход регистра чтения (формируем "свои" регистры в клоковом домене);
на внутренних портах этого модуля имеем (выход - в логику ПЛИС, вход - от логики ПЛИС) сигналы в домене своего клока:
- собственно сам внутренний клок ПЛИС (вход);
- адрес записи (выход - адрес, по которому произошла запись);
- сигнал, говорящий о факте записи (выход, выставляется при записи);
- данные записи (выход);
- адрес чтения (выход - адрес по которому МК собирается прочитать из ПЛИС, может объединим с адресом записи);
- сигнал, говорящий о факте чтения (выход, выставляется при чтении);
- данные для чтения (вход, выставляется ПЛИС по адресу чтения).
Повторюсь - пока это в общих чертах. Вы тоже подумайте. Вам достаточно этих сигналов?
В любом случае таймингами EMC МК придется поиграться - обычная процедура при связках двух камней.

Про we и bls согласен. Но заводить ли "oe" отдельно? Для выбора направления шины данных на выход из ПЛИС мне кажется можно использовать тот же bls. Задержка распросранения этого сигнала внутри ПЛИС позволит, думаю, выдержать требования по удержанию данных на шине для МК (перед переходом в третье состояние). К тому же из PDF на МК для себя сделал заключения, что сигналы bls и oe практически идентичны друг другу.
CS в данном случае не требуется. На шине сидят только МК и ПЛИС.
Дальше уже не совсем прозрачно - операция чтения/записи будет происходить за один цикл МК? И требуется ли подавать We и bls на клоковые пины ПЛИС?

Так как частота сигналов на шине EMC МК ниже чем системная частота МК (подозреваю, что минимум в два раза), а системная частота ПЛИС равна системной МК - то скорей всего да. То есть не за один цикл МК, а за один цикл ЕМС МК.
we подавать на клоковый вход для того, чтобы не ПЛИС защелкивала шину по своим клокам и по уровню we, а МК в ПЛИС защелкнул своим we.
Набросал часть записи (МК -> ПЛИС)
.
Часть чтения позже, скорей всего завтра (завал на работе). Синхронизаторы на шинах данных и адреса скорей всего можно будет убрать - данные и адрес для ПЛИС уже гарантировано защелкнуты. Опыты покажут. ое и bls - не одно и тоже. oe устанавливается только при записичтении, а bls каждый раз - и при записи и при чтении.

Сообщение отредактировал olegras - Sep 3 2013, 11:08

--

Я имел ввиду что СКОРЕЙ ВСЕГО можно будет оставить только синхронизатор для wrx. Потому что на момент синхронизации wrx по clk - адрес и данные (защелкнутые по we) уже не в метастабильном состоянии.

А еще можно подумать задействовать двухпортовое ОЗУ. В порт А МК будет записывать в домене we. Зная адрес записи, ПЛИС по порту B будет забирать в домене clk.

Действительно хорошее решение. Я проанализировал, набросал тестовый проектик. По редактору диаграмм все отлично работает. Если для wr использовать два последовательных триггера-синхронизатора, то полученный строб wrx как раз то что нужно для входов разрешения внутренней логики. Его период 2 клока внутренней частоты. Эту же частоту подаем на клоковые входы внутренней логики ПЛИС.
С сигналом rd думаю можно поступить аналогично. Тактируем входной регистр, далее на два синхронизатора. Так как основная задача читать внутренне ОЗУ ПЛИС, подаем его на вход разрешения чтения двухпортовой памяти. Клок при чтении опять же внутренний, тот же что и при записи. С регистрами для чтения вроде бы тоже не должно возникнуть сложностей. Сейчас регистры, которые необходимо читать, выбираются через CASE. Перебирается адрес. Адрес храним в регистре. В зависимости от адреса на шину данных выставляем данные соответствующего регистра. Шину на выход держим опять же сигналом rd.
Для данных и адреса при записи синхронизаторы думаю ни к чему. Согласен с Вашей мыслью, что метестабильного состояния здесь быть не должно. Данные при чтении с того же ОЗУ выставятся сами при условиях, описанных выше. Держим шину данных на выход в течениии длительности rd.
Остается лишь вопрос с регистром для хранения адреса чтения. Нельзя ли использовать один и на запись и на чтение, а тактировать его замешанными между собой wr и rd? !wr or !rd. В рекомендациях по правильному описанию проектов ведь допускается пропускать клок через комбинаторную логику, использующую два входа.

Завтра попробую откорректировать проект и посмотреть результат. Полученный код выложу.

Сообщение отредактировал DENth - Sep 3 2013, 15:06

С чтением всегда проблем больше. Приходится играться с таймингами МК. Часть чтения для начала такая:



Последовательность при чтении: защелкивание адреса по bls -> выработка rdx -> выставление по адресу addr_rx данных на шину data_rd. На все это МК дает время не больше чем toeloeh, которое можно (и нужно) регулировать битами WAITOEN и WAITRD. Пробуйте.

Можно подробнее о том, как была решена эта задача?