[billidean 0]

Добрый день всем.

На демоплате BeMicro (Cyclone IV E) делаю проект работы с Ethernet (UDP).

При использовании проца Nios II /f все нормально работает. Но для этого проца нужна лицензия (которой у меня нет :crying: ).

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

Код расчета CRC:

unsigned short checksum(void *b, int len)
{
    unsigned short *buf = b, result;
    unsigned int sum=0;
    for ( sum = 0; len > 1; len -= 2 ) /* Sum all 16b words */
    {
//        printf("*buf = 0x%x\n", *buf);
        sum += *buf++;
    }
    if ( len == 1 )
    /* If any stray bytes, */
    sum += *(unsigned char*)buf;
    /* add to sum */
    sum = (sum >> 16) + (sum & 0xFFFF);
    /* Add the carry */
    sum += (sum >> 16);
    /* (again) */
    result = ~sum;
    /* Take the one's complement */
    return result;
    /* Return 16b value */
}

 

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

[Kuzmi4 0]

2 billidean

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

[billidean 0]

Отладчиком еще не проходился.

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

[billidean 0]

Дело получилось не таким простым, как показалось мне сначала.

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

 

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

[Kuzmi4 0]

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

[vadimuzzz 0]

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

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

[billidean 0]

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

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

 

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

 

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

[Serhiy_UA 1]

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

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

[billidean 0]

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

В этом то и загвоздка получилась, работа функции расчета CRC корректная, а вот данные для расчета получились неверные при Эконом. процессоре.

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

[Kuzmi4 0]

2 billidean

Как это нельзя ставить брейкпойнты? Кто вам это сказал ?

Всё можно, только там SW-breakpoint, но в вашем случае это не сыграет какой то важной роли.

[billidean 0]

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

[Kuzmi4 0]

2 billidean

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

 

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

[Копейкин 0]

Если код был "оптимизирован", то там точку останова поставить не даст.

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

[billidean 0]

настройки BSP в части оптимизации были по умолчанию (о0) в обоих случаях.

Исходники не менял при переходе между процами.

Вечером еще раз попробую погонять, может что прояснится.

[billidean 0]

Вобщем все вроде заработало.

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