реклама на сайте
подробности

 
 
> Nios II /e vs Nios II /f (проект Ethernet)
billidean
сообщение Mar 11 2014, 03:55
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Добрый день всем.
На демоплате BeMicro (Cyclone IV E) делаю проект работы с Ethernet (UDP).
При использовании проца Nios II /f все нормально работает. Но для этого проца нужна лицензия (которой у меня нет crying.gif ).
Попробовал перейти в этом же проекте на 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 */
}


В чем может быть секрет?? Кэшей никаких не использую, поэтому переход на Экономный проц должен вроде пройти без проблем, кроме замедления работы.
Go to the top of the page
 
+Quote Post
2 страниц V   1 2 >  
Start new topic
Ответов (1 - 24)
Kuzmi4
сообщение Mar 11 2014, 07:13
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329



2 billidean
Листинг смотрели ? В IDE отладчике сравнивали результаты на выходе для одинаковых пакетов?
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 11 2014, 07:19
Сообщение #3


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Отладчиком еще не проходился.
Но уже дошел до такого решения. Вечером буду пошагово сравнивать расчет этой CRC для обоих процов.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 11 2014, 13:52
Сообщение #4


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



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

З.Ы.: Может у кого есть уже наработанное решение (аля "универсальное") подобной проблемы перехода с Fast на Econom Nios ??
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение Mar 11 2014, 14:30
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329



считать в плисе ?
Go to the top of the page
 
+Quote Post
vadimuzzz
сообщение Mar 11 2014, 22:59
Сообщение #6


Гуру
******

Группа: Свой
Сообщений: 2 291
Регистрация: 21-07-05
Пользователь №: 6 988



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

фокусы с кэшем?
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 12 2014, 01:52
Сообщение #7


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



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

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

Могу выложить исходники проекта НИОСа, если будет желание в нем покопаться.
Go to the top of the page
 
+Quote Post
Serhiy_UA
сообщение Mar 12 2014, 03:09
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 721
Регистрация: 23-10-08
Из: next to Odessa
Пользователь №: 41 112



Попробуйте создать тестовые примеры, максимально все упростив. Вычисляйте Ниосом только контрольную сумму для одного и того же массива по каждому из вариантов и сравнивайте между собой. Таким способом будет легче найти причину, если причина в этой сумме...
У меня контрольная сумма для UDP вычислялась аппаратно в двух потоках (когда один поток через Ниос передавался, другой аппаратно обсчитывался, и наоборот), что было связано с требованием высокого быстродействия.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 12 2014, 03:53
Сообщение #9


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Цитата
Вычисляйте Ниосом только контрольную сумму для одного и того же массива по каждому из вариантов и сравнивайте между собой.
В этом то и загвоздка получилась, работа функции расчета CRC корректная, а вот данные для расчета получились неверные при Эконом. процессоре.
Очень затрудняет процесс отладки то, что при использовании Эконом. НИОСа нельзя ставить брейкпойнты, и приходится через printf() все контролировать, а это та еще песня. При выдачи больших объемов вывод ч/з LTAG может зависнуть (несколько раз на такое натыкался) в то время как программа уже ускокала далеко вперед.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение Mar 12 2014, 06:07
Сообщение #10


Гуру
******

Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329



2 billidean
Как это нельзя ставить брейкпойнты? Кто вам это сказал ?
Всё можно, только там SW-breakpoint, но в вашем случае это не сыграет какой то важной роли.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 12 2014, 06:35
Сообщение #11


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Вроде я такое же читал, что при Эконом.НИОС будут софтовые точки останова. Но когда скомпилил проект к квартусе, затем открыл проект в еклипсе, то сколько бы я не тыкал мышью в разных местах, точки останова не ставились. Может просто глюк был, седня попробую еще раз.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение Mar 12 2014, 06:43
Сообщение #12


Гуру
******

Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329



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

Если не получится выставить брейкпойнты, тогда выкладывайте здесь обрезанный вариант - интересно будет глянуть.
Go to the top of the page
 
+Quote Post
Копейкин
сообщение Mar 12 2014, 06:44
Сообщение #13


Частый гость
**

Группа: Участник
Сообщений: 190
Регистрация: 7-11-07
Из: С-Петербург
Пользователь №: 32 134



Если код был "оптимизирован", то там точку останова поставить не даст.
Уровень оптимизации одинаков в обоих случаях? И какой?
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 12 2014, 07:37
Сообщение #14


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



настройки BSP в части оптимизации были по умолчанию (о0) в обоих случаях.
Исходники не менял при переходе между процами.
Вечером еще раз попробую погонять, может что прояснится.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 12 2014, 11:57
Сообщение #15


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Вобщем все вроде заработало.
Дело было в указании адреса на элемент массива подготовленных данных (пакета), начиная с которого необходимо расчитывать контрольную сумму для IP-заголовка. Этот адрес был сдвинут на один байт правее. Но почему в Фаст.НИОСе при этом производился правильный расчет CRC - это пока загадка.
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Mar 12 2014, 14:59
Сообщение #16


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



