Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SERializer/DESerialiser (SERDES)
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
makc
Возникла задача реализовать SERDES на VHDL для проекта на базе Spartan-3.
У Xilinx есть интересные примеры реализации (xapp485 и xapp486). Но мне их реализация не нравится + ко всему не очень понятно, на сколько они рабочие (железа, чтобы можно было их попробовать у меня сейчас нет).
Попадались-ли кому-нибудь другие реализации SERDESов в виде статей/HDL-описаний (без использования встроенных в FPGA блоков SERDES)?
Прежде чем спросить я погуглил, но результаты более чем скромные. Можно сказать, что xapp485 и xapp486 это все то путное, что удалось найти. sad.gif
DmitryR
Для начала было бы IMHO неплохо узнать, какая вам нужна скорость, а также чем не приглянулись приведенные xapp.
makc
Цитата(DmitryR @ Apr 4 2008, 16:17) *
Для начала было бы IMHO неплохо узнать, какая вам нужна скорость, а также чем не приглянулись приведенные xapp.


Начну с конца: мне не нравятся решения, которые плохо объяснены. Времени было мало, разбираться в коде без коментариев и при этом сильно оптимизированном довольно сложно. Кроме того, не известно, на сколько они работоспособны в железе (в моделировании они функционируют). Вот этим и не понравились упомянутые xapp'ы. Что касается скорости, то нужно не менее 200 Мбит/с из раcчета четырех линий. Т.е. не менее 50 Мбит/с на линию.
dmitry-tomsk
Цитата(makc @ Apr 4 2008, 15:32) *
Начну с конца: мне не нравятся решения, которые плохо объяснены. Времени было мало, разбираться в коде без коментариев и при этом сильно оптимизированном довольно сложно. Кроме того, не известно, на сколько они работоспособны в железе (в моделировании они функционируют). Вот этим и не понравились упомянутые xapp'ы. Что касается скорости, то нужно не менее 200 Мбит/с из раcчета четырех линий. Т.е. не менее 50 Мбит/с на линию.

SERDES, даже аппаратный - это обычный сдвиговый регистр. Зачем ещё там какие-то xapp нужны?
makc
Цитата(dmitry-tomsk @ Apr 4 2008, 16:38) *
SERDES, даже аппаратный - это обычный сдвиговый регистр. Зачем ещё там какие-то xapp нужны?


В вышеупомянутых XAPPах используется уплотнение 28:4 или 35:5: т.е 28-и разрядная шина сериализуется и передается по четырем LVDS-линиям. Для этой передачи исходная тактовая частота умножается в 3.5 раза. Тут-то и начинаются приключения. Так что обычным сдвиговым регистром это сделать не получится. При этом интерфейс получается Source-Synchronous, т.е. вместе с данными передается и тактовый сигнал, который используется на принимающей стороне для получения данных. При этом тактовый сигнал имеет частоту = исходной частоте передачи данных.
litv
Я их сделал на плате со спартаном3е. Оба работают. Правда были какието легкие ошибочки в ихних файлах, даже синтаксические.
Передатчик работал на приемник по витым парам сантиметров 60.
Описания как это и принято у ксайлинкса туманные. Но идея хорошая, так как спартан 3е не имеет таких serdes как виртекс 4. И плата работала нормально часов 5. Частота была входная тактовая 50 МГц - т.е. 350 МГц на линиях так как по двум фронтам .
Вот на виртексе 4 я работал с xilinx xapp lvds - там гораздо хуже описание. Пришлось самому сделать.
makc
Цитата(litv @ Apr 4 2008, 17:07) *
Я их сделал на плате со спартаном3е. Оба работают. Правда были какието легкие ошибочки в ихних файлах, даже синтаксические.
Передатчик работал на приемник по витым парам сантиметров 60.


Приятная новость. smile.gif

Цитата
Описания как это и принято у ксайлинкса туманные. Но идея хорошая, так как спартан 3е не имеет таких serdes как виртекс 4. И плата работала нормально часов 5. Частота была входная тактовая 50 МГц - т.е. 350 МГц на линиях так как по двум фронтам


Проверялась-ли при этом каким-либо способом целостность переданных по интерфейсу данных?
Или просто простояла плата 5 часов и была выключена?
DCM'ы на принимающей стороне lock не теряли?

Цитата
Вот на виртексе 4 я работал с xilinx xapp lvds - там гораздо хуже описание. Пришлось самому сделать.


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

