habenskiy

Всем привет! В наличии две платы Kintex 7 Evaluation Kit и одна плата FM-S14 Quad SFP/SFP+. При работе столкнулись с парой проблем: 1) в проекте задействован PCIe. Одна плата работает во всех системных блоках, другая, с той же прошивкой, выборочно (не работает в одном из системных блоков). В наличии три системных блока с разными мат. платами, по этому к сожалению нет возможности проверить на разных мат. платах одного вида. В проекте используется PCIex8. В таком режиме плата отсутствует в списке устройств. При переводе на PCIex4, плата видится, но не работает. 2) при использовании платы расширения FM-S14 один из четырех портов не работает с SFP 10Gbit (оптика, имеет поддержку 1Gbit). С SFP 1 Gbit (медь) - работает. Причем если использовать туже SFP 10Gbit (оптика), но в режиме 1Gbit - работает. Обе проблемы наблюдаются на одной из плат, на другой все работает. Когда столкнулись с проблемой PCIe, проверили трансиверы с помощью готовой прошивки из мануала KC705 GTX IBERT Design Creation (там есть вариант для "самодиагностики без проводов") - все работает. Подскажите в чем может быть дело и можно ли это вылечить? :-)

Данный тестбенч находится в проекте примера. По сути просто выбираете "Run Behavioral Simulation" и ждете результата. Я вот как раз и хотел взять какой то готовый пример, и посмотреть как и что в нем реализовано, а за тем уже прикинуть что нужно заменить. А то уже чем больше нахожу информации, тем больше погружаюсь в мрак - все таки одной теорией сыт не будешь, нужно что то железячное (по моему данный пример от xilinx подходящий для этой цели). А в какую сторону вы хотели бы отойти от AXI? Он же вроде довольно прост - шина даных (tdata), сигнал валидности данных (tvalid), сигнал готовности принимать данные (tready). Остальные сигналы "расширяют возможности". Это касательно AXI-Stream, а он как раз у нас и используется. С остальными типами AXI сложнее. Или вы имеете в виду вообще какой то другой интерфейс, более заточеный под определенный круг задач (как в этой статье http://habrahabr.ru/post/244997/ интерфейс target)? И все же - кто-нибудь может подсказать, что за активность идет, в мною описаном примере? Да и помочь разобраться с самой структурой транзакций... А то если взять примеры и сравнить, что то не складывается: axis_rx_tdata: 01a0_0a0f_0000_0001 de03_7320_0000_0010 (tkeep = 0f) axis_[b]tx[/b]_tdata: 01a0_0004_4a00_0001 0403_0201_01a0_0a10 01a0 - ID отправителя (почему совпадает для обоих случаев?). 0а - Tag. Что то вобще не понял его назначние "Tag[7:0] is an 8-bit field generated by each Requester, and it must be unique for all outstanding Requests that require a Completion for that Requester" - вроде как уникальное поле для каждого запроса. В данном случае, насколько я понял, выбрали порядковый номер. Но тогда не понятно как он распределяется (его изменения: 0, 0, 1, 2, ..., d, 0, 1, 2, ..., a). 0f (для axis_rx_tdata) / 04 (для axis_tx_tdata) - на сколько я понял это Byte Enable (Last/First). Про Last и First для axis_rx_tdata вроде понятно "If the Length field for this Request indicates a length of 1 DW, then the value for the 1st DW Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied to be 0000b.", а вот First для axis_tx_tdata - не понятно. Следующее DW вроде понятно - тип транзакции и длина. Следующее DW вроде тоже понятно - данные. 0000_0010 - адрес и PH (кстаи так и не понял про это PH). Для axis_rx_tdata вроде без вопросов, а вот для axis_tx_tdata опять в ступоре...

Здравствуйте. Так же столкнулся с задачей реализации PCI Express на плате Xilinx. Как понимаю вы так же запускали пример контроллера памяти на основе Integrated Block for PCI Express. Разбирались ли вы что там к чему? Уже какой день не могу понять как и что в нем работает... Как я понимаю на сам ip возлагается задача инициализации в системе, фильтрация запросов (пропускает только то, что относится к нашей плате, и не пропускает то, что относиться к другим устройствам подключеным по PCIe), а так же преобразование в пользовательский AXI-интерфейс. Так ли это? Просто я запустил тестбенч от этого примера и вижу следующую картину: 1) сперва появляются данные на дифпарах pci_exp_rx и pci_exp_tx. На AXI - тишина. Предполагаю что в этот момент как раз и идет инициализация платы. 2) затем появляются данные на axis_rx_tdata, такого вида: 01a0_010f_0400_0001 (04 - конфигурационное чтение?) d538_d087_01a0_0064 (судя по axis_rx_tkeep=0f d538_d087 нам безразлично) 01a0_000f_4400_0001 (44 - конфигурационная запись?) ffff_ffff_01a0_0010 01a0_010f_0400_0001 8881_01bb_01a0_0010 (аналогично axis_rx_tkeep=0f) 01a0_020f_4400_0001 ffff_ffff_01a0_0014 01a0_030f_0400_0001 d151_f891_01a0_0014 (аналогично axis_rx_tkeep=0f) так повторяется еще для адресов 18, 1с, 20, 24, 30 (если я правильно понял что в ffff_ffff_01a0_00[14] это адрес). Затем начинается следующая группа данных: 01a0_000f_4400_0001 0000_0000_01a0_0010 01a0_010f_4400_0001 0000_0000_01a0_0014 так повторяется для тех же самых адресов и добавляется следющие: 01a0_0701_4400_0001 0300_0000_01a0_0004 01a0_0801_4400_0001 5f00_0000_01a0_0068 но при этом сигнал валидности axis_rx_tvalid в нуле. 3) вместе с данными появляется сигнал валидности: axis_rx_tdata: 01a0_090f_4000_0001 (40 - запись?) 0403_0201_01a0_0010 axis_rx_tdata: 01a0_0a0f_0000_0001 (00 - чтение?) de03_7320_0000_0010 (tkeep = 0f) axis_[b]tx[/b]_tdata: 01a0_0004_4a00_0001 (4a - завершение чтения?) 0403_0201_01a0_0a10 Вот и не могу понять что за данные передаются без сигнала валидности, что за данные [15:0] во-втором DW и что за данные в третьем DW на axis_tx_tdata... Если разбирать по полям правильно ли я понимаю на примере: 01a0_0a0f_0000_0001 de03_7320_0000_0010 01a0 - Requester ID 0a - Tag 0f - BE 0000_0001 - атрибуты и порядковый номер de03_7320 - данные 0000_0010 - адрес ? Попробовали ли вы действовать по этому сценарию? Получилось ли что то?

