dxp 65 19 февраля, 2017 Опубликовано 19 февраля, 2017 · Жалоба Всем привет! Простой вопрос: как в Xilinx SDK получить вид с регистрами периферии? Пока что могу видеть только регистры процессора и его окружения (SCU, кэши, сопроцессоры). Пробовал задать Hardware Platform (втянуть *.hdf файл), но ничего не появилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
0xFFFF 0 19 февраля, 2017 Опубликовано 19 февраля, 2017 · Жалоба вы это имеете ввиду? когда делаете в vivado export-hardware то в SDC появится папка автоматически с файлами вместе с *.hdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 19 февраля, 2017 Опубликовано 19 февраля, 2017 · Жалоба когда делаете в 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 19 февраля, 2017 Опубликовано 19 февраля, 2017 · Жалоба а как выглядят "регистрами периферии" у альтеры Qsys ? что-то типо того как в #include "xparameters.h" и #include "xparameters_hw.h" ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 20 февраля, 2017 Опубликовано 20 февраля, 2017 · Жалоба а как выглядят "регистрами периферии" у альтеры 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 20 февраля, 2017 Опубликовано 20 февраля, 2017 · Жалоба Похоже, в Xilinx SDK это невозможно:( , всегда пользуюсь окном Memory Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 13 апреля, 2017 Опубликовано 13 апреля, 2017 · Жалоба Чтобы не создавать новую тему, тут спрошу. Речь опять о периферийных 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 1 13 апреля, 2017 Опубликовано 13 апреля, 2017 · Жалоба dxp Прошу прощения, что не по теме, интересуюсь просто - какой компилятор использует Xilinx для процессорных ядер в Zynq? DS-5 от ARM, насколько я понимаю - не используется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба dxp Прошу прощения, что не по теме, интересуюсь просто - какой компилятор использует Xilinx для процессорных ядер в Zynq? DS-5 от ARM, насколько я понимаю - не используется? Сами-то ядра те же самые - Cortex-A9, поэтому компляторы там одни и те же. Это либо ARM, либо GCC (arm-none-eabi). Для сборки оболочку (IDE) не использую, поэтому мне без разницы - DS-5 это, XSDK или что угодно другое. Оболочка мне нужна только как отладчик. DS-5 в этом контексте сделана очень хорошо, в том числе есть поддержка всех периферийных регистров - удобно наблюдать за их содержимым и/или вносить в них изменения. Ещё консоль команд по функциональности почти как у GDB, мощные возможности по скриптингу. XSDK, к сожалению, по всем перечисленным фичам сливает по полной. :( Заголовочных файлов с описаниями периферии в составе тулчейнов нет - ведь они же (тулчейны) общие для многих платформ, но конкретный вендор обычно дополняет их описанием под свои микросхемы. У Альтеры это есть в составе HWLib (не к ночи будь помянута), но описание сделано безобразно. А вот у Зайлинкса нет даже этого - есть только какие-то фрагменты (или я не там искал). Всё это неструктурировано, несистематизировано, размазано по примерам, в общем, какое-то частное решение, имхо, малопригодно для комфортного использования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 1 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба dxp Понятно, спасибо. Альтеровская HWlib, кстати, неплохо помогает освоиться с армом, считаю её большим подспорьем. Странно, что у гораздо раньше появившегося цинка нет аналога... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба dxp Понятно, спасибо. Альтеровская HWlib, кстати, неплохо помогает освоиться с армом, считаю её большим подспорьем. Странно, что у гораздо раньше появившегося цинка нет аналога... Не могу согласиться. Качество кода негодное, пользоваться очень неудобно, моё имхо. У Xilinx есть аналог - embeddedsw (на их странице на гитхабе есть репозиторий), там весьма много материала "для подспорья", качество кода тоже так себе (везде индусы), но выше, чем у альтеры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 1 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба Не могу согласиться. Качество кода негодное, пользоваться очень неудобно, моё имхо. У Xilinx есть аналог - embeddedsw (на их странице на гитхабе есть репозиторий), там весьма много материала "для подспорья", качество кода тоже так себе (везде индусы), но выше, чем у альтеры. То, что не нравится - всегда можно подправить под себя, гораздо хуже, когда и править-то нечего, так как нету ничего :( Те же индусо-китайцы ведь пишут и документацию, по которой временами понять что-то трудно - а либа вот она под рукой и рабочая! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба То, что не нравится - всегда можно подправить под себя, гораздо хуже, когда и править-то нечего, так как нету ничего :( К сожалению, там править надо всё, а объём такой, что это становится малореальным. Проще это с нуля написать, тем более, что большая часть нафиг не нужна. Нужны внятные определения MMR и их битов, а остальное - гуано а-ля ST'шный HAL. Если была цель помочь юзеру, так надо просто примеров внятных накидать, как и что делать с тем или иным периферийным модулем. И регистры описать нормально. А уж юзер сам по примерам и после изучения док напишет код. Либа там такая, что создаётся устойчивое впечатление, что цель была - написать как можно больше строк кода, наверное индусам платят за объём, а качество там оценивать некому. Те же индусо-китайцы ведь пишут и документацию, по которой временами понять что-то трудно - а либа вот она под рукой и рабочая! Я бы не хотел пускаться в подробности, но мне двух месяцев ковыряния в этом и в доках альтеры на тему SoC хватило, чтобы начать искать альтернативу, и она нашлась - это цинк7000. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 1 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба Я бы не хотел пускаться в подробности, но мне двух месяцев ковыряния в этом и в доках альтеры на тему SoC хватило, чтобы начать искать альтернативу, и она нашлась - это цинк7000. Поначалу показалось с Ваших слов, что ситуация с Альтерой как раз лучше... Может все же расскажете подробнее, какие есть еще плюсы/минусы у этих конкурирующих SoC? Неужели у хилых документация лучше? :05: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 14 апреля, 2017 Опубликовано 14 апреля, 2017 · Жалоба Поначалу показалось с Ваших слов, что ситуация с Альтерой ,как раз лучше... Может все же расскажете подробнее, какие есть еще плюсы/минусы у этих конкурирующих 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 пунктов, из которых как минимум половина из-за кривизны подхода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться