Уважаемое сообщество! Есть следующий вопрос по взаимодействию ПЛИС и МК:
Имеем ARM7 LPC2468 и ПЛИС Cyclone 2. ПЛИС подключена к контроллеру внешней памяти ARMа. Данный интерфейс предназначен для работы с асинхронной памятью. Относительно ПЛИС сигналы Write, Read с МК асинхронны. На МК и ПЛИС поступает частота с единого генератора - 12Мгц, но в МК она перемножается до 72МГц - частота ядра. Длительность сигналов контроллера внешней памяти зависит от этой частоты. Частота 72МГц на ПЛИС не идет. Вопрос - как обеспечить максимальное быстродействие между МК и ПЛИС?

Read и Write пропускаю через два последовательных триггера для исключения метастабильного состояния. Но как поступать дальше? Использовать их для тактирования внутренних цепей ПЛИС для записи или чтения состояния регистров и памяти вроде как нельзя. Нужен явный клок. Но его нет с МК.

Сейчас получилось сделать так: стробирую эти сигналы внутренней частотой 72МГц, сформированной на PLL ПЛИС. Получаю сигнал длительностью один период частоты 72МГц. Этот сигнал подаю как сигнал разрешения на внутренние цепи. А клок 72МГц как клок на эти же цепи. Все работает. Но если в МК ускорять работу по этому интерфейсу, то всё перестает работать. Видимо пока я синхронизирую Read, Write внутри ПЛИС, МК уже захлопывает данные, а ПЛИС их еще не успела выставить. Стробировать большей частотой не получается, начинает ругаться временной анализатор.

Как сделать правильно?

Во-первых, лично я для исключения метастабильности использую защелкивание входных сигналов только на один триггер. До сих пор не подводило. Поэтому считаю, что два последовательных триггера - это лишняя перестраховка.
Во-вторых, у Вас частота данных на борту МК и частота защелкивания входнух данных на ПЛИС - одинаковые. Поэтому, если Вы защелкиваете Write, также и защелкивайте DATA_IN, а уже потом работайте с результатом в домене 72 МГц.

а что значит «ускорять»? И что именно перестает работать? Вы пишите данные с МК а потом забирает результат с ПЛИС? Какая латентность этой обработки? И честно гоаоря не вижу криминала стробы чтения записи подать на входы глобал клоков, а потом передать из на обработку в другой плисовый клоковый домен через фифо например. Также неясно ,что вы там наворотили, что уже на 72 мгц ругается анализатор.

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

Правильный вопрос. Что значит "перестает работать"?
Я так понял - при однократном WRITE с МК - ПЛИС принимает данные корректно. При зацикливании этого процесса на МК - ПЛИС принимает абракадабру/нули/единицы/предыдущее значение/... Подчеркните нужное.

Два триггера - это правильно.
А дальше усть варианты. Если ПЛИС значительно быстрее, чем МК, то с точки зрения МК все будет укладываться в один цикл "записи". А вот если их скорости примерно одинаковы, то тогда при чтении надо будет переходить к "пакетному" режиму. Т.е. при первом чтении в ПЛИС запишется адрес и перетактируются данные из памяти в выходной регистр, а при втором - данные уйдут в МК. И далее, если сделаете пост-инкремент адреса, то можно будет делать чтение берстом (пакетом)...
А более подробно - у меня на сайте "Краткий Курс", раздел CDC... Кстати и Вам, olegras тоже рекомендую...

Читал, и постоянно пользуюсь. Насчет двух триггеров - я ведь не отрицаю и полностью подтверждаю. Я лишь говорю что если частоты двух доменов равны (а у DENth они равны) - то достаточно одного триггера. Но он должен быть! Во всяком случае, этот факт проверен много раз на практике на частотах до 100 МГц включительно.

Частоты одинаковы, но источники частот разные. Не знаю - можно ли их считать синхронными друг другу. Обе частоты формируются PLL. Но одна в МК, другая в ПЛИС. Если завести обе частоты в SignalTap квартуса, то выглядят они синхронными друг другу, но можно ли достоверно сказать, что это так? Во-вторых в документации на МК нет временной диаграммы, связывающей частоту ядра с времянками чтения и записи по интерфейсу внешней памяти. Из-за этого всего не ясно - когда защелкивать входные данные и когда должны быть выставлены выходные для их правильного защелкивания в МК?

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

Да заявы пошли не шуточные. Ну так на всякий случай сообщаю что флопов должно быть как минимум два.

Под ускорением подразумеваю увеличение количества циклов чтения/записи со стороны МК за единицу времени. В ARMе сделано так, что при этом длительности сигналов write, read уменьшаются с увеличением частоты обращений. Зависят от неких величин, которые приведены в табличке выше.

Стробы записи и чтения я как раз-таки завел на глобал клоки. При 72МГц анализатор пока не ругается, но при увеличении частоты стробирования начинаются проблемы. Код попробую подготовить, чтобы стало более понятнее.



Нет, дело не в однократном-многократном. Проблема именно в общих принципах правильного построения подобного взаимодействия.



Считаем, что нужно построить систему с одним циклом записи, чтения. При пакетном производительность упадет в два раза? Это крайне не желательно.
Ваш курс по описанию временных ограничений с удовольствием читал и постоянно заглядываю при случае. Пожалуй, самое толковое, что есть в рунете по данной теме. Спасибо!

Сообщение отредактировал DENth - Sep 1 2013, 09:14

Конечно не ругается - ему ведь неизвестны времянки на СРАМ интерфейсе ЛПЦ

Не могли бы вы подсказать, как анализатору их сообщить? А то у меня как и у анализатора видимо проблемы с этим =)

Зря Вы иронизируете. Давайте разберемся. Может мы говорим о разных вещах.
Есть входные данные. Пусть будут write_in и data_in. Для простоты остальные сигналы не рассматриваем.
Код на VHDL:

Есть сигналы

Пример первый - без защелки

Пример второй - с одной защелкой

Пример третий - с двумя защелками

Я говорю про второй пример. Использую на практике несколько лет. На частотах до 100 МГц включительно. Еще ни разу не сбоило. При одинаковых частотах входного и внутреннего доменов - стабильность (и корректность) от сдвига фаз не зависит. Попробуйте сами.

DENth я похожую задачу делал для связки ЦСП от TI со Спартаном 3. Работало на частоте шины (между ними) 85 МГц. Представьте свою часть кода.

Вау. А на данные то зачем синхронизаторы ставить?????

> от сдвига фаз не зависит
А вы их сдвигали?

А Вы поставьте и проверьте. А сдвиг фаз смотрел на осцилле. В разных проектах и в разных реализациях - сдвиг был ессно разный. И вообще я поднял этот вопрос в ответ на "Видимо пока я синхронизирую Read, Write внутри ПЛИС, МК уже захлопывает данные, а ПЛИС их еще не успела выставить". Если защелкивать только WRITE (при чтении с МК) - так и будет. Но у DENth стробы заведены на клоковые входы. Значит он (предполагаю) принимает и передает данные по фронтам этих стробов, и значит у него проблема в другом. Выложит код - посмотрим.
Насчет двух флопов - я ведь не против. Ставьте хоть 15.