И все же внутри корпуса или внутри кристалла? Попробуйте вариант, когда ядро щелкает на паразитной частоте, а выводы замаскированы? В этом случае может помочь отделить входной и выходной пины клока от других через несколько непереключающихся пинов. Если внутри кристалла, попробуйте прокинуть паразитный клок через неглобальную шину. Т.е. разделить глобальную/неглобальную для нужного и паразитного клоков (или энейблов).

их бы побольше (гармоник) снять, амплитуды померять, форму импульса прикинуть, тогда можно и конкретный сигнал "обвинить".

2.5В идет только на PLL и JTAG? на I/O - везде 3,3? тогда скорее всего лезет через 1,2. если, конечно, по питанию. ткнитесь анализатором спектра в питание PLL.

разобраться надо обязательно. хотя бы ради будущих поколений )
еще вопросик, а как расположены входной пин клока/выходной пин на АЦП?

вы имеете в виду подать на АЦП и ее обвязку один клок, а на остальную логику другой?


Так и сделано, все выводы отключены, кроме выводов АЦП и усб логера(работает на частоте ~10МГц, на противоположной стороне плис) для связи с компом.


В посте 8 я писал что проброс по короткому пути. минуя глобальные линии результата не дает и то что enable не сидит на глобальной линии, потому как используется enable chain.


В посте 1 писал что две прошивки отличаются только источником тактирования. В одном случае клок идет с порта. В другом с PLL в режиме 1к1. Берем панорамник, ставим определенный частотный диапазон и сравниваем 2 прошивки, прошивая через житаг. Так нашли частоту, увидели что она может завернуться в полосу в том месте где стоит помеха. А после того как было сделано динамическое отключение enable chain вышли на этот сигнал.


Да так и сделано. В посте 8 я писал что на осцилле и панорамнике проверялись все питающие линии. На них наводка не обнаружена.


Изначально входной/выходной были сделаны для PLL_3 (т.е. использовалась пара GCLK/PLLCLKOUT для этой PLL). Потом выходной пин был перекинут на другую сторону ПЛИС в свободный банк. Альтернативный генератор был подключен к PLL_2, выводились сигналы на разные стороны кристалла. Результат везде был один. Наводка не уходила, хотя уровень ее плавал.

Был такой такой баг (паразитный спектр) и при разработке демодулятора. Баг такой : наводки не было до тех пор пока ПЛИС не заполнилась больше чем на половину. Потом от разводки к разводке уровень помехи плавал в пределах +-10Дб. Один раз получилось так : когда я в ручную оптималил проект и задействовал все регистры в умножителях, наводка просела на ~20Дб (забитость была 60%), но когда я сбросил базу инкрементальной компиляции и забил полный демодулятор на 99% плис, она вылезла в полный рост. Теперь она не уходит %)

А что, хорошая идея, которая до сих пор почему-то никому не пришла: задайте констрейны по площади, уберите всю логику в другой угол кристалла от PLL. Если у вас кристалл не забит конечно под завязку. Еще разделите сигнал, идущий наружу и тактирующий логику (сделайте два одинаковых выхода у PLL). Но IMHO 30дБ еще к приведенным картинкам - недостижимо.

у итоговой прошивки ресурсы по умножителям 100%, память 40%, логика 99%.... %)

Есть у меня пара идей, но это только после праздников.

а этот enable, по которому демодулятор работает, по глобальному пути проложен?


а если вывести клок на пин рядом с PLL?

Имеется ввиду влияние топологии кристалла.
Во-первых, влияет ли количество ресурсов тактируемых от паразитной частоты? (Вы писали, что тактируется примерно 10к из 25к). Если разницы от количетсва ресурсов не будет, то возможно виновата трассировка глобальных шин (клоки). Для разделения этих вещей нужно разные клоки пустить разными путями - например один из них глобальным, а другой неглобальным. По топологии рядом они не будут и влиять будут меньше.
Если же дело в количестве элементов переключающихся на паразитрой частое, то дело в локальной просадке напряжения. Если снаружи кристалла с фильтрацией ядра все в порядке (а я так понял, что там все в порядке по словам "обвешана как елка") то с этим ничего сделать невозможно.

PS. Я вообще правильно понял, что в ПЛИС заходят два клока - из первого делается клок для АЦП, второй тактирует основное количество логики?
PPS. Я это все к тому, что подача питания и трассировка от кристалла до внешних ног в корпусах QFP и BGA сильно различается и результаты расследования могут дать информацию о том, можно ли применять такие реализации в BGA. Т.е. вопрос не праздный.

