Имеются эти два девайса, подключенные один к другому. Тактовая частота ПЛИС равна 50 МГц. Можно заставить работать память на частоте 25 Мгц (данные тогда будут следовать со скоростью 50 Мслов/сек), но это не интересно. Интересно, используя удвоенную тактовую, получить скорость 100 Мслов/с.
Собственно, вопрос: каким образом, не используя FIFO, сопрячь две части схемы (50 и 100 МГц), что бы не было всяких логических состязаний и т.п.

1. ИМХО, без FIFO не получится.
2. Минимально домустимая частота тактирования DDR SDRAM 75МГц.

2. Да, точно. Придётся учетверять.
1. А если учетверять, то на ФИФО будет действительно проще.

А вообще, на сколько на выходе DLL совпадают фронты сигналов одинарной и удвоеной частоты?

Ни насколько, разъехавшиеся будут как попало.

Интересно... на Альтеровском PLL можно фазой выходных клоков рулить.

Позвольте не согласиться

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

Я особо не настаиваю
Просто был опыт когда в проекте с учетверенной и удвоенной частотами, при включении примерно 1 к 20 раз, фазы были разъехавшимися. С тех пор я не экспериментировал, тупо получаю все из нивысшей.
Еще, учетверитель более чувствителен к шумам на входном сигнале, если удвоитель может как-то пережить даже кратковременное пропадание входной тактовой (без принудительного сброса) то учетверитель помирает при мелейших отклонениях. Одна из плат с учетверителем стала вырубаться пару раз в день, в итоге все вылилось во встраивание маленькогго частотомера на учетверенную частоту и в случае отсутствия генерировался сброс. Как оказалось позже на этой плате вместо 3.3В было ~3.1, сейчас склонен думать что причина была в этом.

PS Хотя, конечно незачем мне было так категорично утверждать ...

Был однажды подобный случай, PLL была в виде отдельной микросхемы. Потом правда оказалось, что ее включили не правильно, но случаи разные бывают. Вообще такие вещи должны быть в документации четко указаны.


Были всякие проблемы, и с питанием, и со стабильностью входного сигнала, но если все эти проблемы решить должным образом, то оказывается, что все очень неплохо работает. То есть считать выходные частоты синхронными можно.

Если в качестве учетверителя используется выход FX, а в качестве удвоителя - 2X - то имеют право быть разъехавшимися. А 1x и 2x выходы строго синфазны.

Вообще, Спартан-2 - не лучший выбор для контроллера ДДР.
В Спартане-2 нельзя регулировать фазовый сдвиг генерируемого ДЛЛ клока.
Что выливается в практическую невозможность застробировать данные при чтении, которые идут на 200 МГц. Нужный момент строба зависит от длины и нагрузки на шину данных. Кроме того, у этого Спартана нету DDR входных-выходных регистров, что сильно усложняет жизнь разработчику. У Ксилинкса есть Аппнота на ДДР контроллер на базе Спартан-2. Там все работает (разумеется, после правки напильником).

Гораздо лучше подойдет Спартан-3 или 3Е, они же и подешевле будут.

По поводу частоты. Стандарт JEDEC определяет нижнюю частоту ДДР памяти как 84 МГц. Что, однако, не мешает некоторым производителям делать ее еще ниже, например 75. Но нужно четко понимать, что далеко не все ДДР чипы будут работать на 75. Это связано с внутренним PLL чипа памяти. Он просто не рассчитан на низкие (менее 84 МГЦ в общем случае) частоты.

Однако же, и тут существует тайный трюк. Если завести микросхему памяти в отладочный режим (прописыванием определенного бита в конфигурационном слове), то внутренний PLL отключится, позволив памяти работать на низкой частоте. Разумеется, производитель категорически не рекомендует использовать такой способ и не гарантирует временные параметры. Но оно работает.

Абсолютно согласен. Но Спартан-3 не толлерантен к 5 вольтам, а мне нужно было обеспечить совместимость.

Мой коллега вышел из положения, стробируя тактовую ДДР по спаду внутренней CLK, а все остальные сигналы - по фронту. Можно попытаться использовать и такой фокус.

А вот за это, батенька, огромное Вам спасибо. Попробую в первую очередь.

2 Vitёk
Вам нужен поток 100Мслов/сек? Может вам обычным SDRAM'ом ограничиться?

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

