SERializer/DESerialiser (SERDES), вручную на ПЛИС Опции

[makc]

Возникла задача реализовать SERDES на VHDL для проекта на базе Spartan-3.
У Xilinx есть интересные примеры реализации (xapp485 и xapp486). Но мне их реализация не нравится + ко всему не очень понятно, на сколько они рабочие (железа, чтобы можно было их попробовать у меня сейчас нет).
Попадались-ли кому-нибудь другие реализации SERDESов в виде статей/HDL-описаний (без использования встроенных в FPGA блоков SERDES)?
Прежде чем спросить я погуглил, но результаты более чем скромные. Можно сказать, что xapp485 и xapp486 это все то путное, что удалось найти.

[litv]

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

[makc]

Конечно проверялась пять часов целостность данных. Плата и блок питания у меня и так проверенные . Дотошный Вы какой, однако.

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

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

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

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

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

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