ОЧЕНЬ много. При этом наверняка не видите то, что сгладила емкость щупа.

Генератор. Хоть 12, хоть 50 мег.


Варианты?

Это еще надо посмотреть что за осцил и на каком диапазоне мерялось, может он 50 mV сам шумит. Кстати, еще конденсаторы 10 нан + 100 пик попробуйте поменяйть на 100 нан и 1000 пик.

Вариантов очень много. Хотите конкретно - схему и разводку в студию, иначе это телепатия начинается.

Кстати, очень ценное замечание. Есть у меня проект на EP2C5T144, там тоже периодически слетала PLL-ка, после долгих танцев с бубном - и питание крутил и фазы внутренние настраивал подальше от входного фронта (чтобы момент переключения отдалить от окна фазового детектора), таки вылезло SSO - назначил всем выходам 4мА и все работает. А сейчас вот попробовал всем выходам (которые были в группе SSO) поставить MAX CURRENT STRENGTH и только ОДНОМУ соседнему с PLL выходу 4мА - и все, проблема также полностью ушла! Причем земля этого соседнего IO-банка хорошо так от земли PLL на плате отвязана (не говоря уж про питание), а вот сбой все равно был. Итого - ножки соседние с PLL нежелательно использовать как выходы.

Топикстартеру - я бы все-таки еще раз на входной клок посмотрел. Если логики внутри нет, конфликтов на шине нет, все настроено на вход, питание нормальное, то только клок и остается, ИМХО.

Ну это не сильно важно в ракурсе SSO, так как проблемы SSO - это внутрикристальные проблемы, а там GND не отвяжешь, если не SOI-технология. GND одна на весь чип, она от SSO и прыгает, причем эти прыжки могут наружу через проводочки разварки и не вылезти.

Да, наверное, Вы правы - я тоже подумал как оно там внутри разварено и какая там внутричиповая земля - неизвестно.
Но любопытно - внутриплатная PCI32@66MHz гонит без сбоев четверть гигабайта в секунду со всеми выходами данных (кроме одного, который на 4мА) выставленными на 24мА. А вот если этот один, соседний с PLL GND (даже не соседний, еще и через IO GND пин отстоящий), перенастроить с 4мА на 24мА - PLL-ка периодически слетает. Так что, это не совсем SSO, это хрень какая-то . К тому же - SSO "по-альтеровски" - это помехи фазовому детектору, а я моменты переключений триггеров (дизайн полностью синхронный, монодоменный) сдвигал до 1.5нс в обе стороны от входного фронта - никак оно не помогло.

Ну если это и не SSO, а просто SO , оно все равно поддернет питание с землей, и поддернет тем сильнее, чем оно ближе к IO-паду. Это раз. Это в первую очередь распространяется по шинам в металлах. Еще есть шум по подложке и n-карману, а как там внутри оно сделано - можно только гадать. Вполне возможно, что сбивает именно шум подложки, а не подскок в металле.

Касаемо сдвига чего-то от чего-то на сколько-то это никакой роли не играет. Если фазовый детектор даст ложное переключение, то он его даст. и на наносекунду раньше, или позже...

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

Тоже были похожие проблемы с PLL на EP2C20. Решились ограничением тока на выходных ногах ALTERы. Мне кажется Вам стоит поставить минимальное значение тока на выходах ALTERы, которые идут на шину с процессором (атрибут CURRENT_STRENGTH -> MINIMUM_CURRENT).

Правда, это возможно только до определенной частоты шины, ибо малый ток сильно заваливает фронты.