Непонятная проблема с LVDS, V4 Опции

[rv3dll(lex)]

кратко.

есть плис 4 виртекс есть ацп
всё это дело соединено между собой.

битовая частота 300 мгц кадровая 50
изначально соединение произведено не правильно - сигналы заведены на центральную колонну плис, поэтому не получается штатно использовать деление с помощью BUFR, а топологию корректировать пока не возможно.

поэтому

входные буфера сделаны правильно с помощью iserdes и BITSLIP
а вот клок 300 подан на DCM - которым поделён им до 50 мегагерц и использован для десериализации сигналов.

генератор 50 мгц стоит на ацп. ацп формирует 300 и кадровую 50 и 50 однопроводную на тактирование остальной плисины.

решение кривое, но логически рабочее.

так вот есть некоторая непонятная проблема, появившаяся после некоторого заполнения плис.

иногда данные не корректные, вернее они с импульсными помехами - однопериодными врезками, причём явно видно, что модули bitslip правильно сдвинули поток

переконфигурация bitslip не помогает, всевозможные сдвиги сигналов друг относительно друга не помогают

помогает только пересброс ресетом DCM модуля. и если всё включится правильно , то потом работае нормально сколь угодно долго. соответственно если не правильно сколь угодно долго работает не правильно.

что это может быть???

[rv3dll(lex)]

вот под 64 будет новая плата - правильная. а пока надо понять как работать с имеющимся железом

повторюсь - работает или нет зависит от загрузки плисины. если её освободить до 80 процентов всё работает как часы

[rloc]

повторюсь - работает или нет зависит от загрузки плисины. если её освободить до 80 процентов всё работает как часы

По опыту могу сказать в Virtex-4 DCM крайне нестабильны. Вы заметили какой в репорт-файле пишется джиттер на DCM? На мой взгляд величина очень огромная.
Некоторое время назад я проводил ряд экспериментов над решением вопроса о быстродействии Virtex-4 и по случайному стечению обстоятельств на первой плате из партии в 10 шт. удалось разогнать DCM до 600МГц по выходу FX (по даташиту максимальная частота которого составляет где-то 300МГц) и пройти тесты по фильтрации сигнала с АЦП с помощью FIR-фильтра. Обрадованный результатом я попытался повторить эксперимент на других платах, но ничего не вышло - прошивка работала со сбоями, причем даже при снижении частоты по выходу FX до максимально рекомендованных 300МГц (в качестве опорного использовался КГ с низкими фазовыми шумами на 5-ой механической гармонике). Тогда я ради эксперимента попробовал подать опору от внешнего генератора исключив DCM - все платы устойчиво заработали на 600МГц. Ставить на плату отдельный генератор не позволяло место, а работать на низкой частоте не хотелось при таком-то потенциале! Тогда я сделал следующее - я стал поочередно фиксировать местоположение DCM на кристалле с помощью атрибута RLOC_ORIGIN, пока не добился устойчивой работы всех плат на частоте ~425МГц.
Проблема мне видится в плохой ЭМС внутри кристалла из-за отсутствия развязки по цепям питания DCM и всей остальной части, отсюда очевидна и прямая зависимость от занимаемого объема и потребления (в моем случае вся площадь BGA кристалла на ПП была усеяна конденсаторами 0402).
Могу с уверенностью сказать, что на частотах до 400МГц DDR можно спокойно обходиться без DCM и SERDES, особенно когда по условиям работы тактовая частота идет с перерывами, как например при общении по линк-портам TigerSHARC'а.

P.S. Есть надежда, что в новых Virtex-6 эта проблема решена

MMCM Programmable Features
The MMCM has three input-jitter filter options: low bandwidth, high bandwidth, or optimized mode. Low-bandwidth mode has
the best jitter attenuation but not the smallest phase offset. High-bandwidth mode has the best phase offset, but not the best
jitter attenuation. Optimized mode allows the tools to find the best setting.

[DmitryR]

Могу с уверенностью сказать, что на частотах до 400МГц DDR можно спокойно обходиться без DCM и SERDES

Ну вот послушайте же наконец, второе мнение совпадает с моим. Также еще хочу заметить следующее: в новом дизайне, где будет 64 канала, вы если будете ячить по-своему, у вас на выходах ISERDES, относящихся к разным кристаллам АЦП получатся разные временные домены, поэтому все равно придется ставить elastic. То есть сделав сейчас по-моему вы получите решение, которое одинаково бодро будет работать и на этом железе, и на новом. Если же вы будете продолжать по-своему - вы потратите время дважды: один раз сейчас, чтобы найти и прибить баг, и один раз потом, делая новый дизайн для нового железа.

[rv3dll(lex)]

Ну вот послушайте же наконец, второе мнение совпадает с моим. Также еще хочу заметить следующее: в новом дизайне, где будет 64 канала, вы если будете ячить по-своему, у вас на выходах ISERDES, относящихся к разным кристаллам АЦП получатся разные временные домены, поэтому все равно придется ставить elastic. То есть сделав сейчас по-моему вы получите решение, которое одинаково бодро будет работать и на этом железе, и на новом. Если же вы будете продолжать по-своему - вы потратите время дважды: один раз сейчас, чтобы найти и прибить баг, и один раз потом, делая новый дизайн для нового железа.

про временные домены не понятно????

второе мнение - это у кого????

сделав по Вашему равносильно тому, что в Fx кристалле делать процессор на микроблейзе. Я не прошу навязывания мне своего дизайна, который вы кстати не дадите, а задаю вопрос про имеющийся, сделанный как гибрид из предоставленных на сайте ксилинка примеров. И повторюсь делать я буду так как надо, а не как получилось у Вас.

У меня были сомнения что ошибки возникают при переходе с домена на домен и я сделал следующее.

поставил переход 1 и 2 канала ацп по одному фронту а 3 и 4 по другому. ошибок от этого меньше не стало. все каналы или работают или не работают То есть дело тут в ошибке более серьёзной чем переход с домена на домен.