потому что фаст наверняка 32 битный, и при сдвиге на 1 - 2 - 3 байта все равно попадает в 0 байт. А этот почему то честно отработал...
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 13 2014, 00:05
Сообщение #17


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Я тоже так подумал, но вот искать истину пока некогда. Хотя всегда считал, что вне зависимости от типа проца. он всегда 32-хбитный. Надо почитать описание поточнее.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 13 2014, 06:24
Сообщение #18


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Посмотрел доку "Implementation Details" на НИОС (n2cpu_nii51015.pdf), не нашел про изменение работы с памятью (32-хбитное обращение или 8-мибитное) для разных версий проца.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение Mar 13 2014, 07:18
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329



2 billidean
вставьте в С-код выравнивание, откоментируйте это и забудьте wink.gif
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Mar 13 2014, 07:21
Сообщение #20


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



а шина везде одна и таже?
Потом в дорогом проце считался могла быть железная, а передача 32 битными словами, а в дешевом считалка программная и доступ 8 битный.
В ксалинксе так, дешевый мак считает суммы алгоритмически, а дорогой железом.
Go to the top of the page
 
+Quote Post
alexadmin
сообщение Mar 13 2014, 07:26
Сообщение #21


Знающий
****

Группа: Свой
Сообщений: 572
Регистрация: 17-11-05
Из: СПб, Россия
Пользователь №: 10 965



Цитата(Golikov A. @ Mar 13 2014, 11:21) *
а шина везде одна и таже?
Потом в дорогом проце считался могла быть железная, а передача 32 битными словами, а в дешевом считалка программная и доступ 8 битный.


Нет, базовая архитектура всех ниосов одинакова.
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 13 2014, 07:29
Сообщение #22


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Вот моя структура пакета в .h-файле
Код
typedef struct UDP_str
{
    char macDst[6];
    char macSrc[6];
    char type[2];
    char ver_lenIP;
    char all00;
    char len_28plus[2];
    char id_pack[2];
    char fl_4000[2];
    char time_l_80;
    char type_UDP_11;
    char crc16_IPhead[2];
    char ipSrc[4];
    char ipDst[4];
    char portSrc[2];
    char portDst[2];
    char lenUDP_8plus[2];
    char crc16_UDP[2];
    // до этого ... длина равна 42 байта
    char data[UDP_DATA_MAX_SIZE];
} __attribute__((__packed__)) UDP_str;

Вот код в .c-файле
Код
volatile UDP_str udp_send_s __attribute__ ((aligned (1)));
volatile UDP_str udp_take_s __attribute__ ((aligned (1)));

После этого я считаю, что обе структуры выровнено по-байтово и без "дырок" между полями.
Расчет CRC для IP-заголовка должен начинаться с поля ver_lenIP, и просчитывать 20 байт, а я указал (ошибочно), чтобы начинался расчет с поля all00, т.е. сдвинул на один байт вправо. При этом НИОС/Фаст все нормально расчитывал, а вот НИОС/Эконом выдавал кривую CRC, из-за чего я и обнаружил свой косяк в указании начального адреса расчета CRC.
Поэтому и началось обсуждение типов НИОСов и их обращение к памяти.
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Mar 13 2014, 08:22
Сообщение #23


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



тогда битность шины не причем, был бы сдвиг в плюс это можно было бы обосновать выравниванием. А сдвиг в минус, никак не объясним...
Go to the top of the page
 
+Quote Post
billidean
сообщение Mar 13 2014, 09:39
Сообщение #24


Местный
***

Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925



Если шина 32-хбитная, и мы указываем на 2-ой или 3-тий байт ячейки, то эта ячейка будет задействована полностью, начиная с 1-го байта, т.о. будем иметь сдвиг по адресу влево, в сторону уменьшения.
Если посмотреть на шину Авалон, то эта ситуация очень видна, НО в этой шине все (имею в виду побайтовое обращение) разруливается доп.сигналами byteenable.
Go to the top of the page
 
+Quote Post
Serhiy_UA
сообщение Mar 13 2014, 10:14
Сообщение #25


Знающий
****

Группа: Свой
Сообщений: 721
Регистрация: 23-10-08
Из: next to Odessa
Пользователь №: 41 112



Цитата(billidean @ Mar 13 2014, 11:29) *
Вот моя структура пакета в .h-файле

У меня структура UDP-пакетов несколько схожая, но отличается служебными словами PACKED, у них тоже была своя роль...
//------------------- UDPFRAME
typedef struct udphdr { //8 bytes
u_short uh_sport PACKED; /*!< \brief Source port */
u_short uh_dport PACKED; /*!< \brief Destination port */
u_short uh_ulen PACKED; /*!< \brief UDP length */
u_short uh_sum PACKED; /*!< \brief UDP checksum */
} UDPHDR;

struct UDPFRAME {
ETHERHDR eth_hdr PACKED; //14 bytes
IPHDR ip_hdr PACKED; //20 bytes
UDPHDR udp_hdr PACKED; // 8 bytes
u_char md[1472] PACKED; // + (22..1476) bytes
};
Go to the top of the page
 
+Quote Post

2 страниц V   1 2 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd July 2025 - 09:37
Рейтинг@Mail.ru


Страница сгенерированна за 0.01602 секунд с 7
ELECTRONIX ©2004-2016