Подключение синхронной SRAM, помогите разобраться с задержками и избежать состязаний на шине Опции

[Intekus]

Подключаем к ПЛИС внешнее синхронное ОЗУ. Частота довольно высокая (хотим довести до номинальных для микросхемы 200 МГц). Выводы двунаправленные.
Как я поинмаю, принципиально различных с точки зрения времени сигналов на ОЗУ приходит 3: адрес+данные на ОЗУ, тактовый и разрешение Z-состояния.
Без разрешения Z-состояния, ещё можно было бы применить способ "на коленке": подвигать фазу тактового с ПЛИС относительно данных и оставить среднее между 2 точками "срыва" (где память перестаёт правильно читаться / писаться). Но с управлением Z-состоянием приходится вначале прикинуть параметры на диаграммах.
Пока у меня получаятся следующие соотношения:
(Пример для стыка запись-чтение)

Рабочий фронт тактового внутри ПЛИС
--Время защёлкивания данных в регистрах и появления их на ножках ПЛИС, параллельно отсчитываемое от переключения регистра управления выводами время на выход выводов данных ПЛИС из Z-состояния
На выводах данных ПЛИС - записываемые данные
--Задержка на дорожках платы
Setup-время данных на выводах ОЗУ
--Приход тактового на вход ОЗУ
Hold-время данных на выводах ОЗУ
--Приход на ОЗУ сигнала управления Z-состояниями (так как минимальное время от его прихода до переключения направления выводов - 0)
Задержка на перевод выводов данных ОЗУ из Z-состояния на выход либо отсчитываемое от прихода тактового на ОЗУ время появления годных данных на выходе - что раньше закончится
--Считанные данные на выходах ОЗУ
Задержка на дорожках платы
--Время предустановки для регистров ПЛИС
(Здесь параллельной веткой - время от ножек до регистра и после него - следующий фронт тактового внутри ПЛИС)
--Время выдержки для регистров ПЛИС
Перевод выводов ПЛИС в Z-состояние при необходимости.

Это частично, в управлении двунаправленностью упомянуты не все события.
Соответственно, фаза выходного тактового ПЛИС будет определяться временем прихода тактового на ОЗУ минус задержка на дорожках, минус время выхода тактового из ПЛИС. Кстати, там ещё и ножки не выделенные, а обычные I/O, так развели, так что в достижимости 200 МГц уже есть некоторые сомнения.
Фаза сигналов управления двунаправленностью (для ПЛИС и внешнего - отдельно) - из времён переключения направления.
Разделы по заданию констрейнов прочитал, но сейчас интересует именно расчёт их значений.
В общем, судя по сложности выкладок, похоже, я подхожу к задаче как-то не так - посоветуйте пожалуйста, как правильно сделать / что почитать.

[Intekus]

для альтеры все классически, интерфейс с памятью рассматриваем как System Synchronus Input/Output и соотвественно расчитываем констрейны. Для хилых будет немного по другому, но общие концепции сохраняются.

(Из моего первого сообщения)

Соответственно, фаза выходного тактового ПЛИС будет определяться временем прихода тактового на ОЗУ минус задержка на дорожках, минус время выхода тактового из ПЛИС. Кстати, там ещё и ножки не выделенные, а обычные I/O, так развели, так что в достижимости 200 МГц уже есть некоторые сомнения.

Тактовый для ОЗУ создаётся на ПЛИС, так что у меня как раз случай source-synchronous, разве нет?
Повторюсь: с тактовым более-менее понятно, интересует OE для ПЛИС и для RAM - кто сталкивался, поделитесь: распространено ли решение тактировать их отдельным сигналом со сдвигом фазы?
P. S. Из интуитивных соображений кажется, для максимальной скорости работы фазы изменения OE должны ещё зависеть от того, чтение или запись производится - но такое, в отличие от упомянутого в предыдущем предложении, труднореализуемо и вряд ли даст большой выигрыщ.

[CaPpuCcino]

интересует OE для ПЛИС и для RAM - кто сталкивался, поделитесь: распространено ли решение тактировать их отдельным сигналом со сдвигом фазы?

кстати, а зачем вам ОЕ? там реальная течь получается? есть состязание на линиях?

[Intekus]

кстати, а зачем вам ОЕ? там реальная течь получается? есть состязание на линиях?

Промоделирую с реальным контроллером - скажу точнее; интуитивно казалось, что да. Сразу не стал с ним моделировать, потому что, получалось, каждая подстройка фазы тактового на память - это пересборка, но, видимо, придётся так (пока писал, пришла идея, как вообще всё сделать за 1 прогон).

получается, что на 200 МГц с такими задержками память работать не будет в принципе.
почему?

Так выходило по задержкам; когда сдвигаешь фазу в одну сторону - шли ошибки при переходе R->W, в другую - при W->R, а при среднем значении цикл удавалось сократить только до где-то 6 нс (166 МГц), дальше начинались x-ы.
В общем, спасибо всем за некий приданный импульс - до того моделировал в чисто абстрактных условиях, теперь попробую подключить post-PAR-вариант контроллера.
Косвенно связанный с темой вопрос: как в PlanAhead посмотреть, куда физически по топологии разместился триггер? Вывожу его в PlanAhead'овском schematic. В меню по правой кнопке есть разные "выделить" и "подсветить", и он подсвечивается на общем виде кристалла. Но это буквально пара точек на экране, которую тяжеловато искать каждый раз. А аналога знакомого по Altera 'найти на физической топологии (locate in ChipEditor, вроде бы называлось)', по которой его не только выделит, но и приблизит до какого-то удобного увеличения, я пока не нашёл.

[DmitryR]

Так выходило по задержкам; когда сдвигаешь фазу в одну сторону - шли ошибки при переходе R->W, в другую - при W->R, а при среднем значении цикл удавалось сократить только до где-то 6 нс (166 МГц), дальше начинались x-ы.

И это неудивительно - у памяти bus turnaround (время реакции на OE) 3 наны, с учетом буферов ПЛИС за такт не успеть на 200. Надо между чтением и записью просто пропускать такт, и все будет хорошо.

просто мне казалось, что ОЕ вообще в современных SRAM - вещь факультативная, там вроде бы внутренние схемы выходы отключают самостоятельно при цикле записи.

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

[CaPpuCcino]

И это неудивительно - у памяти bus turnaround (время реакции на OE) 3 наны, с учетом буферов ПЛИС за такт не успеть на 200. Надо между чтением и записью просто пропускать такт, и все будет хорошо.

так и не понял зачем нужно пропускать. главное подтянуть выходной буфер в HZ. делать это можно на том же клоке(фронте), что и фронт захлопывающий данные в ПЛИС, если следующий такт записи в ОЗУ. выходы поднимутся через время примерно равное полупериоду. клок на ОЗУ приходит с задержкой(данные для записи тоже). всё будет зависеть от вр. установки сигнала на регистре OE_fpga + буфер выхода с ПЛИС + страйп. нужно смотреть что получается со временем и уже от этого плясать.

Так вот, в сумме эти три цифры дают (для LVCMOS33 24ma и самого быстрого грейда в ПЛИС) 1.55+3.1+0.62=5.27ns.

UPD сорри я запоздал с постом. теперь понятно.