[Ya_Mike 0]

Всем доброго времени суток,

 

Возник вопрос в выборе интерфеса для передачи данных от ПЛИС(Spartan6) к АРМу(arm926ej-s).

На арме - линукс с ядром 3.х.х. Плис будет постоянно обмениваться данными с армом небольшими порциями (пока не определился, какого размера их сделать), поток - оринтировочно 128 кБит/с туда и столько же обратно (*3). При этом АРМ должен будет при старте загрузить прошивку в неё(*2), а при работе - считывать некоторые статистические данные помимо этого основного потока (*1). Итого, получается три "потока" данных.

Есть идея выделить под:

*3 - по EBI интерфейсу,

*2 + *1 - по SPI, (либо всё-таки по отдельным интерфейсам передавать?)

В наличии ещё gpio есть, но думал их использовать для сигналлинга в случае SPI (когда slave что-то хочет сказать master-у).

Так как такая задача возникла впервые, то есть сомнения в правильности выбора интерфейсов. Ко всему, хочется как можно меньше нагружать систему. Буду благодарен, если кто-нибудь сможет посоветовать, где при таком выборе интерфейсов разложены грабли и какие проблемы могут возникнуть.

[faa 4]

Всем доброго времени суток,

 

Возник вопрос в выборе интерфеса для передачи данных от ПЛИС(Spartan6) к АРМу(arm926ej-s).

На арме - линукс с ядром 3.х.х. Плис будет постоянно обмениваться данными с армом небольшими порциями (пока не определился, какого размера их сделать), поток - оринтировочно 128 кБит/с туда и столько же обратно (*3). При этом АРМ должен будет при старте загрузить прошивку в неё(*2), а при работе - считывать некоторые статистические данные помимо этого основного потока (*1). Итого, получается три "потока" данных.

Есть идея выделить под:

*3 - по EBI интерфейсу,

*2 + *1 - по SPI, (либо всё-таки по отдельным интерфейсам передавать?)

В наличии ещё gpio есть, но думал их использовать для сигналлинга в случае SPI (когда slave что-то хочет сказать master-у).

Так как такая задача возникла впервые, то есть сомнения в правильности выбора интерфейсов. Ко всему, хочется как можно меньше нагружать систему. Буду благодарен, если кто-нибудь сможет посоветовать, где при таком выборе интерфейсов разложены грабли и какие проблемы могут возникнуть.

ИМХО, вешать FPGA на EBI и все делать через этот интерфейс. Для программирования написать драйверочек - там нужны будут еще -две-три (или четыре) ноги gpio с ARM (для PROG, INIT, DONE и т.п.).

После программирования можно через /dev/mem обмениваться (или через драйвер). Ну и при желании можно прерывания попользовать.

Примеры есть в инете. Если не найдете - помогу ссылками.

Изменено 30 марта, 2012 пользователем faa

[litv 0]

