Всех приветствую!

Есть spartan-3an starter kit.
Спаял ацп плату, данные 8 bit 50 msps.
Задача - передать данные на комп.
После игр с com-портом, остановился на UDP пакетах.

Вопрос 1: как лучше передавать данные процессору с vhdl уровня. Пока что интересуют пакеты по 1000 байт.
Данные собираются на частоте 50 мгц. пакетами по 1000 точек.
Для начала готов терять часть пакетов.
Пока пробую через GPIO. Подвел к контроллеру прерывания ногу и вывел её на vhdl уровень.
Можно данные по 4 байта складывать в GPIO, но всё равно, кажется не будет успевать.

Вопрос 2: Сколько тактов нужно процессору для обработки прерывания и дописывания в строку переменной из порта GPIO?

Вопрос 3: Почему столько ресурсов скушал только microblaze c переферией?
Это нормально?

OS Platform - standalone
UDP пакеты через Lwip

Microblaze + ethernetlite ip.
Процессор на частоте 62.5 mhz.
16 kb local memory
2kB + 2kb cache data, instr DDR2 SDRAM

fpga xc3s700an

Number of Slice Flip Flops 4,337 ___ 36%
Number of 4 input LUTs 5,218 ___ 44%
Number of occupied Slices 4,259 ___ 72%
Total Number of 4 input LUTs 5,358 ___ 45%
Number of MULT18X18SIOs 3 ___ 15%
Number of RAMB16BWEs 17 ___ 85%

Всем спасибо.

Прелесть микроблайза именно в том что это процессор внутри ПЛИС. И не надо к нему как к обычному процу относиться. У вас в этом проце наружу выведены шины! Через них можно читать и писать данные, при этом как всегда существуют ДМА, так что можно перепихивать данные прямо в память.

Самое простое с помощью визард create and import сделать модуль с регистровым доступом, слейв режима, он добавляется в микроблайз на шину,и данные из него просто читаются как из адресного пространства. Такой же модуль может быть мастером на шине, и сам инициировать обмен. Ну так же есть готовы IP ядра ДМА

обмен по шине одиночный достаточно медленный, много циклов уходят на начало обмена, для увеличения смотрите БРАСТ режимы.

если будите работать из ДДР, а скорее всего так учитывая LwIP и 16 кбайт памяти, то размахивайте кэш на максимум, без кэша с всеми рычажками на скорость, все очень медленно поедет...


ну и поток 50 МБайт в секунду нереальный....

если можно, то напишите, в чем идея, чтобы взять медленный процессор, с малым объемом памяти на борту, без какой либо операционки и на нем что-то городить...
Ведь данные нужно принимать, класть в память и при этом в эту де память принимать и из нее передавать пакеты. И из этой же памяти будет работать процессор... Поставите арбитраж на доступ к памяти и что там останется для процессора?
почему бы не взять микроконтроллер с МАС, чтобы внутри частота была 400-800 Мгц, чтобы памяти было много и для ОС и для пакетов? А АЦП - вешь стандартная и ее все равно куда цеплять...
И как видно, что с ПЛИС Вы не работали...
Так почему? Чья идея?

50 МБайт в секунду надо без микроблайза делать, чисто аппаратный UDP в ПЛИС.

Задача - научиться работать ПЛИСом, в том числе и освоить работу с софт-процессорами.
Из микроконтроллеров опыт пока только с 16 битным микрочипом.
Пока что я привязан к этому железу, нет возможности приобрести что-то более оптимальное для этой задачи.
С ПЛИСами учусь работать, изучаю самостоятельно на имеющемся железе.
Микроблейз я только начал осваивать, с DMA режимом еще не работал.
Пытаюсь приладить имеющееся железо под эту задачу. Пока что меня интересуют пакеты по 1000 значений, с заданной частотой дискретезации.
На первом этапе между пакетами готов делать паузу 10-50 msec, ту которую потребуется для передачи пакета на комп.
Сначала обмен сделал через com-порт, данные с ацп запихивал в FIFO. И по заполнению буфера отсылал на комп. Всё работает, но на максимальной скорости 112 кбит.сек передача 1023 значения по 4 байта занимает около 1 сек. это много хочу повысить скорость хотя бы в 10-50 раз.

