Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вопрос по Multibit Domain Crossing
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
lim
Вообщем почитал тут статью по передаче данных между асинхронными доменами.
Многое применил. Но вот пока одну задачу не могу решить - как сделать!

Вообщем, задача такова.
Частоты в передаваемом и принимаемом доменах одинаковые, но асинхронные,
т.е. есть сдвиг по фазе. А именно из FPGA данные выдаются на DAC ( ЦАП).
И хоть FPGA и DAC тактируются от одного генератора - учитывая разницу в разводке,
да и внутри DAC получается задержка. Вообщем из DAC выдаётся частота, к которой
нужно привязать данные из FPGA. Частота эта - высокая, ну в проекте есть ещё только удвоенная,
т.е. фактически скорость выдачи данных на ЦАП в два раза ниже тактовой частоты работы проекта.
Если бы частота выдачи данных была бы значительно ниже тактовой, то тут пути имеются,
а так что-то ничего не придумывается.
Вообще есть ли решение, если тактовая частота проекта всего лишь в два раза выше частоты выдачи данных,
или же нужно обязательно повышать тактовую частоту ?

Буду особенно признателен, за пример, приведённый, на Verilog, или какие-нибудь ссылки на них и т.д.

С Уважением,
Игорь
murmel1
1) В вашем случае не совсем верно понятие "асинхронные". Ведь сдвиг фазы между источником и ПЛИС одинаков, более того - известен заранее. IMHO, вся задача сводится к подбору tco/tsu/th (см.).
2) В большинстве случаев когда нужно передать данные между кусками проекта с разными тактовыми частотами, достаточно применять DUAL-CLOCK FIFO. Обычно на более глубокое изучение вопроса (какая частота чаще, и т.д.) и конкретизацию задачи не стоит даже тратить время. Одно универсальное решение удобнее трех специфичных biggrin.gif
Doka
Цитата(murmel1 @ Jan 9 2009, 00:00) *
1) В вашем случае не совсем верно понятие "асинхронные". Ведь сдвиг фазы между источником и ПЛИС одинаков, более того - известен заранее. IMHO, вся задача сводится к подбору tco/tsu/th (см.).
+1

Цитата(murmel1 @ Jan 9 2009, 00:00) *
2) В большинстве случаев когда нужно передать данные между кусками проекта с разными тактовыми частотами, достаточно применять DUAL-CLOCK FIFO. Обычно на более глубокое изучение вопроса (какая частота чаще, и т.д.) и конкретизацию задачи не стоит даже тратить время. Одно универсальное решение удобнее трех специфичных biggrin.gif
тем более в FPGA есть такая замечательная штука для этого как true DualPort RAM =)

а почитать об этом можно, например тут
http://www.sunburst-design.com/papers/Cumm...002SJ_FIFO1.pdf
http://www.sunburst-design.com/papers/Cumm...002SJ_FIFO2.pdf
cms
Главное правило асинхронных переходов - на каждом такте должен меняться только один сигнал (бит).
Поэтому при клоковом переходе шины данных пропускают через память, счетчики делают в коде Грея, а контрольные сигналы по возможности убирают совсем.
Ну и ставят по два-три триггера для подавления метастабильности на транзитные сигналы. У альтеры есть хорошая аппнота на эту тему, поищите на сайте.

Но в Вашем случае это абсолютно излишне. Пропустите входной клок в ПЛИС через PLL с фиксированным фазовым сдвигом. Если фазовый сдвиг обусловлен только постоянными задержками PCB и DAC, то этого будет достаточно для стабильной работы во всем PVT-диапазоне. Ну и поделите клок выходных данных на два, какие проблемы?
DmitryR
Насколько я понял, DAC и FPGA имеют общую опорную относительно низкую частоту, которую DAC умножает своей PLL и выдает на ПЛИС как опорную, а ПЛИС умножает своей PLL и использует как внутреннюю. В таком случае сдвиг по фазе не известен зараннее - он зависит от того, как установятся PLL. Поэтому проще всего в данном случае поставить банальное FIFO, запись в которое (от логики FPGA) будет разрешена всегда, а чтение (со стороны DAC) будет разрешаться простенькой схемой, которая будет давать ему наполниться до половины. А еще проще - в качестве внутренней частоты ПЛИС использовать частоту, которую выдает DAC: вобще все будет прямо и красиво.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.