Не читается System ID в системе с двумя NIOS Опции

[VG2903]

Есть проект с двумя независимыми процессорными ядрами Nios II. Каждое из ядер имеет свою периферию. Разделяемых ресурсов у них нет. При отладке в среде NIOS II SBT for Eclipse у одной из систем не удается прочитать system ID и, следовательно, запустить процесс отладки. В обоих случаях компонент «System ID Peripheral» подключен как Avalon-MM Slave к порту «data_master» процессора. Обе системы создавались в Qsys в Quartus II 64-bit version 14.0.2 Build 209. Повторная генерация HDL файлов системы, у которой не читается system ID и последующее обновление BSP результата не дают. На что еще следует обратить внимание при поиске решения данной проблемы?

[serjj]

Попробуйте для начала поставить галочки Ignored mismatched system ID и Ignored mismatched system timestamp

Сообщение отредактировал serjj - Jan 13 2015, 13:05

[VG2903]

Попробуйте для начала поставить галочки Ignored mismatched system ID и Ignored mismatched system timestamp

Не получается так.

[serjj]

ELF файл не собрался, или не влазет, или проц не завелся (в ресете может сидит) или по частотке не отработал. У меня что то подобное было, когда я на свой Nios понавесил много низкоскоростной переферии, а частоту с PLL заводил 125 МГц, помогло разделение Авалона на два домена - 50 для переферии и 125 для ЦПУ и памяти

[VG2903]

ELF файл не собрался, или не влазет, или проц не завелся (в ресете может сидит) или по частотке не отработал. У меня что то подобное было, когда я на свой Nios понавесил много низкоскоростной переферии, а частоту с PLL заводил 125 МГц, помогло разделение Авалона на два домена - 50 для переферии и 125 для ЦПУ и памяти

Разобрались. Действительно, проц был подвешен на операции чтения из-за неверного подключения периферийного модуля

[serjj]

А можете по-подробнее описать какая ошибка была? Думаю это будет полезно, что бы другим на таких же граблях не топтаться

[VG2903]

Ошибка вследствие невнимательности. Периферийный модуль использует сигнал сброса с активным низким уровнем, тогда как на него был заведён сигнал сброса с активным высоким уровнем. В результате - модуль всё время в сбросе, а сигнал waitrequest_n в нуле, поэтому как только встречается первая операция чтения из этого модуля проц. начинает бесконечно ожидать завершения операции чтения на шине (возвращения waitrequest_n в "1"). Это полностью стопорит всю систему