Решил повысить скорость, и привязался к микроблейзу с эзернет-контроллером.
Может быть формировать udp-пакеты проще без процессора на vhdl уровне, будет ли это быстрее?
В UDP, кажется, не обязательно считать там контрольные суммы.

Я полностью согласен с идеей взять процессор с mac-контроллером, скорее всего к этому и приду,
так как микроблейз съел почти все ресурсы ПЛИСа, я предполагал, что он съест 10-15%.
Выбор на ПЛИС пал, так как предполагаю обработку данных в дальнейшем сделать на нём, и ужать поток через эзернет, но пока готов тренироваться обрабатывать их на строне ПК.

З.Ы. из железа есть еще stm32f4 дискавери, но с ней пока что не успел познакомиться. Может кто подскажет,
какой поток данных можно через нее слать на комп.

Еще вопрос, про USB-полноскоростной, на сколько я понимаю можно добиться 480 мбит в сек.
На спартане стоит такая железка: CY7C68013
EZ-USB FX2™ USB Microcontroller High-speed USB Peripheral Controller .
Что потребуется, чтобы реализовать передачу на комп через неё?

Буду рад советам как на имеющемся железе получить приемлемую скорость передачи пакетов на комп.
хотя бы на порядок превышающую скорость передачи по com-порту.
Пройдя через этот этап, надеюсь появится возможность приобрести более подходящее железо.

С микроблейзом пока научился общаться через gpio. Какие еще есть варианты для передачи в него данных?
В моём случае это пока 1000 байт.
Если можно ткните где почитать об этом.

Спасибо.



Если можно ткните, где почитать об этом или по каким словам найти инфу. В микроблейзе я совсем новичок, только что с ним познакомился. Спасибо!




50 Мбайт пока что и не нужно, сейчас интересуют пакеты по 1000 однобайтных выборок. Передача была реализована через com-порт, 1 пакет в секунду, но хочется повысить скорость передачи пакетов хотя бы на 1-2 порядка.




Еще чуть помучаю микроблейз и попробую. Я решил, что с микроблейзом разобраться будет проще, возможно я ошибся. 50 Мбайт в сек. пока что не требуется. Думаю, что для начала, 50-100 пакетов по 1000 байт в секунду будет достаточно. Важно, чтоб частота выборки внутри пакета соответствовала 50 msps. Спасибо.

Если связались с плис, то по опыту ксалинкса и альтеры все будет немного через одно место (много глюков в обслуживающем софте, потому надо точно знать хороший и проверенный путь)

Микроблайз можно втыкать разными способами, вроде бы самый правильный делать так

Platform Studio - делаете ядро, потом экспортите в SDK, там пишете программу.

Так вот в Platform Studio есть такая фигня как Hardware -> Create or Import Perephiral

в ней делаются новые модули и в ней же они импортяться, чтобы сразу вы поняли куда попали, пишутся они в другой программе.
В этой штуке вы говорите что хотите новый модуль, следуя советам визарда создаете его (попросите сразу сделать для него проект в ISE).
Потом в ISE открываете проект, там есть модуль юзер, в нем будет уже пример работы и подсказки куда чего писать.
Пишите и имплементируете модуль
Обратно в платформ студию, опять Create or Import Perephiral, только теперь импортируете модуль. И он появляется в списке IP ядер в пользовательском отделе, перетаскиваете в проц, подключаете, назначаете адрес и ура...

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

Скорость которую вы можете получить. Я на спартане 6 на 100 МГц, с Гигабитным езернетом, с LwIP получил около 8 МБайт в секунду запись-чтение DDR, это на платном МАК контроллере, с поддержкой железного расчета контрольных сумм.
На процессорах АРМ с МАК контроллером, на 100 МГц проце (LPC1768), с кейловским стэком мы имеем порядка 3-4 Мегобайт в секунду.