Устройство уже собрано.
Собственно, основной обьём DDR памяти стоит на второй ПЛИС (V2-pro), и что бы не плодить номенклатуру, её же я поставил и на Spartan-2. При этом я отдавал себе отчёт, что придётся напрячься, но только один раз.

Да, это так. Даже для одного клока фазы прихода на разные элементы (триггеры) будут разными. Однако этот разбег фаз учитывается самим ISE Place&Route, то есть логически синфазность не нарушается.

А Вы не преувеличиваете?
Одно дело учесть разбег при расчете полученых констрейнов.
А то получается что можно посадить тактовую на локальную линию, и пускай PAR разбег компенсирует (фантастика).

Нет, не преувеличиваю Чтобы убедиться в этом, достаточно внимательно посмотреть временной отчет P&R, а именно, как проверяется выполнение временных ограничений, какие составляющие используются в расчете пути. Все средства P&R, с которыми мне приходилось работать, учитывают разбег фаз между элементами и не только его в процессе расположения и разводки соединений. Причем вне зависимости от того, глобальный ресурс используется под тактовую или нет.

Ну в любом случае, надеятся что разбег на глобальной линии систавит менее 0.7нс (для Spartan2) не стоит, а использовать локальную линию в качестве тактовой для хотя-бы мало-мальского синхронного автомата просто самоубийство (можно разбег и в 5нс получить).

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

Ну смотите, получили Вы разбег на локальной линии ~3нс, максимальный период для этой частоты период Вам выдаст PAR, а минимальный путь в этом частотном домене прийдется искать в ручную и смотреть не меньшне ли он этих самых 3нс (при желании можно задержку до тактового учитывать, но это уж черезчур геморойно). Повторять это при каждой итерации, занятие не для слабонервных.
Конечно ничего не поделаешь когда глобалов не осталось, но это уже игра в рулетку получается.
Или Вы знаете путь проще?

Если я правильно понял, то здесь речь идет об анализе минимальных задержек. Если это так, то и этот процесс выполняется P&R автоматически, то есть вручную за этим следить также не требуется. P&R учтет все автоматически. То есть P&R всегда рассматривает как худший, так и лучший случай. Например, Actel Timing Analyzer предоставляет возможность анализа как максимальных задержек, так и минимальных. Кстати, например, для семейства Actel ProASICPlus разбег фазы тактового сигнала в 3-5 нс, даже при использовании глобальной цепи, совершенно нормальное явление

Вот тут я с Вами не согласен, ничего он не учтет (по крайней мере для Xilinx), просто скажет какой разбег получился, а дальше думай сам ...
Ползание по отчетам Timing Analyzer требует тучу времени, хотя конечно имеется констрейн MAXSEW но его значение приходится ставить от балды (по описанным выше причинам).

То есть Вы хотите сказать, что P&R способен учесть заданные пользователем временные ограничения (констрейны), постараться выжать максимальную частоту работы схемы, но при этом совершенно не способен выполнить гораздо более элементарную задачу по учету разбега клока, да еще и со всеми известными параметрами. Странно как-то получается. Не находите?

Чем ситуация лучше (в отношении разбега фаз клока) при использовании глобальной цепи? Там разбег тоже не учитывается?

Вообщем, могу сказать только одно, работая с Xilinx, ошибок, связанных с разбегом фаз клока на разных элементах, не встречал ни разу, связанных с задержкой путей, сколько угодно. Встречал такое при работе с Actel, но это единичные случаи, да и P&R у Actel гораздо менее интеллектуальный.

Именно, и не вижу ничего странного как и "более элементарную задачу по учету разбега клока" и компенсации его в коротких путях, но это мы уже начали воздух сотрясать.
Ситуация с глобалом лучше тем что разбег больше 1нс не будет (да и то на разных сторонах кристалла), у соседних слайсов он гораздо меньше будет, ну а в случае даже со сдвиговым регнистром минимальный путь по локальной линии между соседними слайсами будет ближе к 1нс.
Далее, откуда такая уверенность что у Вас не было проблем из-за разбега?
У меня на в разных проектах имелись модули у которых тактовая была на локале, это самые глючные модули в смысле непредсказуемости их работы при очередной итерации разводки проекта. Например, счетчики перестают считать и т.п. , при этом HDL модулей не меняется. Ситуация обостряется с ростом процента заполненности кристалла (приходилось постоянно мудрить с усилием и настройками PAR). При этом ест-но все констрейны выполняются, а вот MAXSKEW как правило меньше 2нс не выходит.