[dxp 33]

Всем привет!

 

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

[0xFFFF 0]

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

 

 

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

 

[dxp 33]

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

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

[0xFFFF 0]

а как выглядят "регистрами периферии" у альтеры Qsys ?

что-то типо того как в #include "xparameters.h" и #include "xparameters_hw.h" ?

 

[dxp 33]

а как выглядят "регистрами периферии" у альтеры Qsys ?

что-то типо того как в #include "xparameters.h" и #include "xparameters_hw.h" ?

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

 

....
language="en">This GPIO Data register is used to input or output data
Check the GPIO chapter in the handbook for details on how GPIO2 is implemented.</description>
                <bitField access="Read Write" high_bit="28" low_bit="0" name="gpio_swporta_dr">
                    <gui_name language="en">gpio_swporta_dr</gui
...

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

 

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

 

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

[doom13 0]

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

[dxp 33]

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

 

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

 

/********************************************************************************
*** */
/* System MMR Register Map */
/********************************************************************************
*** */
/*// Clock/Regulator Control (0xFFC00000 - 0xFFC000FF) */

#define PLL_CTL><--><-->0xFFC00000  /* PLL Control register (16-bit) */
#define PLL_DIV><--><-->0xFFC00004<>/* PLL Divide Register (16-bit) */
#define VR_CTL<><--><-->0xFFC00008<>/* Voltage Regulator Control Register (16-bit) */
#define PLL_STAT<--><-->0xFFC0000C  /* PLL Status register (16-bit) */
#define PLL_LOCKCNT><-->0xFFC00010  /* PLL Lock Count register (16-bit) */
#define>CHIPID<><--><-->0xFFC00014<>/* Chip ID Register><--><--><--><--><-->*/


/* System Interrupt Controller (0xFFC00100 - 0xFFC001FF) */
#define SWRST<-><--><-->0xFFC00100  /* Software Reset Register (16-bit) */
#define SYSCR<-><--><-->0xFFC00104  /* System Configuration registe */
#define SIC_IMASK<-><-->0xFFC0010C  /* Interrupt Mask Register */
#define SIC_IAR0<--><-->0xFFC00110  /* Interrupt Assignment Register 0 */
#define SIC_IAR1<--><-->0xFFC00114  /* Interrupt Assignment Register 1 */
#define SIC_IAR2<--><-->0xFFC00118  /* Interrupt Assignment Register 2 */
#define SIC_ISR><--><-->0xFFC00120  /* Interrupt Status Register */
#define SIC_IWR><--><-->0xFFC00124  /* Interrupt Wakeup Register */


/*// Watchdog Timer (0xFFC00200 - 0xFFC002FF) */
#define WDOG_CTL        0xFFC00200  /* Watchdog Control Register */
#define WDOG_CNT        0xFFC00204  /* Watchdog Count Register */
#define WDOG_STAT       0xFFC00208  /* Watchdog Status Register */

<...>

и т.д.

 

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

 

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

[sonycman 0]

dxp

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

DS-5 от ARM, насколько я понимаю - не используется?

[dxp 33]

dxp

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

DS-5 от ARM, насколько я понимаю - не используется?

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

 

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

[sonycman 0]

dxp

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

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

Странно, что у гораздо раньше появившегося цинка нет аналога...

[dxp 33]

dxp

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

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

Странно, что у гораздо раньше появившегося цинка нет аналога...

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

[sonycman 0]

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

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

 

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

[dxp 33]

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

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

 

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

 

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

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

[sonycman 0]

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

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

 

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

Неужели у хилых документация лучше? :05:

[dxp 33]

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

 

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