А как же AXI - плис в арм ? ( http://www.xilinx.com/support/documentatio...rence_guide.pdf )

[faa 4]

А как же AXI - плис в арм ? ( http://www.xilinx.com/support/documentatio...rence_guide.pdf )

Если в Spartane AXI еще изобразить можно и вытащить наружу, то в ARM-е (судя по краткому описанию от ТС) до нее достучаться вряд ли получится (да ее там еще и нет, скорее всего).

 

[Ya_Mike 0]

faa, спасибо за отлик!

 

ИМХО, вешать FPGA на EBI и все делать через этот интерфейс. Для программирования написать драйверочек - там нужны будут еще -две-три (или четыре) ноги gpio с ARM (для PROG, INIT, DONE и т.п.).

После программирования можно через /dev/mem обмениваться (или через драйвер). Ну и при желании можно прерывания попользовать.

Т.е. я правильно понимаю, что работа через EBI - это, по сути, обмен через определенный участок памяти?

Наверное, лучше будет через драйвер все делать, так как прерывания будут нужны наверняка. А ног gpio заведено с запасом, поэтому хватит на всё.

 

Примеры есть в инете. Если не найдете - помогу ссылками.

Нашёл на kernel.org пример драйвера carma-fpga. Пока что его изучаю, но если есть на примете более удачные (покороче) примеры - буду рад.

 

А как же AXI - плис в арм ? ( http://www.xilinx.com/support/documentatio...rence_guide.pdf )

В arm926ej-s есть поддержка только второй версии AMBA (AHB), а AXI появился в третьей версии.

Не могли бы вы сказать, в чем преимущества использования AXI по сравнению с использованием EBI?

[faa 4]

Т.е. я правильно понимаю, что работа через EBI - это, по сути, обмен через определенный участок памяти?

Наверное, лучше будет через драйвер все делать, так как прерывания будут нужны наверняка. А ног gpio заведено с запасом, поэтому хватит на всё.

Правильно.

Я пристегивал Xilinx (Spartan-3, Virtex-5) к EP93хх (ARM от Cirrus Logic) (и не только к ним) к системной шине (статической)

с выделением двух чипселектов (CS1 и CS7). Младшие разряды данных (0-7) строго на ножки данных для Select Map Slave,

старшие как лягут (только в "правильный" нужный банк их надо). Шину данных и 16 и 32 разряда делал.

Для программирования надо три сигнала с GPIO - два в fpga (INIT, PROG), один (DONE) обратно.

M0-M2 можно запаять на постоянку для select map slave или вытащить на джамперы (у меня на тестовых можно еще через jtag зашить).

Драйвер для программирования есть - лежит на ftp.

Там же костылик для заливки прошивки в fpga.

INIT потом можно еще попользовать для общего сброса модулей в fpga.

После прошивки можно работать через /dev/mem.

Что-то типа такого:

   fpgaDesc = open("/dev/mem", O_RDWR | O_SYNC);
   if ( fpgaDesc == -1) goto fpga_error;

   mapped_size = getpagesize();
   page_size = getpagesize();
   offset_in_page = ((unsigned int)FPGA_ADDR) & (page_size - 1);

   if ( offset_in_page + 20 > page_size)
       mapped_size *= 2;

   fpga_base = mmap(NULL, mapped_size, PROT_READ | PROT_WRITE, MAP_SHARED, fpgaDesc, ((off_t)FPGA_ADDR)&~(off_t)(page_size-1) );

 

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

 

Есть еще камни Spear600 и Spear13хх от STM. Там у них есть возможность через мост достучаться прямо до матрицы AHB.

Но назначение ножек и полная дока только под NDA - видимо свои косяки скрывают ;)

Ну и Zynq от Xilinx- там все в одном флаконе: и fpga, и Cortex-A9 (два ядра), и мосты master и slave для общения напрямую.

Изменено 1 апреля, 2012 пользователем faa

[Ya_Mike 0]

faa, доброго времени суток вам,

 

Драйвер для программирования есть - лежит на ftp.

В драйвере, что на фтп, обнаружил одну маленькую проблемку на 150 строке: while (fpga_done_read == 0) {..} - этот цикл не выполнится ни разу, а пользователь может не узнать, что возникла проблема.

 

Вообще большое спасибо за ваш пост, очень помог!

 

 

[ilya_blazer 0]

Всем доброго времени суток!

 

Уважаемый faa, а если использовать для загрузки конфигурационной последовательности из ARM в FPGA последовательный интерфейс?

( Для Spartan6, с которым я работаю сейчас, это UG380, страница 26(

Тогда для загрузки конфигурационного файла требуется 5 gpio pin ARM( два- для побитовой передачи файла в FPGA, соответственно данные и такт, и еще три для контроля ПЛИС, PROGRAM_B -сброс FPGA, DONE - конфигурация выполнена,INIT_B - загрузка прошивки в FPGA без ошибок).

Вы не пробовали подобный способ загрузки?

[faa 4]

Всем доброго времени суток!

 

Уважаемый faa, а если использовать для загрузки конфигурационной последовательности из ARM в FPGA последовательный интерфейс?

( Для Spartan6, с которым я работаю сейчас, это UG380, страница 26(

Тогда для загрузки конфигурационного файла требуется 5 gpio pin ARM( два- для побитовой передачи файла в FPGA, соответственно данные и такт, и еще три для контроля ПЛИС, PROGRAM_B -сброс FPGA, DONE - конфигурация выполнена,INIT_B - загрузка прошивки в FPGA без ошибок).

Вы не пробовали подобный способ загрузки?

Там еще (если мне склероз не изменяет) и CSI_B нужен будет.

Вариант просматривался, а так же и вариант с JTAG (тут только 4 GPIO потребовалось бы).

Но если FPGA будет взаимодействовать с ARM по параллельной шине, то зачем громоздить еще один интерфейс?

Я сделал при программировании так (режим selectMAP):

CSI_B - CS соответствующего банка ARM от static memory controller

СCLK - напрямую сигнал WR с ARM

DATA0-DATA7 - младший байт шины.

(согласование уровней по управляющем сигналам резисторами - есть соответсвующий UG и XAPP)

RDWR_B - не использовал (не было необходимости читать обратно прошивку) - всегда запись

При этом FPGA при загрузке работает в интересном режиме - смесь "SelectMAP Non-Continuous Data Loading with Controlled CSI_B" и

"Non-Continuous SelectMAP Data Loading with Controlled CCLK", что напрямую из DS не следует, но функционирует.

Вот схемка для vrtex5. JTAG тоже присутствует, он ChipScope используется и параллельно заведен на ARM (на всякий случай ;))

 

 

В драйвере, что на фтп, обнаружил одну маленькую проблемку на 150 строке: while (fpga_done_read == 0) {..} - этот цикл не выполнится ни разу, а пользователь может не узнать, что возникла проблема.

Спасибо, посмотрю, поправим.

Изменено 26 апреля, 2012 пользователем faa

[hlebn 0]

Вариант через JTAG - самое то (требует только 4 пина от микроконтроллера. желательно SPI)

без проблем пристегивал Xilinx (Spartan-3, Virtex-2, Virtex-5) к ( EP93хх, AT91SAM9xxx, STM32F103 )

[1891ВМ12Я 0]

Обладаю устройством SK-AT91SAM9G45-XC6SLX - в качестве примера можно взять её, и заодно посмотреть как там сделан SPI "зашивалка" в ПЛИС на базе GPIO.

 

Как раз недавно делал обмен между ПЛИС и ARM - там для этого есть шина EBI (SMC контроллер). У меня получилось выжать 140 мегабит, но это не предел, там еще есть возможность выжать наверное все 500, просто я тайминги медленные задал.

 

А работал как раз через /dev/mem - вполне неплохо. Но конечно для прерываний нужно писать драйвер.

 

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

 

P.S.

Если всего 128 кбит/c - имеет ли смысл вообще городить через шину памяти? Я бы просто взял SPI... Или даже I2C если он быстрый достаточно в конкретном проце.

[ilya_blazer 0]

Доброго дня!

 

Уважаемым faa и hlebn огромное спасибо за данные советы)))

 

Уважаемый AVR, как раз эта плата была взята за основу, с нее я взял подключение процессора и плис.

Насчет синхронизации, в исходном варианте плис тактуется от процессора, но в моем случае тактование раздельное, а для передачи данных по SPI достаточно только тактового сигнала на этом интерфейсе, ведь он асинхронный.

 

Что касается шины EBI, то пока ее реализация отложена, возможно она и не пригодится( к началу разраобтки проекта просто не было достаточного опыта, и поэтому сделал с максимальным запасом, в том числе по скорости интерфейсов.