Сеть с микроблайзом реально проще, за счет готового стэка. Но самый быстрый способ это правда прямая посылка по UDP, без ядра и прочего. В сети много проектов, реализации этого в железе, с расчетом контрольной суммы. Проблема только в выдачи IP адреса платы, и прочим заморочкам связанным с сетью, но если это все можно настроить с компьютера носителя через какой-нибудь RS232-USB, то почему бы и нет.





USB - сложная штука, обычно упирается в драйверы со стороны windows. Вся часть связанная с большой скоростью данных требует своих драйверов, ибо стандартных типа HID нету, а те что есть очень плохо работают, и зачастую на 1 конечной точке не выдают обещанных скоростей, и требуют опять же писать свой драйвер для сбора с нескольких конечных точек для получения полной скорости.

Опять же та часть что в ПЛИС, тоже не проста, и требует шевелений по настройке и обработке, опять же того же микроблайза в итоге, хотя тут я могу ошибаться, плотно тему USB в ПЛИС не изучал.

В этом случае я бы попытался обойтись без процессора. Есть готовое ядро:

1G eth UDP / IP Stack

Спасибо, это очень полезно, чуть домучаю микроблейз и попробую разобраться с этим ядром.



Я создаю проект схематик в проекте навигаторе, Add embedded sources. В xps конфигурирую железо микроблейза, подправляю mhs файл. Генерю нэт-лист, закрываю xps. Делаю top-hdl для микроблейза в ise, делаю схем-символ из top-hdl, подцепляю схем-символ к проекту ise.
Синтез, имплементация, генерю программный файл, далее экспорт железа в sdk c бит-стримом...

Вопрос: Корректно ли теперь из этого проекта ISE, в другой проект ISE копировать папку с железом микроблейза, и подцеплять его add embedded source (.xml), если железо микроблейза устраивает, или лучше пересобирать железо всё снова в новом проекте.
А то ошибки стали появляться, ISE ругается, что тактовая частота теперь далеко и не оптимально разведена, предлагает указать в (xxx.ucf) микроблейза для неё параметр "dedicated", предупреждает, что всё может плохо синхронизоваться.

Спасибо.




Благодарствую, попробую на днях поковырять, застрял что-то на ерунде...

Интересно, через сколько тактов после подачи активного уровня на ногу внешнего прерывания, процессор считывает данные с i-порта GPIO?
Можно ли в отладчике SDK увидеть время исполнения команд, типа stopwatch в MPlab микрочипа.

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

Выбирая между скопировать старое, или еще раз сделать новое, в отношении ксалинкса, я выбирают сделать новое. 2 Дня бился с багой, оказалось что как-то не так при повторном экспорте сделались библиотеки, и все что я менял в заголовках и прочее, не имело никаких действий, так как бралось из кривых библиотек. Так что при пересборке ядра, лучше вообще новый железный проект сделать, а потом еще почистить, а потом только старые проекты запихивать, и их почистить... криво там все работает...

100% результат если вы все сделали с 1 раза, вот так и ходите, ни шагу назад.

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

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

Можно его самому через GPIO сгенерить, записав время таймера до вывода данных, а потом повторно уже в прерывании проверить значение таймера, после считывания и все узнаете.

Создал процессор в planAhead, стал подсовывать туда же проект ISE, в котором файл верхнего уровня - схема, как её в planAhead засунуть, она видится только списком соединений, от которых голова идет кругом... ))

отставить planAhead, нужна другая программа на букву p - Platform Studio!

Так ведь и из ISE навигатора, что из PlanAHead, при добавлении embedded в проект, все пути ведут к xps.
Я полагал, что есть разница с какой проги начинать.

З.Ы. Высота 10 килобайт в сек, через gpio - микроблейз - udp взята. 100 килобайтных пакетов по прерыванию gpio с ходу не пролезают. ))

так рассуждая, надо все писать в блокноте, или сразу в машинных кодах.

Platform Studio - средства создания систем с микроблайзом, подключения к нему периферии и подготовки проекта к програмингу. В конечном итоге микроблайз то-же IP ядро, потому его естесвено можно подключить откуда угодно, но в Платформ Студии это удобнее и правильнее.