Значит референсный пример от Xilinx всё таки работает? Тогда у кого лажа-то? Или вам просто религия не позволяет вдумчиво читать документацию?

Скорей лажа в недостатке пошаговых примеров, где всё понятно и доступно объясняются основные принципы работы с soc, а так же даются ссылки на соответствующие разделы документации. Ибо найти такой тонкий момент в огромной документации для новичков непосильная задача.

Полностью согласен с Wic.
Мне что бы разобраться в ошибке именно ХИЛЫХ, а не моей пришлось потратить кучу времени и перерыть много литературы. Почему информации по этой проблеме нет в ug388????

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

Почему не хватает??? Он мирно находится в неактивном состоянии, а я считаю что после включения питания контроллер памяти находится в состоянии как после сброса (т.е. исходном)... И дело там не в том что сигнал сброшен, просто они ошиблись в схемотехнике и требуют дополнительного сброса для правильного запуска тактирующих цепей.

wolfman, логично для тех, кто уже прошел начальную стадию =) Когда сам начинал копать альтеровскую документацию, наматерился. Итог работы был печален почти 8 дней ковыряния для постижения основ, а сейчас основы soc для циклона могу объяснить за час полтора. Это можно считать таким тестом для доступа в разработчики на FPGA =)

Ни в чём они не ошиблись. Большинство более-менее серьёзных корок от Xilinx всегда требуют наличия внешнего ресета. Потому что только так можно установить сложную систему в известное состояние. По-другому это сделать просто невозможно. Надеяться на то, что после загрузки всё само собой встанет так как надо нельзя в сложных системах, хотя бы потому, что момент перехода из неактивного состояния в активное может превышать период клока системы, соответственно возможны самые причудливые эффекты при неодновременном выходе (всилу банальных задержек на распространение сигнала) системы из состояние сброса. Вообще-то это - прописные истины. Можно например про это прочитать у Кена Чапмена или других гуру. Странно что вы этого не знаете, и не думаю что вина Xilinx в том, что эти банальности они не разжёвывают в каждом UG.

А зачем тогда секция initial???
Получается сброс нужно назначать на один из пинов и делать внешним. Или как я делать - корректировать файлы ядра что бы добавить туда код для сброса. Т.к. вход ядра сразу подключается на клоковый пин ПЛИС и выход хоть какого клока есть только после сбрасываемого PLL!!!! Так как делать в этом случае, если хилые сами этого не сделали? И даже в UG об этом не написали????

Вообще-то initial - несинтезируемая конструкция. Используется только для симуляции.Правда хилые зачем-то использовали это (грязный хак по-моему) для начальной установки триггеров. Клоковые пины выведены наружу только в примере, а не в самой корке. Как вы будете получать эти клоки - ваше личное дело.Корка тут ни при чём.Исходные клоки вам нужны в любом случае, при чём частота этих клоков в общем случае может быть не кратна, и даже несинхронаа частоте работы контроллера. Теоретически вы можете запихивать данные в фифошки с одной частотой, а контроллер будет работать на другой частоте.В большинстве члучаев так и происходит - контроллер работает на частоте большей, чем каждый из портов чтобы успевать обслуживать несколько портов. В общем то, что вам нужны как минимум свои клоки, не связанные с контроллером - это понятно? Хилые рекомендуют чтобы эти клоки были кратны частоте контроллера, однако это необязательно. Ну а как сделать сброс имея свои клоки по включению питания - это совсем просто.

У меня в проекте, да и на отладочной плате один клок 100МГц. И этого достаточно... Из него можно получить все частоты, которые мне нужны. Возможно Вы меня не поняли - клоковый вход корки ДОЛЖЕН быть подключен к клоковому пину, там даже IBUFG сразу стоит... По этому пришлось менять код ядра, т.е. добавлять внутрь цепи сброса.

Xilinx пример не работает при перезаливке на работающем чипе. Это происходит не всегда. Какие-то вероятностные штуки. Документация у Xilinx почти никогда не рассматривает corner-cases. Вдумчиво читать её непомогает. У них происходить индунизация разработки и support, в примерах все работает а шаг в сторону - дрова. На вопрос - почему ? support отвечает "незнаем, делайте как у нас, у нас все работает".

Да и что читать-то, в упомянутом UG про проблему эту ни слова нет...

Весь связанный с клоками код вынесен в отдельный модуль infrastructure.v специально для того, чтобы была некоторая свобода в выборе и способе генерации клоков. Этот модуль не входит в состав корки враппера, но он входит в состав example_design, так как без него пример работать не будет. Вам никто не запрещает сделать так, что весь дизайн будет работать от 100МГц - возможно даже удастся обойтись всего одной PLL для этого. Но составители примеров Xilinx не знают об этом вашем уникальном пожелании, поэтому они делают так чтобы всё работало на большинстве демоплаточек с минимальными имзменнениями в коде (в данном случае под каждый конкретный дизайн надо только лишь UCF поправить). И наконец для того, чтобы была некоторая свобода в том,как и где генерировать нужные клоки, они выносят из состава враппера наружу, в отдельный модуль, все клоковые дела для того, чтобы вам не пришлось лезть глубоко внутрь коры с целью что-то поменять в клоках.Доступно объясняю?
Сброс, повторяю, этому дизайну необходим отдельный, и (желательно) никак не завязанный на выходные клоки с ПЛЛки, потому что если пллка перестанет генерить клок (такое бывает, напрмер, когда на входе у неё клок умирает), то и сброс работать не сможет - получается deadlock.
Кроме того, по сбросу автоматически происходит перекалибровка задержек, его можно использовать для принудительной перекалибровки если к примеру темепература сильно ушла в соторону от номинала.