Это какой-то кошмар!!!
Стоит что-нибудь изменить в SOPC как очень часто NIOS IDE перестает видеть sysid - говорит что " Connected system ID hash not found on target at expected base address.", при этом Connected ID и Connected timestamp - not found... Уже сил нету с этим возиться. Адрес этой sysid никогда не меняется, так какого рожна он перестает ее видеть? Кто-нибудь сталкивался?

П.С.: при этом, если поставить галки в Ignore SysID/Timestamp, то дебаггер отваливается с фатальной ошибкой, гласящей что "Downloading Elf failed"...

П.П.С: пара пояснений по процессу:
1. Меняю что-то в SOPC - например, добавляю компоненты, меняю имена компонентов. Генерю SOPC.
2. Обновляю и правлю (если нужно) схему по входам-выходам SOPC-системы. Компилирую.
3. Заливаю SOF на плату.
4. Генерирую BSP. В случае если изменились имена компонентов, то в BSP-едиторе во вкладке Linker Script делаю Restore to defaults.
5. Компилирую.
6. При настройке дебаггера появляется то самое сообщение о несовпадении ID и таймстампа.

Вроде процесс правильный, все это раньше на других платах и проектах делалось уже сотни раз, но здесь какая-то черная дыра прямо.

.

Какую используете версию QuartusII и NiosII SBT ?
Как именно Вы генерируете BSP после изменений в SOPC Builder'е? Используете Refresh или сносите старый BSP и создаете новый?

SystemID затем и используется, чтобы контролировать соответствие программной части проекта его аппаратной части. Если Вам это не нужно, то удалите SystemID из системы в SOPC Buider'е.

Использую 10.0 SP1 и Квартус и Ниос.

Испоьзую Рефреш.

Подчеркну, что sysid НЕ ВИДИТСЯ. Я бы понял если бы он видел не то значение, так он его вообще не видит. Возможно ли, что присутствуют какие-либо помехи на ЮСБ-бластере? Хотя .sof заливаются вполне нормально...



Кстати, в Ниосе стала часто возникать ошибка:

"Assertion failed!

nios2oci.cpp line 158

Expression m_state == STATE_DEBUG"

