[Beby 8]

В Spartan-3A опять появилась поддержка LVPECL-3.3V, но только приемной стороны.

Насколько я понимаю, несмотря на то, что для Virtex-E и Spatran-IIE была заявлена поддержка выходного каскада LVPECL, как таковой ее не было. А было предложено решение, как при помоши 3 резисторов превратить пару выходов (очень похожую на LVTTL или LVCMOP) в подобие LVPECL (на то, что это был не чистый LVPECL, указывает некоторое количество мути вокруг ответа на вопрос: "Насколько Xilinx LVPECL, соответствует National Semiconductor LVPECL ?").

 

 

Имеется хитро задуманный модульный комплекс, реализованный на Virtex-E и Spatran-IIE. Несколько шин реализовано с элеккрическим стандартов Xilinx LVPECL. Все приемники/передатчики это Virtex-E и Spatran-IIE. Хочеться постепенно перевести проект на Spartan-3A. Изменять электрический стандарт шин очень нехочется, т.к. это приведет не к постепенной эволюции комплекса, а революции, коия совсем не интересна заказчику.

 

Тепер вопросы:

1. Возможно ли, использовать схемотехническое решение от Virtex-E (XAPP133.PDF) для Spartan-3A ? И если да, то какие должны быть настройки у выходного буфера ? (пока я предпологаю, что Xilinx LVPECL - это два LVTTL 12mA).

 

2. В чем глубинный смысл жестко закрепленных пар IOB для одного диф. выхода у Virtex-E и Spatran-IIE ? И можно ли использовать любые выходные ножки под диф. выход, если clock постурает на триггеры этих IOB с малой разбежкой фронтов (напри мер менее 1.0 ps или 0.1 ps) ?

[kiss 0]

Стандарт LVPECL у Xilinx всегда был, и будет не совсем "родным", что в общем неудивительно, в связи с особенностями схемотехники выходных каскадов ЭСЛ. Основная его задача - обеспечить совместимость, особенно по входу, не замахиваясь на высокие скорости ЭСЛ.

 

Закладывать LVPECL для связи нескольких ПЛИС ИМХО не стоит - для этого предусмотрен LVDS, и BLVDS - для шин.

 

По вопросам:

1. В принципе, можно использовать LVTTL, и ток выходного буфера сделать в диапазоне от 4 до 12 мА, и в большинстве случаев все будет работать для скоростей в несколько сот мегабит/с. Выходной буфер разумеется недифференциальный.

 

2. Под подобный дифф. выход можно использовать любые ножки. Смущаться по поводу дисбаланса, и т.п. не стоит - немного неоптимальности в данном случае уже не повредит.

 

Лично у меня LVPECL надежно работал на скорости 500 мбит, но не потому, что я его специально выбрал для этой цели, а некуда было деваться - ошибка при проектировании платы, когда на данные выводы нельзя было назначить выходной буфер LVDS.

[Beby 8]

2. Под подобный дифф. выход можно использовать любые ножки. Смущаться по поводу дисбаланса, и т.п. не стоит - немного неоптимальности в данном случае уже не повредит.

О каком дисбалансе и неоптимальности идет речь, если можно дайте ссылочку на литературу (очень неудобно себя чувствовать, когда не понимаешь детально как именно работает группа ног ПЛИС, а надо применять эти знания).

 

Лично у меня LVPECL надежно работал на скорости 500 мбит, но не потому, что я его специально выбрал для этой цели, а некуда было деваться - ошибка при проектировании платы, когда на данные выводы нельзя было назначить выходной буфер LVDS.

В моем случае практически то же, ПЛИС работают с клиентами LVTTL, корписа PQ, поэтому оба банка IO имеют VCC = 3.3V.

 

Спасибо за овтет.

[kiss 0]

О каком дисбалансе и неоптимальности идет речь, если можно дайте ссылочку на литературу (очень неудобно себя чувствовать, когда не понимаешь детально как именно работает группа ног ПЛИС, а надо применять эти знания)

 

ссылка про LVDS, например: http://www.xilinx.com/esp/wired/optical/collateral/lvds.pdf

 

Дисбаланс в данном случае возникает как по времени выдачи сигналов (когда они не в одном IOB - это понятно), так и по току через общий проводник - у идеального LVDS его практически нет, что очень серьезно облегчает signal integrity, и снижает "звон" по земле. В случае эмуляции дифференциального стандарта (если ток выходных драйверов больше 4 мА) при значительном количестве драйверов могут быть проблемы. Дисбаланс, вызванный пространственным разносом выводов ПЛИС драйверов - не для этого случая, а для мультигигабитного. По крупному, вопрос серьезный, и требует соответствующего подхода.