Всем привет!

Простой вопрос: как в Xilinx SDK получить вид с регистрами периферии? Пока что могу видеть только регистры процессора и его окружения (SCU, кэши, сопроцессоры). Пробовал задать Hardware Platform (втянуть *.hdf файл), но ничего не появилось.

вы это имеете ввиду?



когда делаете в vivado export-hardware то в SDC появится папка автоматически с файлами вместе с *.hdf

Да, пробовал создать Hardware Platform на основе этого файла, но ничего нового (ожидал увидеть возможность добавить окно с регистрами периферии) не обнаружил. Кстати, насколько понял, этот файл - это просто архив, в который входят ps7_init.c, ps7_init.h, ps7_init.tcl, ps7_init.html и т.д. Не очень понятно, что там является файлом с описанием регистров периферии. Например, в DS-5 для этого служат *.svd файлы, поставляемые вендорами процессоров (или генерируемые их программами - в частности, как у альтеры Qsys).

а как выглядят "регистрами периферии" у альтеры Qsys ?
что-то типо того как в #include "xparameters.h" и #include "xparameters_hw.h" ?

Для альтеры в DS-5 уже есть файл на всю периферию HPS, это xml файл с записями вида


Выглядит это примерно как показано в этом посте.

Помимо этого ещё Qsys/Quartus генерит svd файл (по формату это xml), который согласно документации содержит описание периферийных регистров. Но я его не подключал, мне хватало того, что есть в DS-5. Собственно, я и ищу в SDK аналог - возможность увидеть регистры периферии PS (клоки, сбросы, маки, усб, уарты и т.д.). И не нахожу.

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

Похоже, в Xilinx SDK это невозможно , всегда пользуюсь окном Memory

Чтобы не создавать новую тему, тут спрошу.

Речь опять о периферийных memory-mapped регистрах и их потрохах. Как правило, программные пакеты от вендоров имеют в своём составе директорию типа include, где лежит ворох *.h файлов с определениями регистров периферии и прочим. Обычно это тыщи макроопредлений вида:



Сколько не искал в xsdk, не нашёл ничего похожего. В примерах попадаются какие-то файлы, которые что-то фрагментарно описывают - xparameters.h, xparametes_ps.h, xiluartps.h, xiluartps_hw.h и т.д. Но это, во-первых, не с пакетом поставляется, отдельно надо искать и собирать по частям, а во-вторых, и в-главных, это всё какие-то частные куски, нету цельного описания всех регистров и их битов (масок, позиций).

Вопрос: их нет, потому что никому не надо - все на цинке запускают линух и работают с периферий с помощью предоставленных драйверов? или их нет..., потому что просто нет, и если кому надо, то он сам себе частным порядком создаёт эти описания?

dxp
Прошу прощения, что не по теме, интересуюсь просто - какой компилятор использует Xilinx для процессорных ядер в Zynq?
DS-5 от ARM, насколько я понимаю - не используется?

Сами-то ядра те же самые - Cortex-A9, поэтому компляторы там одни и те же. Это либо ARM, либо GCC (arm-none-eabi). Для сборки оболочку (IDE) не использую, поэтому мне без разницы - DS-5 это, XSDK или что угодно другое. Оболочка мне нужна только как отладчик. DS-5 в этом контексте сделана очень хорошо, в том числе есть поддержка всех периферийных регистров - удобно наблюдать за их содержимым и/или вносить в них изменения. Ещё консоль команд по функциональности почти как у GDB, мощные возможности по скриптингу. XSDK, к сожалению, по всем перечисленным фичам сливает по полной.

Заголовочных файлов с описаниями периферии в составе тулчейнов нет - ведь они же (тулчейны) общие для многих платформ, но конкретный вендор обычно дополняет их описанием под свои микросхемы. У Альтеры это есть в составе HWLib (не к ночи будь помянута), но описание сделано безобразно. А вот у Зайлинкса нет даже этого - есть только какие-то фрагменты (или я не там искал). Всё это неструктурировано, несистематизировано, размазано по примерам, в общем, какое-то частное решение, имхо, малопригодно для комфортного использования.

dxp
Понятно, спасибо.
Альтеровская HWlib, кстати, неплохо помогает освоиться с армом, считаю её большим подспорьем.
Странно, что у гораздо раньше появившегося цинка нет аналога...

Не могу согласиться. Качество кода негодное, пользоваться очень неудобно, моё имхо. У Xilinx есть аналог - embeddedsw (на их странице на гитхабе есть репозиторий), там весьма много материала "для подспорья", качество кода тоже так себе (везде индусы), но выше, чем у альтеры.

