Собираются идеи по приему данных с интерфейса:
1. 4 бита и клок. При этом данные выставляются по фронту и спаду клока (DDR).
2. Максимальная частота клока - 150 МГц, но если не получится, то можно до 100 МГц опустить, но не желательно.
3. Нужно опционально двигать линии данных в пределах 1-10 нс, с шагом 1-2 нс.
Для пункта 3 пока что рассматриваются любые варианты, даже не рекомендуемые для широкого применения, типа задержки на внутренней логике. Внешние решения тоже рассматриваются, только не линии задержки за $10 / канал.
Выравнивание данных осуществляется пользователем "на глаз" по приему тестовых последовательностей, так что абсолютная точность задержки не важна, нужна просто возможность подвигать все относительно клока.
После приема ПЛИС будет восстанавливать из этого байтовый поток, выполнять простую фильтрацию и передавать все это на внешний интерфейс. Сильно много ресурсов для этого не нужно, так что чем дешевле решение, тем лучше.
Идеи?
Полная версия этой страницы: Идеи по приему данных с 4-бит интерфейса
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(ataradov @ May 9 2017, 09:53) 
Собираются идеи по приему данных с интерфейса:
1. 4 бита и клок. При этом данные выставляются по фронту и спаду клока (DDR).
2. Максимальная частота клока - 150 МГц, но если не получится, то можно до 100 МГц опустить, но не желательно.
3. Нужно опционально двигать линии данных в пределах 1-10 нс, с шагом 1-2 нс.
Для пункта 3 пока что рассматриваются любые варианты, даже не рекомендуемые для широкого применения, типа задержки на внутренней логике. Внешние решения тоже рассматриваются, только не линии задержки за $10 / канал.
Выравнивание данных осуществляется пользователем "на глаз" по приему тестовых последовательностей, так что абсолютная точность задержки не важна, нужна просто возможность подвигать все относительно клока.
После приема ПЛИС будет восстанавливать из этого байтовый поток, выполнять простую фильтрацию и передавать все это на внешний интерфейс. Сильно много ресурсов для этого не нужно, так что чем дешевле решение, тем лучше.
Идеи?
1. 4 бита и клок. При этом данные выставляются по фронту и спаду клока (DDR).
2. Максимальная частота клока - 150 МГц, но если не получится, то можно до 100 МГц опустить, но не желательно.
3. Нужно опционально двигать линии данных в пределах 1-10 нс, с шагом 1-2 нс.
Для пункта 3 пока что рассматриваются любые варианты, даже не рекомендуемые для широкого применения, типа задержки на внутренней логике. Внешние решения тоже рассматриваются, только не линии задержки за $10 / канал.
Выравнивание данных осуществляется пользователем "на глаз" по приему тестовых последовательностей, так что абсолютная точность задержки не важна, нужна просто возможность подвигать все относительно клока.
После приема ПЛИС будет восстанавливать из этого байтовый поток, выполнять простую фильтрацию и передавать все это на внешний интерфейс. Сильно много ресурсов для этого не нужно, так что чем дешевле решение, тем лучше.
Идеи?
А в чем проблема? частота 150 МГц довольно низнакая (я реально принимал 250 МГц 14 бит с АЦП). Разрядность невысокая. Выравнивание можно и даже нужно замутить на встроенных блоках задержки (если Xilinx). Так что проблем быть не должно если конечно плата разведена более или менее нормально.
Посмотрите application note от Xilinx: xapp524,xapp855,xapp856,xapp860,xapp866,xapp585,xapp774,xapp1064,xapp1071,
потом можно поискать поиском по форуму по названиям xapp-ов, было уже множество тем с разбором приёма такого типа данных.
Даже статья на хабре есть - https://habrahabr.ru/post/313692/
потом можно поискать поиском по форуму по названиям xapp-ов, было уже множество тем с разбором приёма такого типа данных.
Даже статья на хабре есть - https://habrahabr.ru/post/313692/
Цитата(ataradov @ May 9 2017, 09:53)
3. Нужно опционально двигать линии данных в пределах 1-10 нс, с шагом 1-2 нс.
Для пункта 3 пока что рассматриваются любые варианты, даже не рекомендуемые для широкого применения, типа задержки на внутренней логике. Внешние решения тоже рассматриваются, только не линии задержки за $10 / канал.
Выравнивание данных осуществляется пользователем "на глаз" по приему тестовых последовательностей, так что абсолютная точность задержки не важна, нужна просто возможность подвигать все относительно клока.
Идеи?
Для пункта 3 пока что рассматриваются любые варианты, даже не рекомендуемые для широкого применения, типа задержки на внутренней логике. Внешние решения тоже рассматриваются, только не линии задержки за $10 / канал.
Выравнивание данных осуществляется пользователем "на глаз" по приему тестовых последовательностей, так что абсолютная точность задержки не важна, нужна просто возможность подвигать все относительно клока.
Идеи?
Если альтера, то прямо для Вас
Спасибо всем, буду читать аппноты. Проблема тут одна - я нуб с ПЛИС, поэтому думаю в терминах стандартной логики, и спец. блоки упустил из виду.
К стати, этот форум не доступен из внутренней сети Microchip, так как домен помечен как зловредный в OpenDNS.
К стати, этот форум не доступен из внутренней сети Microchip, так как домен помечен как зловредный в OpenDNS.
Возможно придется городить что-то типа сетки частот со сдвигами и выбирать по какой из них щелкать данные для каждого бита, а потом через фифо пересинхронизировать.
не наврал, дадут дискретность даже лучше.
Цитата(Anton1990 @ May 9 2017, 11:14)
А в чем проблема? частота 150 МГц довольно низнакая (я реально принимал 250 МГц 14 бит с АЦП). Разрядность невысокая. Выравнивание можно и даже нужно замутить на встроенных блоках задержки (если Xilinx). Так что проблем быть не должно если конечно плата разведена более или менее нормально.
встроенные блоки задержки дают максимальную задержку в 2-3 наны. 32 тапа по (кажись) 80 пикосекунд
когда то собирал модуль автоподстройки данных от ацп для ддр и кюдр интерфейсов. но там черт ногу сломит в коде ))). да и не помню уже особо тонкостей логики функционирования
автору смотреть юзер гайды по ISERDESE b IODELAY
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.