Эта ошибка описана у самой альтеры (http://www.altera.com/support/kdb/solutions/rd05242010_978.html), на форумах также много людей с этим сталкиваются. Может быть все же дело в кабеле?
Кстати, должно ли быть все заземлено?

Версия 10.0 SP1 дюже глючная - у меня, например, в ней такой глюк наблюдается - если в NiosII SBT создать проект с нуля, то elf нормально заливается в кристалл. А если открыть уже существующий проект (например, только что созданный), то при попытке загрузки elf'а вываливается какая-то неинформативная ошибка, и загрузки не происходит. Помучавшись, откатился на v9.1 sp2, и жду, когда выйдет v10.1 (обещают в начале декабря).
Еще в десятой версии какая-то беда с JTAG-сервером. Я про это уже здесь писал. Так что ну ее в болото пока.



А попробуйте не рефрешить BSP, а снести его вместе с содержимым, и создать заново.
Есть у меня предположение, что рефреш происходит некорректно - я с таким тоже сталкивался.

Спасибо!
Тоже пришел к выводу что нужно возвращаться к 9.1 SP2.

Еще такой вопрос: версия под линукс и версия под мастдай - могут они генерить различающиеся файлы (имеется в виду выхлопы SOPC, компилятора FPGA, NIOS)? То есть, если на двух машинах установлено, допустим, 10.0 SP1, но на одной линуховая версия, а на другой - виндовая - могут ли быть различия в выхлопах?

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

Сталкиваюсь с данной проблеммой в 11.1 SP2. Причем иногда ID и Timestamp - not fount, а иногда равны нулю.
После простой пересборки проекта он находится в Eclips. В чудеса не верю, Timequest говорит, что все ок.
Куда копать - не знаю.

Ну окей то оно окей, а клоки именно ваши таймквест видит? Можно просто не указать клоки, таймквест будет смотреть только клок altera reserved tck = 10 мгц и скажет что все в норме.

Что то мне подсказывает, что это глюки альтеровской надстройки для эклипса, я на такие вещи уже внимания не обращаю.
Можете попробовать сменить версию Ква+Эклипс, может помочь, а может и новые глюки порадить.

Если, как я понял, после перекомпиляции с изменениями такое возникает, то больше походит на неуказанные клоки.

Все клоки корректно прописаны. Все ограничения для Альтеровский ядер заданы. Все самописные межклоковые переходы сделаны через двухклоковые фифошки той же альтеры.
Я сам бы рад грешить на асинхронщину, да вроде нет её в проекте. Проект большой. Пока что занимает половину 125 тыс. ArriaIIGX. Дальше будет ещё больше.
И ещё инфа для размышления. В системе было сперва 2 ниоса. Так вот они могли по очереди не читать один и тот же System ID и Timestamp. Тоесть скомпилирован проект. Один ниос читает - второй нет. Перекомпилил - наоборот, снова перекомпилил - оба читают. Сейчас временно второй ниос отключен.
Это я все к чему - видимо всетаки глюк именно в связке Quartus - Eclips. Если так - то печально.
Завтра попробую 12.0СП2.
Если новые глюки позволят корректно работать,а данные глюк пропадет - придется переходить на новую версию окончательно.

По поводу Q12. Читается-ли System ID и Timestamp?

У меня та же проблема в Q11.0. Не знаю что делать. После небольшого изменения в SOPC System ID и Timestamp не читаются (хотя до все читалось). Пробовал сносить BSP со всеми папками и создавать по новой. Не помогло. Q11.0 работает в WinXPSp3.

Подскажите пожалуйста чего нибуть.

Примерно такая же картина (Q12.0SP1), зависит от перекомпиляции, температуры и напряжения питания, но не зависит от тактовой частоты.
Возникло подозрение, что в процессоре есть неинициализированные триггера или память, такое вообще возможно или нет в
алтеровских FPGA интересно? К сожалению формат sof файла закрыт и непонятно обязательно ли грузится значение триггера
в занятой LC ли нет... И наверное этот бардак происходит в CPU JTAG так, как он в состоянии остановить/сбросить процессор и
читать SysId из avalon, чтобы никто не мешал...

Потратив время на разные перекомпиляции наткнулся на то, что System ID и Timestamp начинает корректно читаться независимо от проекта, независимо от проца и незавсимо от его частоты если в .sdc файл добавить строки типа

Глубоко с этим не разбирался. Если кто знает в чем хитрость поясните пожалуйста.

Наверное дело не в этом, у меня это всё было описано. Проблема видимо в порче прошивки. Я только, что разрешил Error Detection CRC (это в Device and Pin options).
И когда схема сбоит, error-нога показывает, что CRC плохой, если стоит в '0' то всё работает ок, ну это и понятно если прошивка испорчена то тут что угодно может быть.
У меня DE0-nano, загружаю или через встроенный usb-blaster или через ecps, сбоит одинаково и по тому и по другому, если когда зашьётся, то всё работает. Обычно
пока холодная плата сбоит, прогреется зашивается почти всегда.
Описано это в an357, an539, но почему прошивка портится? вот вопрос...
Или у них вообще нет CRC контроля при конфигурации устройства?.. Я помню раньше flex10k если неправильно конфиг запихнёшь, то она вообще не работает...

Спасибо за информацию.
Я тоже борюсь с DE0-nano. На работе стоит DE0 - работает гораздо надежнее. Правда там использую Q90. С проблемой System ID и Timestamp столкнулся когда запустил Q110. Если-бы в Q90 был Cyclon 4 думаю было-бы проще. Программа которая исправно работает на DE0, в Nano работает с кучей странностей при одной и той-же конфигурации системы. Не понятно, то-ли компилятор Q110 (Эклипс) совсем не то комплит, то-ли весь Q110 глючит.
Например, простая функция передачи по Ethernet типа eth_ocm_raw_send(ethmass, sizeof(ethmass)); при размере массива ethmass 1168 байт в DE0 посылает то, что прописано, а DE0 Nano посылает 1164 байта. Чудеса. ..

Да я такие ошибки тоже вижу, при этом процессор на первый взгляд работает, а CRC контроль показывает ошибку.
Это легко проверить, просто поставить галочку "Error Detection CRC "и осциллограф на JP3-17.

В общем всё это очень грустно, получается, что сигналу CONF_DONE нельзя верить, а чтобы убедиться в правильной конфигурации надо потратить 10% ёмкости FPGA на самодиагностику.

Попробую с CRC.
Поскольку Вы Работаете с Nano подскажите пожалуйста как корректно импортировать демо проект "DE0_Nano_SOPC_DEMO" в Eclipse Q11.0. Демка создана с DE0_Nano_Syslib (вроде под Q10.1), а в Q11.0 нужен BSP файл. Иначе не компилится main.c. Не врубаюсь как все перенести без потерь в Q11.0

Я эти проекты вообще не собирал, я сразу делал в eclipse из template. Сначала попробовал Counter Binary по алтеровским tutorial.
Потом Hello MicroC/OS-II начал переделывать для себя. А из этого проекта я только sopc-файл взял и в Qsys сконвертил

Понял. Если не сложно, подскажите как из SOPC в Qsys конвертить.
Мне удалось таки запустить DE0_Nano_SOPC_DEMO в Q11.0 Пришлось заново пересоздать проект в Eclipse. Все зараотало. Обратил внимание, что System ID и Timestamp в проекте стоит устойчиво, во всяком случае после двух изменений. Там имеются компоненты Clock Crossing Bridge Может стоит их использовать...

А просто открываем sopc-файл из Qsys он преобразует, а сохраняем уже qsys-файл. Clock Crossing Bridge, как написано в описании облегчает работу avalon, но ошибок
из-за их отсутствия не будет, лишь бы не ругался TimeQuest. Всё равно я думаю будет сбоить, у меня сбои плавно нарастали с увеличением проекта, это и
понятно что увеличивается вероятность, может попробую сменить epcs64 на epcs16, что-то epcs64 spansion народ не любит... Еще надо попробовать снизить
частоту конфига используя CLKUSR И хорошо бы вызвонить резисторы, чтобы перепаять AS FAST на AS STANDART

Вылечили мы свою DE0-nano, Vcore плавало 1.5-1.7V вместо 1.2, выкусили REG3 и впаяли свой стабилизатор.
Похоже, что было впаяно что другое по ошибке вместо LP38500SD-ADJ

Да...уж.
На моей Nano перестал теряться ID.
По поводу 1.2 В тоже нужно проверить.
По ходу возник вопрос, который поставил в тупик. Имеем макет с EP3C25 + EPCS16. Пытаюсь его настроить. Конфигурация в EPCS16 зашивается нормально. А как теперь быть с программой Nios, которая пока работает во внутренней памяти (в дальнейшем должна работать в SDRAM). Куда и как ее загружать. Я по наивности считал, что все можно поместить в EPCS16. Если это не так, подскажите пожалуйста как?

Надо у процессора поставить Reset vector memory: имя_epcs_контроллера.epcs_control_port. Начальный загрузчик делает Quartus и помещает его в адреса EPCS контроллера.
После компиляции сконфигурить через бластер fpga чтобы совпадал system Id с BSP и далее нужно зашить в ecps с помощью Flash Programmer сразу и SOF и ELF.
Flash Programmer шьёт как я понимаю через JTAG_UART->JTAG_CPU->ECPS_контроллер. *.jic - jtag indirect файл в этом случае можно не делать.
Это я описал случай, когда бластер подключается к JTAG.
Да ещё процессор должен к ECPS контроллеру подключаться по обоим шинам и данных и инструкций, так как загрузчик прямо с него выполняется.

Много писать не буду - сухой отстаток такой:
В версии 11.1 sp2 для того, чтобы гарантированно получить рабочую конфигурацию ПЛИС и увидеть System ID надо снести папки db и Qsys_system\synthesis\submodules.
Тогда Eсlipse, поставляемый с данной версией квартуса нормально работает. При это перед повторной сборкой ПО надо сделать clean и для исходников, и для BSP.
Если использовать версию Eсlipse, поставляемую с Quartus 12.0 sp2, то папки можно и не удалять, но clean делать обязательно.
Изменение версии самого Quartus на проблему никак не влияет.
Как-то так.

Столкнулся с аналогичной проблемой. Отладочная плата SoCKit. Днем ранее загрузил Quartus, открыл в нем проект SoCKit_DDR3_Nios_Test с диска к плате. Загрузил, в ПЛИС, все заработало. Начал его переделывать, удалил on-chip, перекинул все на DDR3, добавил sgdma, fifo, rgb конвертер vsync generator, все что нужно для рисования Ниосом на экране. В eclipse создал новый проект HelloWorld, запустил, все заработало, на мониторе тоже все хорошо, видно как запустилась видиоподсистема. Сохранил его как шаблон для дальнейших экспериментов. Сегодня продолжил работу. Примерно в 12:15 приступил к сборке проекта в eclipse. Скопировал файлы от другого тестового проекта в свой проект. Повозился немного с кэшем, плюнул и заменил Nios II gen 2 на Nios 2 Classic, уменьшил на один разряд адрес DDR3, в итоге получил 512 МБ вместо 1024 МБ. Далее все собралось и к 17:45 я увидел ожидаемое изображение на экране. Немного поигрался с кодом. После все еще раз собрал, проверил и запакавал архиватором с пометкой ****_v2.
Продолжил совершенствовать проект, стояла задача задействовать в контроллере DDR3 много портовый режим, залез в QSYS настроил, тут же вылезли какие то странные ошибки которые исчезли когда я удалил оба мастера (Nios и SGDMA) и снова их добавил. Все система сгенирировалась, далее собрал проект в Quartus и запустил Eclipse попытался подцепить существующий проект, но он даже BSP не перегенирировал. Создал проект с нуля. Закинул в него файлы *.c и *.h, скомпилировал и далее RunAs, eclipse выдал окно с ошибкой по SYSID, нажатия refresh ни чего не дало, установил заветные галочки, запустил, вылетело ожидаемое окно с ошибкой.
Как я ни колдовал ни чего не помогает. Создавал HelloWorld, пытался его грузить все равно вылетает. Ну думаю контроллер памяти не хочет работать в много портовом режиме, пере собрал в QSYS в одно портовый режим как было раньше, все скомпилировал, в eclipse по новой создал HelloWorld, скомпилировал и далее RunAs и все тот же вылет.
Удалил проект полностью, восстановил из архива. Прошил все заработало.
Начал его менять, снова те же проблемы. И вот уже 20:00 я удаляю опять перепаханый проект, восстанавливаю из архива, загружаю в ПЛИС и все ни чего не работает, вылетает все время ошибка по SYSID. Я уже и eclipse и quartus и комп перегружал ни чего не помогает.
Что могло произойти, использую Quartus 15.1.0 Build 185, Eclipse Kepler тот который с ним в комплекте устанавливается.