[Bad0512 2]

Xilinx memory controller - полная лажа. Приходится делать полное выключение питаня чтоб он заработал. Иначе при перезаливке прошивки результаты такие же как и у вас.

Про то что сделанная с нуля по инструкциям Xilinx система вообше не работает я уже молчу - пришлось начинать с работаюшего Xilinx примера.

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

 

 

[Wic 0]

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

[AlphaMil 0]

Полностью согласен с Wic.

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

[wolfman 0]

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

 

[AlphaMil 0]

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

[Wic 0]

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

[Bad0512 2]

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

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

 

[AlphaMil 0]

А зачем тогда секция initial???

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

[Bad0512 2]

А зачем тогда секция initial???

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

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

 

[AlphaMil 0]

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

[alexr22b 0]

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

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

[svedach 0]

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

[Bad0512 2]

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

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

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

Кроме того, по сбросу автоматически происходит перекалибровка задержек, его можно использовать для принудительной перекалибровки если к примеру темепература сильно ушла в соторону от номинала.