Хотел еще вот что спросить: блоки SERDES'ов из упомянутых XAPP размещались согласно их рекомендациям (по правой стороне кристалла) или "куда легли, туда легли"?
litv
07.gifКонечно проверялась пять часов целостность данных. Плата и блок питания у меня и так проверенные wink.gif . Дотошный Вы какой, однако. По размещению уже точно не помню, что подбирал.
Вроде в ucf только временные требования.
DmitryR
Цитата(makc @ Apr 4 2008, 16:32) *
Что касается скорости, то нужно не менее 200 Мбит/с из раcчета четырех линий. Т.е. не менее 50 Мбит/с на линию.

Тогда вам те xapp на самом деле не нужны, потому что захватить 50 мегабит даже на Спартане - дело тривиальное, сдвиговый регистр на самом деле. Там же описываются скорости на порядок выше и поэтому все несколько хитрее.
makc
Цитата(litv @ Apr 4 2008, 17:30) *
07.gif Конечно проверялась пять часов целостность данных. Плата и блок питания у меня и так проверенные wink.gif . Дотошный Вы какой, однако.


Приходится быть дотошным: очень уж не люблю вероятностную работу изделия, когда то работает (когда стоишь рядом), то дурит (когда отойдешь). wink.gif

Цитата
По размещению уже точно не помню, что подбирал.
Вроде в ucf только временные требования.


Думаю, что временных требований должно хватать. Размещение обычно нужно подбирать и задавать, чтобы удовлетворить временные требования.

Большое спасибо за информацию! a14.gif


Цитата(DmitryR @ Apr 4 2008, 17:49) *
Тогда вам те xapp на самом деле не нужны, потому что захватить 50 мегабит даже на Спартане - дело тривиальное, сдвиговый регистр на самом деле. Там же описываются скорости на порядок выше и поэтому все несколько хитрее.


Не совсем так просто: если брать 50Мбит/с на линию, то регистр придется тактировать на частоте 50 МГц. И эту же частоту (в самом простом варианте) нужно будет передавать на приемный конец для синхронизации. А частота получается не маленькая. При использовании этих XAPPов нужно будет передавать куда меньшую частоту, около 30 МГц и это куда проще.
Но самое главное в другом: цифра 200 - это не окончательная величина, она может корректироваться в большую сторону, если возникнет необходимость. Т.е. имеет смысл сразу закладывать расширяемое решение, чем потом все переделывать.
dmitry-tomsk
Цитата(makc @ Apr 4 2008, 17:42) *
Приходится быть дотошным: очень уж не люблю вероятностную работу изделия, когда то работает (когда стоишь рядом), то дурит (когда отойдешь). wink.gif
Думаю, что временных требований должно хватать. Размещение обычно нужно подбирать и задавать, чтобы удовлетворить временные требования.

Большое спасибо за информацию! a14.gif
Не совсем так просто: если брать 50Мбит/с на линию, то регистр придется тактировать на частоте 50 МГц. И эту же частоту (в самом простом варианте) нужно будет передавать на приемный конец для синхронизации. А частота получается не маленькая. При использовании этих XAPPов нужно будет передавать куда меньшую частоту, около 30 МГц и это куда проще.
Но самое главное в другом: цифра 200 - это не окончательная величина, она может корректироваться в большую сторону, если возникнет необходимость. Т.е. имеет смысл сразу закладывать расширяемое решение, чем потом все переделывать.

Частоту легко передавать выходным DDR триггером. На передний фронт 0, на задний - 1, вот и получаем сдвиг по фазе 90 относительно данных.
rv3dll(lex)
Цитата(litv @ Apr 4 2008, 17:07) *
.
Вот на виртексе 4 я работал с xilinx xapp lvds - там гораздо хуже описание. Пришлось самому сделать.


на нем без констрейнов размещения удалось сделать на 250 мегагерц на триггерах

если нужен
12 разрядный приёмник то он делается на встроенных десериалайзерах и DCM - 400 мегагерц работает больше не пробовал.
makc
Цитата(rv3dll(lex) @ Apr 7 2008, 08:09) *
на нем без констрейнов размещения удалось сделать на 250 мегагерц на триггерах

если нужен
12 разрядный приёмник то он делается на встроенных десериалайзерах и DCM - 400 мегагерц работает больше не пробовал.


Мне нужно без использования аппаратных блоков SERDES.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.