Xilinx SDK, Peripheral Register View Опции

[dxp]

Всем привет!

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

[sonycman]

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

[dxp]

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

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

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

[sonycman]

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

[dxp]

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

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

[sonycman]

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

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

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

[dxp]

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

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

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

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

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

[sonycman]

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

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

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

[dxp]

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

Может все же расскажете подробнее, какие есть еще плюсы/минусы у этих конкурирующих 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 пунктов, из которых как минимум половина из-за кривизны подхода.