То, что не нравится - всегда можно подправить под себя, гораздо хуже, когда и править-то нечего, так как нету ничего

Те же индусо-китайцы ведь пишут и документацию, по которой временами понять что-то трудно - а либа вот она под рукой и рабочая!

К сожалению, там править надо всё, а объём такой, что это становится малореальным. Проще это с нуля написать, тем более, что большая часть нафиг не нужна. Нужны внятные определения MMR и их битов, а остальное - гуано а-ля ST'шный HAL.

Если была цель помочь юзеру, так надо просто примеров внятных накидать, как и что делать с тем или иным периферийным модулем. И регистры описать нормально. А уж юзер сам по примерам и после изучения док напишет код. Либа там такая, что создаётся устойчивое впечатление, что цель была - написать как можно больше строк кода, наверное индусам платят за объём, а качество там оценивать некому.


Я бы не хотел пускаться в подробности, но мне двух месяцев ковыряния в этом и в доках альтеры на тему SoC хватило, чтобы начать искать альтернативу, и она нашлась - это цинк7000.

Поначалу показалось с Ваших слов, что ситуация с Альтерой как раз лучше...

Может все же расскажете подробнее, какие есть еще плюсы/минусы у этих конкурирующих SoC?
Неужели у хилых документация лучше?

Там я говорил про DS-5. Это среда от ARM и сделана она очень прилично. Заслуг Altera тут не просматривается. Жаль, что Xilinx не пошёл по этому пути, а начал пилить свой велосипед.

Что касается самих SoC'ов (СнК) и всего, что вокруг них. Сразу оговорюсь, что это моё (и моих коллег) частное мнение, обусловленное личным опытом и требованиями целевых задач: одно из главных - поднять СнК в режиме bare-metal.

Почему bare-metal, а не linux. Linux, конечно, тоже очень интересует, но это следующий шаг. Linux рассматриваем как мощное дополнение, открывающее "портал" в целый мир: файловые системы, сетевые стеки, GUI и т.п., и всё это по-взрослому.

