Jump to content

    
Sign in to follow this  
billidean

Nios II /e vs Nios II /f (проект Ethernet)

Recommended Posts

Я тоже так подумал, но вот искать истину пока некогда. Хотя всегда считал, что вне зависимости от типа проца. он всегда 32-хбитный. Надо почитать описание поточнее.

Share this post


Link to post
Share on other sites

Посмотрел доку "Implementation Details" на НИОС (n2cpu_nii51015.pdf), не нашел про изменение работы с памятью (32-хбитное обращение или 8-мибитное) для разных версий проца.

Share this post


Link to post
Share on other sites

а шина везде одна и таже?

Потом в дорогом проце считался могла быть железная, а передача 32 битными словами, а в дешевом считалка программная и доступ 8 битный.

В ксалинксе так, дешевый мак считает суммы алгоритмически, а дорогой железом.

Share this post


Link to post
Share on other sites
а шина везде одна и таже?

Потом в дорогом проце считался могла быть железная, а передача 32 битными словами, а в дешевом считалка программная и доступ 8 битный.

 

Нет, базовая архитектура всех ниосов одинакова.

Share this post


Link to post
Share on other sites

Вот моя структура пакета в .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.

Поэтому и началось обсуждение типов НИОСов и их обращение к памяти.

Share this post


Link to post
Share on other sites

Если шина 32-хбитная, и мы указываем на 2-ой или 3-тий байт ячейки, то эта ячейка будет задействована полностью, начиная с 1-го байта, т.о. будем иметь сдвиг по адресу влево, в сторону уменьшения.

Если посмотреть на шину Авалон, то эта ситуация очень видна, НО в этой шине все (имею в виду побайтовое обращение) разруливается доп.сигналами byteenable.

Share this post


Link to post
Share on other sites
Вот моя структура пакета в .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

};

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this