А нельзя ли по фазе попробовать отстроиться? Внутри все переключения делаем по одному тактовому, а на АЦП выдаем сдвинутый на 90 (или на любой другой подходящий угол) - тогда, по идее, все переключения что внутри ПЛИС происходят, будут иметь минимальное влияние на фронты внешнего сигнала.

кхм, я три раза в этой теме (последний раз в посте 33) сказал что нет %)


геометрически PLLCLKOUT находиться как раз рядом с PLL. Это видно в Fpga editore


В посте 33 я писал что зависит, в посте 8 что 15к хлопает на enable == clk/2 и еще 5 к на enable == clk/4.


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


меня тоже интересует этот вопрос, когда я обнаружил сие поведение минут 5 парил в прострации от сего факта %)



хмм, надо подумать. Пока как запасной я хочу реализовать дробный приемник (АЦП работает на частоте не целочисленно кратной символьной приемного потока) и пробросить на АЦП сигнал от него.

еще вопросик: а как в проекте с пинами? сколько используется/не используется. как сконфигурированы те, что не используются. особенно интересно в районе клока.

и еще, возвращаясь к варианту с PLL. логика запитывается с PLL_OUT, как и АЦП? или на логику идет GCLK(PLL_IN), а на АЦП PLL_OUT?

кхм, в посте 33 об этом писал %) Фотографии в посте 1 сделаны при использовании 10 пинов АЦП, 1 клок + 12 пинов усб. Клок выводился по разному, в том числе GND GND CLK GND GND. Уменьшения заметно не было.


вопрос не понятен. Используется вывод PLLCLKOUT с с0 выхода PLL и потом глобальный тактовый буфер.

а потом с буфера и на АЦП, и на логику? я к тому, что у вас по всей микрухе параллельно идут клок и мешающий строб. тут как ни крутись, а перекрестных помех не избежать (кстати, об этом намекает спектр, помеха села аддитивно), особенно при таком кол-ве задействованной логики. поэтому клок для АЦП стоит развязывать от клока ПЛИС всеми способами. один вариант предложил VslavX. я говорю примерно о том же: вход с GCLK идет на глобальный буфер (для запитки логики) и на вход PLL (только для АЦП). при таком раскладе длина трассы клока АЦП внутри ПЛИС минимальна и на ней не сидят "левые" потребители. или логику запитать с PLL, а на АЦП пробросить входной клок. а лучше так - сделать 2 выхода с PLL, с0 - на пин для АЦП, c1 для логики.

либо мы с вами читаем разные даташиты, либо что-то не так %)

Cyclone III Device Handbook -> 6. Clock Networks and PLLs in Cyclone III Devices -> Cyclone III PLL -> External Clock Outputs

Я понимаю это так, что используется самая оптимальная схема вывода клока из ПЛИС, как с точки зрения джиттера, так и с точки зрения наводок. Глобальный буфер ставиться уже после точки ответвления клока на PLLCLKOUT. Потому роли и не играет.


это только в том случае если частота генератора равна требуемой частоте, в моем случае это не так.


В посте 8 я писал что сделал сборку вообще без PLL, используя генератор и его деление на триггере. результат тот же самый. На клоке наводка.

я с даташитом и не спорю ), но: так уж и не играет? буфер дает бесконечную развязку вход/выход(особенно нагруженный на такую сеть)? мне как-то более правильным кажется c0 пустить на АЦП, а c1 - на логику. хотя бы тупо попробовать )

так клок для триггера и для логики общий? результат не удивляет. кстати, это был пост №10 )

попробывать то можно, но вот логического обоснования не вижу %). Ушел коннект с c0 на внешний пин, затем пошел на ближайший CLKCTRL блок, там прошел через мультиплексоры и ушел через буфер. Буфер этот скорее всего с высокоомным входом и сильно низкоомным выходом. Каким местом выход этого буфера даст наводку на вход этого буфера, а тем более на выделенную линию связи PLLCLKOUT в принципе не понятно.


уже писал что делал и общий глобальный и отдельно выделенный путь для АЦП и делитель делал отдельно выделенный с триггером для АЦП в IO буфере. Результат везде был один.

ЗЫ. побить в бубен то можно, но вот логического обоснования не видно %)