billidean

У меня используется по одному ядру на каждый тип операций (+,-,*,/,..). Выполняется все последовательно-параллельно, т.е. однвременно выполняются только разнородные операции, например, одновременно провожу выполнение "*" и "+" и "-", и т.п. Стараюсь ресурсов использовать по-минимуму. Да, при таком подходе скорость обработки падает, но это все-таки не чисто последовательное вычисление, поэтому более-менее скорость устраивает. Повторюсь, проблема в нехватке ресурсов для расширения проекта. Поэтому хочется уйти от этих "полновесных" Альтеровских ядер. Кто-нибудь вообще использовал сторонние модули float-вычислений? Очень нужна инфа по ним.

Про точности я писал: ПЛИС - без АРМа. Другая ПЛИС - этот вариант не рассматривается, нужно именно в этой. Меня интересуют именно сторонние вычислительные модули с плав.точкой. Кто их использовал, где брали, как с ними обстоят дела....

Эти расчеты, точнее аргументы вычислений, никак не связаны с АЦП. Диапазон входных аргументов для операций как раз и указан в первом посте (1е-8 ... 200.000.000).

Добрый день всем. Инструменты работы: Циклон5Е, Квартус 13.0 Для реализации имеется некая формула, вернее набор последовательно вычисляемых формул, имеются операции умножения, деления, извлечение корня, и +,-,<>.. Аргументы при перемножении имеют довольно большие значения - до 200.000.000. При делении делитель имеет довольно малое значение - порядка 1е-8. Точности расчетов должны быть порядка 1е-8. Исходя из таких аргументов я принял решение реализации на плав.точке, при этом приходится использовать ядра Альтеры для проведения всех необходимых операций вычислений. Так вот, собственно, проблема в том, что эти ядра в кристалле занимают ОЧ.много ресурсов, и уже для расширения проекта приходится экономить на регистрах и памяти, и то места может и не хватить на будущее. Имеются ли в природе модули, выполняющие мат.операции с плав.точкой, занимающие меньше места чем Альтеровские? Если да, то кто ими пользовался, что можете сказать о них? Вариант перехода на фикс.точку я рассматривал, но при таком диапазоне аргументов и результатах вычислений у меня как-то не получилось это вытянуть.

Добрый день. Работая с несколькими разными отладочными платами (контроллер, ПЛИС, FTDI), имеющими разъем miniUSB для подключения к ПК (программирования, JTAG-отладки), наткнулся на такой момент, что при использовании разных кабелей USB-miniUSB комп может не видеть устройство (отладочную плату). Скажем, из моих четырех кабелей (три от разных девайсов типа фотоаппарат или внешний накопитель, а один покупной) платы видятся компом только при использовании двух кабелей, а при подключении через остальные два кабеля наблюдается только наличие питания на платах. Может кто-нибудь подсказать, в чем могут различаться внешне похожие кабели? Или это просто глючные кабели?

Не я покупал, мне подогнали для проекта.

Так в этом-то и прикол, что софтовый контроллер вроде работает, а хардовый - не работает в непрерывном режиме.

В-общем, добился корректной работы при условии, что циклограмма чтения такая: 1. запрос чтения одного слова (avl_rdreq) 2. получение слова при появлении avl_rddatavalid НО это получается долго. Хотелось бы так: 1. посылаю N-запросов по нужным адресам без пауз (с учетом avl_ready, конечно) 2. принимаю N-слов данных НО почему-то не могу добиться ровной работы по второму варианту. Если у кого есть проект с подобной работой с ДДР (без НИОСа) для этой платы, очень прошу поделиться :help: Проект горит :help:

Да уж. Ни разу не было так, чтобы взять новую плату с памятью, подцепить в проект контроллер памяти, запустить проект и ... он заработал. Типа как работа с OnChip. Каждый раз приходится искать в инете какие-то настройки и секреты... А самая клёвая настройка у этих контроллеров внешней памяти - это настройки борды (времена)! Это ваще жесссь!...

2 Konst_777 Извиняюсь за наглость, но у Вас нет проекта по использованию этой ДДРки на этой же плате, только без применения НИОСа, так сказать работа напрямую с HMC? Я создал тему с проблемой по работе с этой памятью (вот), а уже после этого нашел эту тему. Заранее спасибо.

Добрый день всем. Недавно начал работать с платой BeMicro_CV (ПЛИС - 5CEFA2F23I7). Создал проект по тестированию работы с ДДР3, которая стоит на этой плате, делаю запись (небольшой объем данных - 100 слов), затем несколько раз читаю эти данные и сравниваю с теми, которые были записаны (с исходным массивом). При НЕсовпадении очередного прочитанного слова с "эталонным" увеличиваю счетчик ошибок. В сигналтапе также контролирую весь процесс. Так вот, на таких небольших объемах проверок я все-таки получаю ошибки читаемых данных, но не всегда. Может получиться и так, что половина массива вычитается правильной, а потом полезут кривые данные. Причем после появления первой ошибки следующие почти все последующие данные - битые. Я понимаю, если бы постоянно данные кривые читались, то проблема была бы в записи или в настройках. А так - ничего не пойму. Контроллер использую хардовый, ТаймКвест косяков не выдает. Питание использую от USB. Работаю на ноуте. Вопрос к тем, кто работал с этой платой: не замечали такой работы контроллера ДДР на этой плате/ПЛИС? и если да, то как победили? Есть подозрение, что память не стабильная, т.е. косячная. Но это все паранойя.

Приветствую всех. В разработке проект на плис с использованием микросхемы FT232H. Железо будет состоять из двух плат (отладок): плис и UM232H(c ft232h). Платы пока не в наличии, но до их прихода хочется подготовить работу плис с ft232h, обмен будет по интерфейсу SPI (ft232h будет настраиваться на этот интерфейс). Так вот, вопрос такой - есть ли в природе некая модель (для моделсима) этой самой микросхемы ft232h? Я, конечно, понимаю, что SPI - он и в Африке SPI, но работа с моделью дает большие возможности для правильной организации работы с железом, не на 100%, но на 60-70% это точно.

--

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

Вот моя структура пакета в .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. Поэтому и началось обсуждение типов НИОСов и их обращение к памяти.

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

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

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

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

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

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

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

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

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

Добрый день всем. На демоплате 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 */ } В чем может быть секрет?? Кэшей никаких не использую, поэтому переход на Экономный проц должен вроде пройти без проблем, кроме замедления работы.