Спасибо за совет. Еще раз внимательнее пересмотрю этот референс дизайн. В предыдущий раз сложилось впечатление, что там просто пошаговая инструкция, как запустить их готовые примеры по типу "мы уже все сделали, ваша задача найти нужную папку, а в ней файл прошивки, загрузить в плату и смотреть, что все работает". Причем со сторонним ядром Northwest Logic. Что ж - еще раз пересмотрю, может действительно упустил какое то описание/подробности.

Всем привет. Есть в наличии Xilinx Kintex-7 FPGA KC705 Evaluation Kit. Хочется разобраться с использованием PCIe. В конечном итоге нужно сделать связку FPGA-PC. В этой связке компьютер задает начальные критерии. Плата, на основе этих критериев, как то обрабатывает данные и передает результат по PCIe обратно в компьтер. Для примера: плата является ethernet-мостом, который может оборвать соединение с конечным устройством, если будет передано сообщение, неудовлетворяющее критериям, и сообщить компьютеру, какое сообщение и по какому критерию не прошло. Начал разбираться сам, но от обилия информации только каша в голове. Как вижу я последовательность действий: 1) собрать для начала пример, в котором плата будет просто отвечать на запросы от компьютера (например зажигать/тушить светодиод). Примеры в вивадо основаны на работе с памятью. Таким образом от компьтера команда выглядит как адрес регистра функции чтения/записи, а данные это - просто адрес для чтения, и адрес/данные для записи - так ли это? Если это так, то для случая со светодиодом как это будет выглядеть? 2) разобраться как для этого дела написать драйвер по linux. 3) собрать пример, где помимо светодиода, будет еще задействована какая-нибудь кнопка, и привязать к ней какое-нибудь элементарное действие, например переключение раскладки (может быть это и не очень элементрано - не знаю). Соответственно в проект нужно будет добавь не достающее (как я понял это dma). 4) доработать драйвер. На этом как бы идеи и представления как реализовать пропадают... Конечно хотелось бы увидеть уже готовые примеры. Может пока искал информацию, что то пропустил. Но для начало бы было достаточно тыкнуть носом в подходящие доки хотя бы по первым двум пунктам, а так же подсказать где искать про сам PCIe, а то все что находил либо совсем про низкий уровень (параметры элементной базы, допустимые напряжения и т.д.), либо совсем поверхностно... В ходе поисков был найден xapp1171. Подойдет ли он для реализации пункта 3? На сколько сложно будет написать драйвер основываясь на данном xapp?

