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

[Intekus]

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

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

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

[gutzzz]

а что за озу, если не секрет

[Maverick]

Какая используется ПЛИС?

[Intekus]

ПЛИС Virtex5
ОЗУ ISSI Pipelined 'No wait' state bus SRAM серия IS61NLP512
ИМХО, эти сведения не обязательны, интересно общее решение для таких случаев.
Видел демо проект от Xilinx - именно контроллер ZBT / 'No wait' state bus SRAM; в нём просто прописана пара OFFSET, но при этом наружу выведена двойная (указано, что именно в случае pipeline) частота, зачем - скажу честно, не разобрался. Ещё там есть петли тактового сигнала для автоматической компенсации задержки DLL'ью - но у нас в разводке подобных вещей предусмотрено не было.

[des00]

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

[Intekus]

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

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

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

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

[gutzzz]

А интересно кто-нибудь вообще делает подобные рассчеты?
Насколько они реалистичны?

[Intekus]

То, что сказал des00 (констрейнты на source synchronous / system synchronous - интерфейсы)- рассчитывают, видел на сайте Альтеры документы, в которых даже усредняли какие-то задержки, вычисленные временным анализатором и потом где-то прописывали полученную фазу.
Вот тот документ http://www.fpga.com.cn/freeip/zbt_xilinx.pdf на стр. 5 и 6 рассчитали даже нагрев корпусов от токов при состязаниях на шине; а вот расчётов фазы сигналов управления направлением - пока не нашёл.

[VladimirB]

ПЛИС Virtex5
ОЗУ ISSI Pipelined 'No wait' state bus SRAM серия IS61NLP512
ИМХО, эти сведения не обязательны, интересно общее решение для таких случаев.
Видел демо проект от Xilinx - именно контроллер ZBT / 'No wait' state bus SRAM; в нём просто прописана пара OFFSET, но при этом наружу выведена двойная (указано, что именно в случае pipeline) частота, зачем - скажу честно, не разобрался. Ещё там есть петли тактового сигнала для автоматической компенсации задержки DLL'ью - но у нас в разводке подобных вещей предусмотрено не было.

У нас используется CY7C1460AV33 ZBT SRAM, подключённая к Spartan3A, контроллер самописный, констреинты только на частоту клока заданы, клок подаётся с ПЛИС и всё нормально работает на частоте 133МГц. DLL не используется.
Разводка тоже не больно хорошо сделана - разве что дорожки до памяти короткие не более 60-70мм.

А у вас пятый виртекс (сравните ради интереса задержки в IOB-ах спартана и виртекса). ИМХО проблемы, если и возникнут, то только если память далеко от ПЛИС и волновые сопротивления не согласованы - тогда отражения могут всё испортить. Задержки в дорожках составляют 67 пс/см и будут существенны если память значительно удалена от ПЛИС.

[CaPpuCcino]

У нас используется CY7C1460AV33 ZBT SRAM, подключённая к Spartan3A, контроллер самописный, констреинты только на частоту клока заданы, клок подаётся с ПЛИС и всё нормально работает на частоте 133МГц. DLL не используется.
Разводка тоже не больно хорошо сделана - разве что дорожки до памяти короткие не более 60-70мм.

я то же самое делал с точностью до модели ZBT(кажись), но на Virtex-2Pro(и дорожки чуть покороче). тоже считаю, что всё норм. д.б. без особых фокусов. правда, на счёт 200МГц не могу быть уверен(зуб не дам) - надо расчёты поднять, где-то валялись.

[des00]

То, что сказал des00 (констрейнты на source synchronous / system synchronous - интерфейсы)- рассчитывают, видел на сайте Альтеры документы, в которых даже усредняли какие-то задержки, вычисленные временным анализатором и потом где-то прописывали полученную фазу.

это пока таймквеста не было, как он появился все просто. Задаем задержки, параметры памяти, и времянку по tsu/th для памяти и плис соответственно.

ЗЫ. Пример подключения асинхронной памяти есть у меня в статье, но она будет напечатана только в декабре. На примере альтеры, если вам уж сильно горит, можно списаться.

[Intekus]

Всем большое спасибо за ответы; расстояние между ПЛИС и памятью небольшое, сантиметров 5-7.
Скоро вернусь к этой задаче, пока всё равно не понял, чем же тактировать OE для ПЛИС и RAM, так что, наверное, буду делать аккуратную по времянкам модель памяти и отлаживать подключение на ней.

[Intekus]

Что-то я закопался. Расписал акууратную по времянкам (причём выходные задержки ПЛИС пока поставлены меньше 1 нс с потолка) модель в Modelsim - пока получается, что на 200 МГц с такими задержками память работать не будет в принципе. Если у кого есть примеры рассчётов (и, особенно, констрейнтов под Xilinx) - прошу поделиться.

[CaPpuCcino]

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

почему?

[DmitryR]

Вообще мне кажется, что при наличии пятого виртекса, у которого есть линии задержки в лапах, следует поступить так:
1. Сделать дизайн, где OE выдается синхронно с остальными сигналами.
2. Сделать временную модель, запустить симуляцию и посмотреть ширину участка, на котором происходит состязание шины.
3. Задержать в буферах все сигналы, кроме OE на эту величину.

[CaPpuCcino]

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

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

[Intekus]

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

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

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

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

[CaPpuCcino]

Промоделирую с реальным контроллером - скажу точнее; интуитивно казалось, что да.

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

[DmitryR]

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

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

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

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

[CaPpuCcino]

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

ага, понятно, просто не посмотрел на абсолютные значения.

Надо между чтением и записью просто пропускать такт, и все будет хорошо.

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

[Intekus]

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

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

Пропускать не хотелось, вот поэтому и была изначальная идея тактировать OE отдельным сдвинутым сигналом.

[DmitryR]

А тут вы его хоть как сдвигайте. Вам надо, чтобы за такт:
1. Сигнал OE вышел из ПЛИС.
(провода не учитываем)
2. Память переключилась
3. Данные дошли обратно до ПЛИС прежде, чем вы выключите OE, потому что в этот момент (выключения OE) состояние шины становится непредсказуемым, hold у этой памяти не специфицирован.

Так вот, в сумме эти три цифры дают (для LVCMOS33 24ma и самого быстрого грейда в ПЛИС) 1.55+3.1+0.62=5.27ns. Еще есть ненулевая ширина фронта - и вы получаете 6 нан, то есть 166 МГц.

[CaPpuCcino]

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

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

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

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