Первая проблема, с которой столкнулся в v10.0 - EDS не находит процессорного ядра, загруженного в кристалл (работаю в GUI).
Ниосовское ядро содержит jtag debug модуль, проект загружен в кристалл и работает.
При попытке выполнить в EDS "Refresh Conection" выдается сообщение "No NiosII target connection paths were located. Check connections and that a NiosII downloaded". Запрет проверки System ID не спасает.
Соответственно, нельзя ни загрузить исполняемый код в Nios, ни запустить дебаггер или FlashProgrammer.
ПЛИС'ка корректно грузится из-под квартуса, проект работает.
С ходу решения проблемы найти не удалось.

не видел еще такого квартуса и вообще - жара думать лень, собираюсь в отпуск...

из общих соображений:

а к JTAG-у доступ имеет?
может это виндовая проблема - ресурсы какие-нибудь и т.п.

или из cygwin-а доступ к портам ограничен - может пользователя текущего надо добавить в какую-нибудь группу типа dialup

Можно попытаться старый работающий проект из 9х версий подцепить новым отладчиком.
А можно новый проект попробовать подцепить старым отладчиком.
(сам не пробовал).
Может там jtag интерфейс отвалился при синтезе? Можно на сигнлатап вытащить что-нибудь из jtag блоков процессора.

В конце концов, можно хелп почитать, вдруг там все просто по новому.

вроде эта проблема перекочевала из 9.1

В 9.1 у меня все работало как часы...

такого не наблюдал. EDS 10 и 9.1 на первый взгляд ни чем не отличается. Все тоже самое. Бывает что не совпадает ID но после перезагрузки конфига плисины и перекомпиляции они совпадают, и все продолжает работать.
Другое дело Q10.0. Вроде сначала ничего но когда дело дошло до сигнала тапа и соурс проба то там какойто глюк. Если к жтагу подвешены две плисины то он видит их но как только пытаешся работать со второй то по какимто причинам сбрасывается на первую всегда. В 9,1 такого нет. Здесь пришлось перейти на 9,1сп2 назад.
В модель симе какието глюки с atrera_mf.v если брать её из v6.5e то при использовании pll модель сим резко увеличивает память > 1 Гб и зависает, если использовать altera_mf.v из v6.5b то все работает нормально.

Вялотекущее выяснение проблемы показало следующее:

1. Из-под command shell не получается соединиться с локальным JTAG'овским сервером. При этом утилита "jtagconfig" определяет подключенный USB Blaster правильно. Но при попытке загрузить в кристалл sof-файл из-под command shell USB Blaster опять не обнаруживается. См. скриншоты.
Проверить эту ситуацию с ByteBlaster'ом, к сожелению, не имею возможности, т.к. в наличии только плата с интегрированным USB Blaster'ом.

2. В Legacy NiosII IDE v10.0 автоматически приконнектиться к таргету также не получается. Но если там указать тип загрузочного кабеля врукопашную, то коннект с таргетом происходит, и дальше все работает как положено - и загрузка и отладка.
А вот в Nios II SBT v10.0 врокопашную установить тип кабеля нельзя, и, соответственно, коннекта не происходит никак.

Подозреваю проблемы в JTAG'овском сервере в v10.0.
В Альтеру жалобу отписал, хотя особо реакции и не жду.

а если nios2-configure-sof с ключом --cable пустить и усб-бластер прописать?

Одночленственно :


Упс, пардон, правильно вот так :
nios2-configure-sof --cable 3

Теперь по крайней мере sof грузится...

В моем случае "3" - это номер, под которым утилита jtagconfig определяет USB Blaster.

Дальнейшие разборки показали следующее.
У меня в системе имеется два LPT-порта - один встроенный, второй на основе карточки PCMCIA с оксфордовским чипом (ByteBlaster работал в обоих LPT'шниках). Утилитой jtagconfig LPT1 опознавался как устройство 1, LPT2 - как устройство 2, ну а USB Blaster - как устройство 3.
Командами "jtagconfig --remove 1" и "jtagconfig --remove 2" оба LPT'шника были удалены из списка jtag-сервера.
После этого NiosII SBT v10.0 под гуем стал находить USB Blaster, и загрузка кода в ниос заработала.

Несколько озадачивает то, что теперь не получается вернуть LPT'шники обратно в список jtag-сервера. В результате исполнения команды
"jtagconfig --add byteblaster lpt1" выдается сообщение "Unablе to add hardware (Bad port name)" независимо от того, воткнут бластер в соотв. порт или нет. И так для обоих LPT'шников. Перезагрузка компа не помогает.

Кроме того, вылезла очередная проблема:
При работе под гуем загрузить исполняемый код в ниос получается только в свежесозданном софтверном проекте. Если после создания проекта и получения elf'а закрыть NiosII SBT, а затем открыть его с тем же проектом, то при попытке загрузить исполняемый код в ниос возникает ошибка:

С какого препоя он ищет это файл Found ???

а это не оно?

http://www.altera.com/support/kdb/solution...252010_524.html

Ща проверим. Вот только SP1 докачаю...

Увы... Не оно.

Докладываю очередные результаты.
Установка QuartusII v10.0 ServicePack1 и NiosII SBT v10.0 ServicePack1 облегчения больному не принесла.
Обе проблемы:
- с обнаружением USB Blaster'а под гуем (при наличии в списке jtagserver'а железок с меньшим порядковым номером);
- с загрузкой исполняемого кода из-под гуя в существующем проекте,
как были, так и остались.
С добавлением байтбластеров утилитой jtagconfig тоже все по-прежнему хреново.

Вернуть байтбластеры в список jtagserver'а удалось только трансректальным способом:
1. в менеджере устройств снести старый драйвер байтбластера
2. установить драйвер байтбластера заново.
Использование рекомендованной утилиты bblpt.exe в даном случае - как мертвому припарки. Нифига она не инсталлирует (или у меня кривые руки).
Для установки пришлось раскопать квартусовскую папку ..\drivers от старой версии квартуса, и инсталлировать с использованием файла win2000.inf.
3. после перезагрузки можно добавить байтбластеры в квартусовском программере - Hardware Setup - Add Hardware - ByteblasterMV or ByteblasterII.

Если же в квартусовском программере таким же точно способом байтбластеры удалить, то обратно их уже просто так не добавить -
песня начинается сначала, переходим к пункту 1

В общем, "Расстроил меня Джордж" (с) "Трое в лодке не считая собаки"

Я так и продолжаю работать в 9.1 после непродолжительных попыток работать в 10.0...