Прошу помощи в разборе двух интефейсов - gmii и xgmii. Стоит следущая задача: есть сервер и клиент, которые общаются по tcp/ip. Между ними нужно вставить fpga, которая будет анализировать данные, которые поступают от клиента, и если данные плохие, то обрывает соединение. FPGA подключается с помощью двух портов SFP - один к клиенту, другой к серверу. Между собой SFP подключаются либо по gmii, либо по xgmii. В это место и подключается наш анализатор. Изучая стандарты на gmii и xgmii (ieee 802.3) так и не понял в каком случае выставляется сигнал ошибки и как следствие, не могу понять как на него должен реагировать анализатор - либо просто пропустить ошибочные байты, либо пропустить весь фрейм. Как будут реагировать на такой фрейм клиент и сервер - будут делать перезапрос (tcp/ip)? Вопрос касательно только gmii: из стандарта как я понял есть два типа ошибок - Propagating an error within a frame и Propagating an error within carrier extension. Для первого случая вроде бы это ошибка в данных, но там есть предложение "When TX_ER is asserted for one or more TX_CLK periods while TX_EN is also asserted, the PHY shall emit one or more code-groups that are not part of the valid data or delimiter set somewhere in the frame being transmitted.", которая наводит на мысль, что это вовсе не ошибка, а просто байты, которые не относятся к данным. Так что же это? Для второго случая вобще не понятно, что это за "carrier extension" и что за ошибка там может быть... Есть подозрение, что это какая то информация о свойствах соединения. Тогда в этом случае нету ли того же самого в xgmii?

Спасибо за совет - будем обсуждать. Наверно действительно мы поторопились, выбрав линукс, при этом плохо изучив что есть помимо. Выбор на него пал, так как это первое что пришло в голову с наличием как раз таки полного езернета. По-сути мы сейчас не столько нацелены на результат, сколько на то, что бы пощупать и оценить сложность. Но в любом случае без микроблейза никуда =) И вроде уже есть подвижки в этом деле.

Спасибо за ответ =) Абсолютно правы - я в этом ноль. Но надо же с чего то начинать =) Сейчас как раз вот и занимаемся поиском каких то готовых сборок и пошаговых инструкций. Про то что нужен или нет - нам сказали, мы арбайтен =) Про операционку от ксайлинкса - вы про петалинукс?

