[spectr 0]

Это какой-то кошмар!!!

Стоит что-нибудь изменить в 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 и таймстампа.

 

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

Изменено 11 ноября, 2010 пользователем spectr

[spectr 0]

.

[StewartLittle 41]

Какую используете версию QuartusII и NiosII SBT ?

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

 

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

[spectr 0]

Какую используете версию 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), на форумах также много людей с этим сталкиваются. Может быть все же дело в кабеле?

Кстати, должно ли быть все заземлено? :) :) :)

Изменено 13 ноября, 2010 пользователем spectr

[StewartLittle 41]

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

Еще в десятой версии какая-то беда с JTAG-сервером. Я про это уже здесь писал. Так что ну ее в болото пока.

 

 

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

А попробуйте не рефрешить BSP, а снести его вместе с содержимым, и создать заново.

Есть у меня предположение, что рефреш происходит некорректно - я с таким тоже сталкивался.

 

 

[spectr 0]

Спасибо!

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

 

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

[StewartLittle 41]

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

Не знаю - линуха не имею, проверять не на чем.

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

[warrior-2001 0]

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

После простой пересборки проекта он находится в Eclips. В чудеса не верю, Timequest говорит, что все ок.

Куда копать - не знаю.

 

[alexPec 3]

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

После простой пересборки проекта он находится в Eclips. В чудеса не верю, Timequest говорит, что все ок.

Куда копать - не знаю.

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

[Wic 0]

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

Можете попробовать сменить версию Ква+Эклипс, может помочь, а может и новые глюки порадить.

[alexPec 3]

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

Можете попробовать сменить версию Ква+Эклипс, может помочь, а может и новые глюки порадить.

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

[warrior-2001 0]

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

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

Я сам бы рад грешить на асинхронщину, да вроде нет её в проекте. Проект большой. Пока что занимает половину 125 тыс. ArriaIIGX. Дальше будет ещё больше.

И ещё инфа для размышления. В системе было сперва 2 ниоса. Так вот они могли по очереди не читать один и тот же System ID и Timestamp. Тоесть скомпилирован проект. Один ниос читает - второй нет. Перекомпилил - наоборот, снова перекомпилил - оба читают. Сейчас временно второй ниос отключен.

Это я все к чему - видимо всетаки глюк именно в связке Quartus - Eclips. Если так - то печально.

Завтра попробую 12.0СП2.

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

[acvarif 0]

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

Я сам бы рад грешить на асинхронщину, да вроде нет её в проекте. Проект большой. Пока что занимает половину 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.

 

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

[gridinp 2]

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

 

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

 

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

Примерно такая же картина (Q12.0SP1), зависит от перекомпиляции, температуры и напряжения питания, но не зависит от тактовой частоты.

Возникло подозрение, что в процессоре есть неинициализированные триггера или память, такое вообще возможно или нет в

алтеровских FPGA интересно? К сожалению формат sof файла закрыт и непонятно обязательно ли грузится значение триггера

в занятой LC ли нет... И наверное этот бардак происходит в CPU JTAG так, как он в состоянии остановить/сбросить процессор и

читать SysId из avalon, чтобы никто не мешал...

Изменено 26 октября, 2012 пользователем gridinp

[acvarif 0]

Примерно такая же картина (Q12.0SP1), зависит от перекомпиляции, температуры и напряжения питания, но не зависит от тактовой частоты.

Возникло подозрение, что в процессоре есть неинициализированные триггера или память, такое вообще возможно или нет в

алтеровских FPGA интересно? К сожалению формат sof файла закрыт и непонятно обязательно ли грузится значение триггера

в занятой LC ли нет... И наверное этот бардак происходит в CPU JTAG так, как он в состоянии остановить/сбросить процессор и

читать SysId из avalon, чтобы никто не мешал...

 

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

#создаются все выходные клоки PLL
derive_pll_clocks -create_base_clocks 
#вычисляется джиттер
derive_clock_uncertainty

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

Изменено 27 октября, 2012 пользователем Acvarif