[DASM 0]

Задачка такая. С сенсора оптического собираю данные, 12 бит параллельная шина, клок 96 Мгц. В ФПГА можно организовать небольшой буфер (два), которые по заполнении делают прерывание для DMA центрального проца. Он тогда забирает данные и кидает их в DDR. (вернее DMA engine это делает через AMBA 2 AHB-Lite). Тогда мой модуль должен быть слейвом на шине. Второй вариант - модуль в ФПГА наооборот мастер на шине, опять таки AHB-Lite и сам кидает данные в ДДР все через тот же ДМА. Вот чего-то я тут как-то затупил, что собственно лучше использовать.. Есть идеи ?

[Raven 8]

Я бы сделал в духе сетевых адаптеров. Это примерно соответствует второму варианту (сам себе мастер на шине), но дополнительно имеет также список буферов и их дескрипторов (обычно завязанный в ring). Начать можно с простого (CSRs + пара дескрипторов на регистрах), а потом развить до предела фантазии и необходимости.

[DASM 0]

Честно говоря, идею не понял

[yes 5]

я бы делал в FPGA слейва, а ЦП мастером (ЦП это отдельный чип/хардкоре? хотя без разницы)

делал для DSP-шек (TI) внешних мастеров на ПЛИС - геммора больше

 

мастера в ПЛИС имеет смысл делать если времянка очень жесткая (то есть обработать прерывание латенси всяко хуже, чем у захвата шины) и без гемора никак

[DASM 0]

Нет, это двуядерник Zynq с FPGA на одном чипе. Просто я пока не очень представляю, какая максимальная латентность в Линуксе реакции на прерывание - чтобы DMA запустить по надобности успеть. При таком траффике мне внутри ФПГА большого буфера то не сделать (560 KB

block ram) - на 4 мс всего, да и отдавать его весь тоже не вариант. С шинами тут несколько попроще, мне шину полностью (в смысле монопольно на большок кол-во трансферов) никто не даст захватить, у Fabric довольно низкий приоритет.

[krux 8]

DASM

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

[yuri_t 0]

Eсли работаете с Linux, то, IMHO, для скоростных обменов данными нужно пользоваться Network-like подходом: co стороны Software

можно взять уже существующие механизмы - sk_buff etc., со стороны hardware - device должен с помощью DMA загружать несколько буферов

в памяти, и потом только вызывать прерывание (Linux NAPI etc.)

 

[DASM 0]

Ну да, поток должен быть непрерывным (пока хотя бы кадр), матрица ждать не будет.С софтом я разберусь, меня и подход v4l устраивает.Вопрос то хардворный скорее. Понятно, что это относительно новый вопрос, раньше то кушали что дают. Но рассматривая процы со встроенным интерфейсом к камере я не понял, в какой роли на шине он там.Похоже все же ДМА мастер.

[yuri_t 0]

Ну да, поток должен быть непрерывным (пока хотя бы кадр), матрица ждать не будет.С софтом я разберусь, меня и подход v4l устраивает.Вопрос то хардворный скорее. Понятно, что это относительно новый вопрос, раньше то кушали что дают. Но рассматривая процы со встроенным интерфейсом к камере я не понял, в какой роли на шине он там.Похоже все же ДМА мастер.

 

А откуда CPU знает, что сейчас real-time device должен сбрасывать содержимое в память? Поллинг или прерывания - неэффективно.

Real-time device должен быть ДМА мастер.

 

 

[DASM 0]

Ну да, вероятно мастером и сделаю.

[Golikov 0]

Немного не в тему, как цинк сам по себе? Юникс легко поднялся? Как организована связь с ПЛИСовой логикой?

[DASM 0]

Цинк великолепен. И новая среда проектирования Вивадо. Надо будет сравнить с ARM DS5, но по сравнению с USE прямо чудо. АРМы связаны с фабрикой тесно, посредством шин понятно дело. Та же AXI дает такую пропускную способность, что даже загрузить сложно. Умный snoop арбитр с приоритетом шин — это вам не как в НИОС завесить всю систему , ошибившись с сигналом готовности. Вообще много всего, на одной такой борде и АРМ с шинами освоишь, и многопроессорное вычисление (хочу ассиметричное освоить, Линукс на одном, а на втором рилтайм типа vxWorks . Ну и ФПГА на борту не самая то и дохлая, 106.000 флипфлопов и 220 умножителей, 276GMacs. В общем если ест желание расти профессионально — советую. Перечитываю дифф. и интегральное исчисление учебник, жалею что в ВУЗе нам не объяснили, что это действительно нужно. ( хочу на фабрике кодер jpeg2000 сделать). Короче планы наполеоновские, лишь бы время. Жутко жаль того времени, когда работал в "стабильной компании с хорошим доходом», а на самом деле в машине по убиванию интереса к новому. Вообще если не жаль 470 бачей — берите, дешевле частному лицу без всякого геммора с курьерскими службами я не нашел, да и не жалко. Вскоре в ЭФО должны SocKit появится, Альтера, суть платы и чипы одинакова, но альтеровский 300 с чем то вроде. ..Заговорился, Линукс на борту уже стоит, пересобирать не пробовал, мне еще с похожей системой на Актеле надо работать, правда там uCLinux и проц всего лишь Кортекс м3.

[Golikov 0]

Да мне от фирмы купят:) мы под проект его планируем, только боязно брать, новый он, для нас во всяком случае...

спасибо за отзыв, покумекаем...

 

 

А да еще вопрос, что за среда разработки? Как под проц без юникса писать?

[DASM 0]

Да мне от фирмы купят:) мы под проект его планируем, только боязно брать, новый он, для нас во всяком случае...

спасибо за отзыв, покумекаем...

 

 

А да еще вопрос, что за среда разработки? Как под проц без юникса писать?

Под арм писать на чем угодно ессно, от гцц до попсового иар. Под ФПГА ISE или Vivado (поглядите курсы на ютубе, впечатляет.) Вивадо не на базе Simplify, разводит иначе, но я тут пока не гуру что лучше. А новизны чего бояться то, судя потомуй, что и несчастныйй Андроид поднят — критичных багов нет. Хотя с Циклоном5 я постараюсь тоже хоть немного поработать. Главный инструмент это все же голова и Матлаб, плэйс энд роут вторичны. Не могу понять в соревнованиях Альтеры с Ксайлинксом — кто тут Интел, а кто АМД :) Хотя крайняя Терасиковскаяц борда с Атомомц как бы намекает. Мне такой вариант неинтересенц, еше немное и микрософтом запахнет

[Golikov 0]

понятно спасибо.

 

В проекте не хочется воткнуться в ошибки которые ограничат рассчитанную функциональность... Надо будет на стар ките погонять конечно...