Большое спасибо! Получилось наконец создать работающий download.bit из hellow_world_0.elf. В примере был сгенерирован линкер скрипт таким образом, что только первой секции, та что "Code Section Assignments", была назначена BRAM, остальные в DDR. Заменил на BRAM и все запустилось. А можно поподробнее про линкер скрипт и секции? А точнее наверно только про секции, так скрипт сам собой генерируется, - что храниться в каждой из них (тут вроде более или менее понятно: первая секция - первая команда программы; вторая - переменные, константы и т.д.; третья - стек) и какая память, в каких случаях для них нужна? Информации много и поэтому сложно в ней сориентироваться, тыкните носом если можно. А то боюсь опять уйти в какие-нибудь дебри. Что бы сузить критерии, могу сказать, что цель проекта - запустить на плате линукс, который будет взаимодействовать остальной логикой.

Да, есть такой бит файл - download.bit. Но как я писал, он у меня получался только с mb_bootloop_le.elf. И да - в примере, который использовали, есть DDR. Не подскажите, где можно посмотреть про создание отдельного загрузчика? В Vivado 2014 выпилили совсем impact, осталось только само Vivado и SDK. В этом и загвоздка - все туториалы, что я находил, ссылаются на ISE или Vivado 2013, где есть impact или полноценное EDK.

"Program FPGA" заливает только во ОЗУ. При чем, когда я там пробовал подсунуть вместо mb_bootloop_le.elf hellow_world_0.elf из примера, он у меня ругался на кривой elf файл.

(тихо сам собой веду беседу) Возник вопрос - а туда ли я копаю? Поясню задачу: нужно самое простое - собрать microblaze с какой либо прошивкой, и что бы это все работало после выключения. Может мне и не нужна прошивка во flash? Появилась такая мысль: 1) собираем проект microblaze в vivado. 2) экспортируем в SDK. 3) пишем прошивку, тестируем её в SDK. 4) добавляем получившийся hellow_world.elf в проект в vivado (тут два варианта: 1) "Add source" в "Design Source"; 2) "Associate ELF Files"). 5) пересобираем проект.

За вчера выяснили некоторые детали. В SDK, когда выбираем "Program FPGA", создается download.bit (как и писали в одной из тем на форуме), на основе system.bit, system_bd.bmm, которые как я понял экспортируются из Vivado, и mb_bootloop_le.elf, который берется из установочной папки Vivado. Данный elf файл, как я понял, является загрузчиком для других elf-файлов, а именно тех, которые сформированы на основе С-программ (из примера это hellow_world_0.elf), и загружаются в ОЗУ, когда мы нажимаем "Run As" в SDK. Таким образом нам нужно как то либо объединить mb_bootloop_le.elf и hellow_world_0.elf, при этом bootloop должен быть изменен так, что бы загрузка происходила уже не из ОЗУ, а из ПЗУ, либо создать такой hellow_world_0.elf, который будет загружаться сам. Из того, что успели попробовать: на основе download.bit был создан файл для прошивки в ПЗУ, прошили его и попробовали без всяких прошивок в SDK запустить "Run As" для примеров из ссылки выше (hellow_world, board_test_app_Console, board_test_app_Webserver) - все запустилось. Попробовал, при создании download.bit указать hellow_world_0.elf вместо mb_bootloop_le.elf - вылетает с ошибкой. Если выбрать "Program Flash" в SDK, то при прошивке hellow_world_0.elf что то записываается в память, но что то неработоспособное (все светодиоды, 8 штук, которые на плате - горят, хотя при рабочем варианте они все потушены). Если в окошке настроек "Program Flash" поставить галку "Convert ELF to bootloadable SREC format and program" - тоже самое. Возможно нужно колдавать с "Program at offset" - но от куда берется это значение, на каких данных основывается? Прикрепляю скриншот окошка "program Flash" и "Generate linker script" - может что подскажет

Приветствую. Имеется Kintex-7 FPGA Embedded kit. Помогите разобраться с прошивкой microblaze в постоянную память (BPI). Делал по инструкции от сюда http://www.wiki.xilinx.com/K7+Embedded+TRD+2013.2 . Все получилось, все хорошо. Но встал вопрос о том, как это все залить в постоянную память. Поискав информацию, натыкались только на ISE. Хотелось бы узнать, что необходимо для Vivado кроме SDK и какая последовательность действий.