Но на данном этапе речь идёт о замене существующей платформы - у нас есть отработанная связка Blackfin + CycloneIV и платы на их основе, но это уже морально устаревшее решение и не поддающееся расширению (тут и связь между процессором и ПЛИС ограничена по пропускной способности, и тот же Linux в перспективе не поставишь, да и развитие семейства Blackfin вендором ведётся в ином направлении, чем нужно нам: нам нужно просто эффективное ядро процессора, а фины чем дальше, тем больше становятся похожими на МК или даже небольшие СнК. К тому же, с некоторых пор у меня основная рабочая платформа - Linux, а Blackfin под Linux можно сказать, что не поддерживается. Портировать имеющиеся проекты удалось, но развития тут тоже нет.

Не нужно быть оракулом, чтобы понять, что общий тренд - СнК. Куда не глянь, везде они. В любом телефоне или планшете. Да и вообще, дело не в том, как это называется, а в сути, а она такова, что всякое развитие идёт по пути упрощения внешних интерфейсов за счёт сколько угодно большого усложнения внутренностей. И нынче и навороченные МК (Cortex-M4/7) уже похожи на СнК, а любая микросхема с Cortex-A на борту - это всегда СнК.

В нашем случае такая СнК - это связка Cortex-A + ПЛИС. Поскольку весь прежний опыт плисоводства был связан с Altera, то внимание было обращено на SoC CV. Поначалу казалось, что тут всё аналогично (по сравнению с тем, что у нас было), только процессор и ПЛИС в одном корпусе. Но при ближайшем рассмотрении всё оказалось совсем не так. И стало понятно, почему вендоры (та же Altera) предлагает путь: "Ставьте Linux и не мучайтесь".

Углубляться в трудности освоения тут не буду, для этого надо отдельную тему заводить. Просто краткое сравнение.

Что касается самих микросхем.

По навороченности тут приоритет за Altera. По продуманности и сбалансированности - за Xilinx.

В частности, SoC CV поддерживает до двух аппаратных SDRAM контроллеров - один на стороне HPS и один на стороне FPGA Fabric, у Zynq7000 только один - на стороне PS, в PL аппаратного нет даже в старших. Сам по себе SDRAM контроллер в Altera более продвинутый, он поддерживает (если не путаю) всё адресное пространство (4G), а в Zynq7000 - только 1G. Поначалу я относил это к важному недостатку СнК Xilinx, но поразмыслив и посчитав пропускную способность интерфейса к внешней памяти, понял, что его достаточно с хорошим запасом, а один SDRAM контроллер (и следовательно, один интерфейс к внешней SDRAM) - это лучше для экономии энергии и пространства на плате (для нас это важно, т.к. приборы нередко носимые с автономным питанием). И 1GB памяти тоже вполне изрядно для систем такого "калибра".

Ещё у SoC CV ACP выведен на уровень L3 Interconnct, что позволяет кэш-когерентный доступ в память со стороны мастеров периферии HPS и ПЛИС. У Zynq7000 ACP зацеплен на PL, т.е. такой доступ возможен только для мастеров из ПЛИС. Но насколько это критично, я пока не вижу. Зато это проще в реализации (не нужно этот канал через интерконнект тащить), и по всей видимости инженеры Xilinx посчитали, что потоки данных от внутренних периферийных устройств не нуждаются в обеспечении когерентности кэшей ядер. В общем, для нас это не недостаток.

Теперь о том, что для нас важно.

On-Chip Memory (OCM)

У Zynq7000 объём внутренней SRAM 256к, а у SoC CV - всего 64к. Это очень существенно. 64к для bare-metal проектов - это откровенно маловато (особенно, если учесть, что та же таблица трансляции MMU сожрёт 16к от этого объёма) и часть программы придётся размещать в SDRAM, а это заметно большая латентность доступа. Я даже продумывал вариант, чтобы как-то залить весь код и данные в L2 кэш на старте программы, чтобы избавиться от доступа наружу. А вот 256к - совсем другое дело, тут уже должно хватить с запасом.

Далее. У CV OCM сидит на L3 интерконнекте, а у Zynq7000 сразу на шине APU (блок с ядрами), т.е на L2 уровне. При этом хотя тактирование OCM половинное от частоты ядер, зато шина 128 бит, что при выровненном доступе даёт тот же поток, что и по шине ядра, которая 64 бита.

В общем, для bare-metal, когда хочется иметь весь код и данные внутри и минимальную латентость доступа, цинк сильно впереди.

Количество выводов СнК, доступные для пользователя.

Тут сравнение в пользу цинка. Например, CV в 484-выводном корпусе для пользователя доступны 66 FPGA GPIO и 151 HPS I/O. Это 217 ног, т.е. меньше половины от общего числа. У аналогичного цинка 200 PL (FPGA) и 128 PS, т.е. 328 ног, на 100 (!) ног больше. Сравнимое количество выводов имеет CV в 672-ногом корпусе (145 + 181 = 322), но этот корпус заметно больше - 23 мм сторона против 19 мм у 484-ногого.

Далее, обратите внимание, что баланс у CV сдвинут в сторону HPS, а у Zynq - в сторону ПЛИС. Если не хватает на той или иной стороне, то можно "занять" (loan в терминах альтеры) пинов у "соседа". Но если в случае ПЛИСовых пинов они являются полноценными - с регистрами в IO элементах, с DDR функционалом, то те, что на процовой стороне не факт, что такие. Проверять это на CV у меня руки не дошли, а на Zynq это делать и не надо.

В общем, тут Zynq выглядит более продуманным и сбалансированным.

Документация.

Тут приоритет Xilinx безоговорочный. У Altera в плане SoC документация безобразная. Имею в виду прежде всего основной документ cv5_v4.pdf. 3600 страниц мути. Нет, некоторые фрагменты написаны вполне внятно, в целом оставляет тяжёлое впечатление. Бестолково написано, безобразно, небрежно оформлено (уж это-то можно было хоть нормально сделать). Впечатление, что гнались за объёмом - чем больше налабали страниц, тем больше зарплаты получили. Аналогичный документ на Zynq7000 - 1800 страниц. Ровно в два раза меньше! При этом читается после альтеровского как художественная книжка... В общем, про доку на CV HPS могу много чего сказать, я на ней и сломался, точнее, когда пытался по ней разобраться с GPIO. В тот момент решил посмотреть, у всех ли так же бестолково и по-дурацки написано про это, скачал на Zynq7000 и... в общем, с этого момента начал зреть на переход на Xilinx, хотя для меня это тяжёлый переход - опыта с Xilinx почти нет, а тут новая САПР (Vivado), другой design-flow. Хотя сам SoC изучать в обоих случая с нуля. Сейчас я в процессе освоения. Но если хождение по альтере было сродни хождению по лабиринту, то на зайлинксе хотя тоже всё не просто (вот с теми же MMR проблема), но движение поступательное.

Про HWLib тут писать не буду, и так много букв уже написал. Это можно отдельную тему поднять.

Ну, и сам design-flow у Altera - я поднимал MPL - искусственно раздутый, "рыхлый" и мутный. Я сложил свой эксперимент на гитхаб и там законспектировал шаги - получилось 15 пунктов, из которых как минимум половина из-за кривизны подхода.

dxp
Спасибо за столь развёрнутый ответ, было очень познавательно

Сам я пока тоже дальше простого Bare Metal приложения из под MPL загрузчика не забирался, но, если воспринимать SoC систему как большой микроконтроллер с программируемой логикой - выглядит весьма увлекательно, пусть для меня это просто хобби и занятие для души

Zynq весьма популярная SoC, имеет кучу обучающих роликов на ютубе и море различных отладочных плат, вот и тянет порой "пощупать" железяку
Но что в них раздражает - закрытость Xilinx для России, заставляющая людей плодить темы "Помогите скачать" и т.п.

ЗЫ: HDMI видео выход, как я понял, вообще без проблем организовать на ксайлинксе, даже без микросхемы-драйвера, что практически невозможно на альтере.

А вы доку (ug585) скачайте и полистайте.


Ну, я бы не сказал, что это закрытость. У любого вендора есть закрытые места. Вот что лучше по альтере в РФ, так это дистриьюторы (ЭФО, Гамма), что заметно даже по нашему форуму. Ну, и киты на CV разнообразнее и дешевле - Терасику зачёт. Например, Zedboard стоит "там" $495. Есть более младший вариант Zybo - $189, но на этом и всё. Фирменные от Xilinx - от 800+ зелёных рублей. В то же время Arrow SoCKit мы брали за $350, а он более нашпигованный, чем та же zedboard.

В общем, "если гора не идёт к Магомеду..."...

На основе официального мануала ug585-Zynq-7000-TRM.pdf создан набор заголовочных файлов с описаниями memory-mapped registers (MMRs). Регистры и описания их битовых полей распределены по файлам на основе модулей. Zynq7000 содержит 31 тип модулей, соответственно создан 31 файл с описаниями регистров. Плюс к этому добавлены ещё два файла: один просто включает в себя для удобства все остальные (ps7mmrs.h), и один содержит адреса модулей (ps7modmap.h), он используется в других файлах.

Взять можно тут.

Подробности.

Набор файлов не один, а три - в разных стилях, на основе :

• констант (const int, const uintptr);
• перечислений (enum);
• макросов (#define), это традиционный стиль.

Тут уж кому что больше нравится.

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

Вообще, в pdf'нике описание сделано по единому формату - зачёт редактору документа, но вот описания модулей делались, очевидно, разными людьми, тут полный разнобой и по стилям, по объёму информации, и по именованию регистров/полей, и т.д. и т.п. Из-за этого пришлось поредактировать.

Итого:

• Все имена приведены к единому стилю - в верхнем регистре с символами подчёркивания в качестве разделителей.
• Имена регистров выполнены по формату <MODULE_NAME>_<REGISTER_NAME>_REG. Исключение составляют регистры контроллера прерываний - GIC, там именование достаточно традиционное, почти все имена заканчиваются на R, что означает "регистр", поэтому суффикса _REG к ним не добавлено.
• Если модуль имеет два или более экземпляров, то после суффикса _REG в имени регистра следует ещё суффикс экземпляра модуля - например, регистры управления UART'ов имеют вид UART_CTRL_REG0 и UART_CTRL_REG1.
• Для каждого битового поля введены два макроса в формате <BITFIELD_NAME>_MASK (маска) <BITFIELD_NAME>_BPOS (позиция битового поля).
• Исходные имена, которые были в CaMeL стиле приведены к виду CA_ME_L.
• Немало было мест, где имена регистров и особенно битовых полей были идентичными.
• У некоторых битовых полей имён вообще не было, пришлось добавить.
• Отдельные имена регистров были очень длинными - фактически состояли из строки, описывающей все поля регистра, - заменены более короткими.
• В именах регистров и их полей общеупотребительные CONTROL, STATUS, INTERRUPT заменены на более короткие CTRL, STS, INT соответственно.
• Ну, и ещё кое-что по мелочи.

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

В общем, пока "первый блин". Но компилятор не ругается, т.е. синтаксически всё нормально и конфликта имён тоже нету.

Надеюсь, ещё кому-нибудь будет полезно. Замечания приветствуются.

Статистика ( Per Mod - количество регистров в модуле, Total - всего регистров в модулях данного типа, Bit Fields - количество битовых полей в регистрах модуля, внизу сумма):