Добрый день всем.
На демоплате BeMicro (Cyclone IV E) делаю проект работы с Ethernet (UDP).
При использовании проца Nios II /f все нормально работает. Но для этого проца нужна лицензия (которой у меня нет ).
Попробовал перейти в этом же проекте на Nios II /e, при отправке (из платы) пакетов расчитывается кривая CRC для UDP-заголовка. Для самого тела UDP-пакета можно ставить CRC=0, что я и делаю, а вот для заголовка нужна корректная CRC, иначе прога на ПК вообще не принимает пакет.
Код расчета CRC:


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

2 billidean
Листинг смотрели ? В IDE отладчике сравнивали результаты на выходе для одинаковых пакетов?

Отладчиком еще не проходился.
Но уже дошел до такого решения. Вечером буду пошагово сравнивать расчет этой CRC для обоих процов.

Дело получилось не таким простым, как показалось мне сначала.
При отладке двух вариантов Nios/e и Nios/f получилось, что сама функция unsigned short checksum(void *b, int len) проводит все операции правильно, а вот данные по адресам void *b получились кривые в случае Nios/e. Формирование этих данных довольно сложное, и поиски "кривых концов" мне не очень улыбаются, поэтому я пока забил на этот вопрос (Но осадок остался).

З.Ы.: Может у кого есть уже наработанное решение (аля "универсальное") подобной проблемы перехода с Fast на Econom Nios ??

считать в плисе ?

фокусы с кэшем?

Вы имеете в виду вынести формирование пакета за пределы НИОСа во внешний модуль ПЛИС, который наберет все нужные данные из НИОСа и сформирует отправной пакет? Это конечно интересно, и не будет зависеть от НИОСа и его типа, НО большая проблема в том, что кристалл забит почти на 90%. Проект компилится несколько часов с несколькими заходами в фиттеровщик.

В настройках НИОСа кэш данных отключен, с ним даже Фаст проц чота глючил при формировании пакетов.

Могу выложить исходники проекта НИОСа, если будет желание в нем покопаться.

Попробуйте создать тестовые примеры, максимально все упростив. Вычисляйте Ниосом только контрольную сумму для одного и того же массива по каждому из вариантов и сравнивайте между собой. Таким способом будет легче найти причину, если причина в этой сумме...
У меня контрольная сумма для UDP вычислялась аппаратно в двух потоках (когда один поток через Ниос передавался, другой аппаратно обсчитывался, и наоборот), что было связано с требованием высокого быстродействия.

В этом то и загвоздка получилась, работа функции расчета CRC корректная, а вот данные для расчета получились неверные при Эконом. процессоре.
Очень затрудняет процесс отладки то, что при использовании Эконом. НИОСа нельзя ставить брейкпойнты, и приходится через printf() все контролировать, а это та еще песня. При выдачи больших объемов вывод ч/з LTAG может зависнуть (несколько раз на такое натыкался) в то время как программа уже ускокала далеко вперед.

2 billidean
Как это нельзя ставить брейкпойнты? Кто вам это сказал ?
Всё можно, только там SW-breakpoint, но в вашем случае это не сыграет какой то важной роли.

Вроде я такое же читал, что при Эконом.НИОС будут софтовые точки останова. Но когда скомпилил проект к квартусе, затем открыл проект в еклипсе, то сколько бы я не тыкал мышью в разных местах, точки останова не ставились. Может просто глюк был, седня попробую еще раз.

2 billidean
У меня в проектах обычно Nios2-e, патроны подавать много мозгов не надо, так отладка всегда работает без вопросов (Q2 v9.0sp2 / Q2 v13.0sp1). Даже когда собираю скриптами, потом импортирую проект в эклипс и в уже импортированном выбираю папки/сорцы и в сорцах ставлю точки останова.

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

Если код был "оптимизирован", то там точку останова поставить не даст.
Уровень оптимизации одинаков в обоих случаях? И какой?

настройки BSP в части оптимизации были по умолчанию (о0) в обоих случаях.
Исходники не менял при переходе между процами.
Вечером еще раз попробую погонять, может что прояснится.

Вобщем все вроде заработало.
Дело было в указании адреса на элемент массива подготовленных данных (пакета), начиная с которого необходимо расчитывать контрольную сумму для IP-заголовка. Этот адрес был сдвинут на один байт правее. Но почему в Фаст.НИОСе при этом производился правильный расчет CRC - это пока загадка.