[mantech 132]

Только что, makc сказал:

Цинках процессор грузит ПЛИС, а не наоборот

Вообще не представляю, как может быть наоборот в случае аппаратного проца?)))))))

[makc 381]

Только что, mantech сказал:

Вообще не представляю, как может быть наоборот в случае аппаратного проца?)))))))

Да очень просто. Сначала конфигурируется ПЛИС, формирует обвязку проца, а только потом отпускается ресет проца и всё запускается.

[mantech 132]

2 минуты назад, makc сказал:

Сначала конфигурируется ПЛИС, формирует обвязку проца, а только потом отпускается ресет проца и всё запускается.

Предположу, что это сделать значительно сложнее, чем просто запустить программу на проце... Либо если проц не имеет встроенного загрузчика.

Edited September 15, 2025 by mantech

[makc 381]

7 минут назад, mantech сказал:

Предположу, что это сделать значительно сложнее, чем просто запустить программу на проце... Либо если проц не имеет встроенного загрузчика.

Предложения могут быть любыми, но они должны подтверждаться какими-то фактами, чтобы быть принятыми во внимание. А так - увы и ах, но нет. К тому же у Цинка есть неприятная особенность: его BootROM недоступен для чтения штатными средствами, что не даёт понять можно ли ему доверять и нет ли в нём каких-то дыр (спойлер - есть).

[mantech 132]

12 минут назад, makc сказал:

его BootROM недоступен для чтения штатными средствами

В смысле, это как? Он самоблокируется после передачи управления загруженной проге и через жтаг недоступен? Однако..

[makc 381]

1 час назад, mantech сказал:

В смысле, это как? Он самоблокируется после передачи управления загруженной проге и через жтаг недоступен? Однако..

Именно так и есть.

С JTAG там отдельная история, т.к. по-умолчанию он ЕМНИП отключен, а BootROM его включает только после отдачи управления FSBL.

[dxp 198]

11 часов назад, Arlleex сказал:

Разве в цинках не кинтекс всегда был?

От ёмкости зависит. До 20-го Artix, далее Kintex.

11 часов назад, Arlleex сказал:

Все-таки, не на порядок, а в 2-3 раза жирнее самых начальных внутри линейки цинков.

 

Мы про ПЛИС говорим, Artix -- не младшее семейство, младшее Spartan. В цинках, да, 20-й по ёмкости PL где-то раза в три толще 10-го.

10 часов назад, jcxz сказал:

В моей pdf-ке для >XA7Z020 указана Kintex, для <=XA7Z020 - Artix.

По вашей ссылке:

До 30-ки Artix, с 30-ки -- Kintex.

XC и XA отличаются исполнением, XA -- automotive, вроде. Хотя в нём, оказывается аж два АЦП, в XC всегда один был (тож не особо нужный).

 

[dxp 198]

10 часов назад, Arlleex сказал:

Инструментарий оставляет желать лучшего - тормозная среда, основанная на эклипсе (под процовую часть) и претерпевшая уже несколько поколений изменений. Крайне дебильная схема экспорта описаний ПЛИС-овых ядер (адресов) в SDK для проца. Крайне недружелюбная, на грани "хз как так получилось,

Имхо, почти любые среды оставляют желать лучшего. Лучше "завязываться" на них по минимуму -- у меня обычно среда используется только как front-end к отладчику. Т.е. сборку как обычно делаем сами (make или кто что любит, у меня scons). В итоге всё собирается по одной команде из консоли (или из редактора), а если надо, то и загружает микросхему (и PS, и PL), и программирует загрузочную флешь. И никаких страданий с SDK/Vitis.

10 часов назад, Arlleex сказал:

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

Фтопку эти проекты. Флоу от вендора там уродское, если серьёзно работать, лучше сразу про это забыть и сделать как следует самому -- сэкономит в дальнейшем тонны времени и нервов. Главное -- это позволит сосредоточиться на функциональности проекта и не отвлекаться на раздражающие кривые моменты (а их, имхо, в любой среде хватает). Как ни странно, но ключевым софтом в этом процессе является вовсе не Vitis, а Vivado -- именно она генерит код инициализации аппаратуры SoC и описывает стыковочные моменты. Да, это делается у них посредством блочных дизайнов (BD), что поначалу может конфузить из-за некой непривычности и тяжеловесности, но особых проблем тут нет.

Vivado несмотря на известную тормознутость (жаба-GUI) сама по себе архитектурно сделана очень стройно: в её основе лежит движок с богатым Tcl API, с помощью которого можно сделать всё, и тот же GUI тоже выполняет действия через этот движок, о чём радостно сообщает, показывая Tcl команды в консоли -- это классное средство быстро понять, какие команды можно использовать для тех или иных действий. Всё это позволяет достаточно легко автоматизировать практически все операции, в том числе и экспорт настроек -- xsa файла, который по сути является zip-архивом, в котором лежат ps7_init.* файлики, необходимые для инициализации периферии. 

Лазить по гуям и тыкать галочки тоже каждый раз не нужно: один раз вначале создали BD с ps7 компонентом (это процессорная часть), зашли в компонент, натыкали, что надо, вышли в BD, далее делаем экспорт BD в Tcl. Оно рожает скрипт, в котором много лишнего (скрипт легко читается), самое нужное нам находится в конце (собственно настройки ps7) -- это выдираем к себе в отдельный файлик, который потом при сборке запускается и позволяет сгенерить xsa. xsa распаковываем (это ж zip) и забираем к себе на сборку софтовой части ps7_init.h, ps7_init.c. Конечно, всё это делает автоматически система сборки, один раз настроено, далее всё собирается автоматически.

Если надо что-то подправить, то совсем не нужно заново все это городить -- что-то понятно прямо из текста скрипта (чиселку какую-нить подправить), но если не хочется вникать и есть сомнения, то можно зайти в BD и ткнуть нужную галку, поправить значение, -- эти действия отобразятся в Tcl консоли Vivado в виде команд. Эти команды скопировать и вставить в свой Tcl скрипт, который ранее сгенерили. Ничего сложного тут нет, и делать это приходится нечасто (только при изменении конфигурации -- у меня в основном, когда портиуешь проект на другую плату -- проект может собираться под сколько угодно целевых плат).

10 часов назад, Arlleex сказал:

Идеологию "все напишу сам" лучше сразу забыть, т.к. среда диктует свое, единственно правильное, видение "правильной разработки".

Тем не менее, мы именно так и делаем -- флоу полностью свой. Я даже компилятор использую не из состава Vitis, а собственноручно скачанный gcc нужной версии. Единственное, что навязывет среда -- это вышеописанный процесс с BD. Но и с ним всё ровно, я уже забыл, когда туда лазил.

FSBL их -- это "ужос, летящий на крыльях ночи", начиная от стиля именования переменных и функций и заканчивая построением и злоупотреблением макросами. Такое впечатление, что специально писали так, чтобы было труднее разобраться -- какие-то простые вещи оборачиваюся в макросы, которые не упрощают восприятие, а наоборот усложняют -- обфускация какая-то.

Из кода FSBL я выдрал только начальную инициализацию (boot.S, с мелкими правками), но там "слова из песни не выкинешь", и это код процентов на 90+ от ARM, Xilinx там что-то по-мелочи добавил. Далее весь загрузчик полностью свой. И он делает то, чего FSBL не может, а мне надо (хотелось): он собирает все сегменты OCM в виде единого куска 256к в старших адресах (0xfffc0000, при старте BootROM конфигурирвет три сегмента по 64к в младших адресах и один в старших), и грузит туда целевую программу. Учитывая, что сам  код загрузчика кладётся на старте BootROM в OCM (в младшие адреса), то тут приходится поприседать (нельзя ведь просто переместить сегменты в другие адреса, когда в них живёт код и объекты текущей программы, ещё есть нюансы с кэшами, MMU). Но в итоге целевая программа загружена в единый кусок ОСМ, при этом уже всё проинициализировано и PL загружена, т.е. ценная внутренняя память не расходуется на служебные задачи (а там то же ps7_init весит весьма ощутимо).

Т.е. сделано так, как надо мне, а не так, как "диктует" среда. Да, это потребовало усилий, т.е. за это "заплачена цена". Но это делается один раз, и жить после этого энкратно комфортнее. И вся OCM полностью в распоряжении целевой программы, без потерь.

10 часов назад, Arlleex сказал:

Да, исходники можно писать и самому, но подружить это с некоторыми идеями, навязываемыми самим САПР-ом, без лютых костыляний просто невозможно. Особенно, когда будете сопрягать PL-ную часть с PS-ной (экспортировать зависимости и адреса).

Не понял, с каким костылями тут приходится сталкиваться. PL отображается в PS на адреса (по умолчанию, вроде, начиная 0x40000000, размер задаётся), в программе PS заводим секции, которые прибиваются на адреса в этом диапазоне, любое обращение в этот диапазон порождает AXI3 транзакцию на AXI мост PS-PL. В PL логика должна реагировать на эту транзакцию, корректно её обрабатывать и возвращать ответ. Даже поведенческая модель есть для HDL симулятора. Мы с помощью этого управляем своей кастомной периферией в PL: все нужные модули имеют регистры управления, которые отмаплены на адреса в PS (на те самые секции, в которые помещены структуры с регистрами). Использование самое обычное -- как со штатной периферией (MMR): пишем/читаем регистр в программе, в  PL летит транзакция, которая меняет или читает состояние регистра периферийного модуля в PL. По сути это просто расширение штатной периферии с помощью нештатной -- кастомной, расположенной в PL. А обращение к ней технически почти такое же.

Конечно, следует признать, что всё это хозяйство далеко не такое простое, как в среднестатистическом МК, и для эффективной работы нужна автоматизация (система сборки, но она есть, и это решает). Порог вхождения получается изрядно выше, но это не странно -- SoC обычно сложнее МК, и возня на низком уровне с ней потребует больше времени и усилий.

10 часов назад, Arlleex сказал:

При сборке ПЛИС-ового проекта средней сложности можете сразу идти в курилку на полдня.

Ну, это преувеличение. Время сборки сильно зависит от требований по таймингам и забитости логики, но средний проект в 20-м цинке собирается единицы-десятки минут. У меня щас там порядка 10% логики занято, тайминги расслабленные, сборка занимает 5 минут на домашнем компе и 3 минуты на рабочем. Это всё полностью с генерированием проекта Vivado, синтеза блочного дизайна, сборки программ (загрузчика и целевой), синтеза и PnR с финальной генерацией образов для прошивки в загрузочную ПЗУ. 

Полдня -- это уже скорее жирные Kintex или Vritex.

[dxp 198]

8 часов назад, makc сказал:

Учитывая, что в Цинках процессор грузит ПЛИС, а не наоборот, то это скорее процессор с добавкой ПЛИС. 😉

Сомнительный критерий. 🙂 Загрузочная функция вряд ли может выявить тут главного. В однокласснике Cyclone V SoC, например, ПЛИС умеет грузиться самостоятельно. И в обычных ПЛИС есть внутри аппаратный загрузчик (который Active Serial, например, осуществляет), мы же не считаем его главным. 

В SoC всё же главный упор на целевые функции, а их выполняет, как правило, не процессор, а специализированная аппаратура. Процессор там -- это типа "смотрящий", его задача всё настроить, запустить, следить "за порядком" и осуществлять интерфейс с пользователем. Я бы главного тут вообще не выделял -- вся сила именно в гибком и грамотном распределение задач, поэтому все части жизненно необходимы.

[makc 381]

46 минут назад, dxp сказал:

Сомнительный критерий. 🙂 Загрузочная функция вряд ли может выявить тут главного.

Что именно сомнительно? Вы посмотрите на то, как устроен Цинк, и поймёте, что ПЛИС там чисто для оффлоада частных задач, а главным элементом является именно процессор. Он же грузит прошивку ПЛИС и реализует функции безопасности (проверку целостности и аутентичности прошивки ПЛИС). Без него ПЛИС - это мёртвое железо, которое вы не сможете никак иначе запустить. И после всего этого вы по-прежнему считаете, что процессор в этой системе не главный? 🤔

50 минут назад, dxp сказал:

В однокласснике Cyclone V SoC, например, ПЛИС умеет грузиться самостоятельно.

Хорошо, если так. Я ими не пользовался.

51 минуту назад, dxp сказал:

И в обычных ПЛИС есть внутри аппаратный загрузчик (который Active Serial, например, осуществляет), мы же не считаем его главным. 

Блок конфигурирования не реализует никаких высокоуровневых функций в этой системе и поэтому никак не может сравниваться с процессором. Итого: сравнение некорректно, аргумент не засчитан. 😉

52 минуты назад, dxp сказал:

В SoC всё же главный упор на целевые функции, а их выполняет, как правило, не процессор, а специализированная аппаратура.

Сомнительно. (С) Т.к. зависит от решаемых задач. В среднем это наверное 50/50. 🤔

[dxp 198]

12 минут назад, makc сказал:

Вы посмотрите на то, как устроен Цинк, и поймёте, что ПЛИС там чисто для оффлоада частных задач

Не частных, а основных, потому что всё остальное на PS части (включая и древние Cortex-A9) там более чем ординарное и мало кого может заинтересовать сегодня. Именно наличие хорошей ПЛИС -- главная фишка цинка! Без неё это старая, неинтересная микросхема.

 

12 минут назад, makc сказал:

Он же грузит прошивку ПЛИС и реализует функции безопасности (проверку целостности и аутентичности прошивки ПЛИС)

Ага, только без включенной ПЛИС (запитанной и подключенной через левел шифтеры) он никакую секурность сделать не может -- блок крипты и HMAС живёт в ПЛИС. Да и процесс загрузки там выполняет блок PCAP, который тоже в ПЛИС, а процессор только запускает DMA этого блока, технически процесс загрузки выполняет аппаратура ПЛИС.

12 минут назад, makc сказал:

Блок конфигурирования не реализует никаких высокоуровневых функций в этой системе и поэтому никак не может сравниваться с процессором. Итого: сравнение некорректно, аргумент не засчитан. 😉

Как же -- а декрипту и секурную загрузку кто делает? Вполне себе высокоуровневая функция. В Zynq MPSoC вообще процессом загрузки занимается не штатные ядра A53/R5, а аж три захардованных Microblaze (один начально грузит, другой за секурность отвечает, третий ещё там что-то делает), там процесс загрузки вообще нетривиальный. Может они тогда главные в системе,а не 4 ядра Cortex-A53?

 

[makc 381]

15 минут назад, dxp сказал:

Не частных, а основных, потому что всё остальное на PS (включая и древние Cortex-A9) части там более, чем ординарное и мало кого может заинтересовать сегодня.

Всё зависит от проекта, для кого-то ПЛИС это вычислитель, а для кого-то glue logic и коммутатор потоков данных в системе. Задачи бывают разные. 

15 минут назад, dxp сказал:

Именно наличие хорошей ПЛИС -- главная фишка цинка! Без неё это старая, неинтересная микросхема.

Я с этим и не спорю, но способы использования ПЛИС могут быть сильно разными.

15 минут назад, dxp сказал:

Ага, только без включенной ПЛИС (запитанной и подключенной через левел шифтеры) он никакую секурность сделать не может -- блок крипты и HMAС живёт в ПЛИС.

Не понял, это как? После подачи питания ПЛИС не сконфигурирована, а крипта (например, RSA) и HMAC живут в ПЛИС и ядро A9 их использует чтобы сконфигурировать ПЛИС? Вам не кажется, что получается pkunzip.zip? 

15 минут назад, dxp сказал:

Да и процесс загрузки там выполняет блок PCAP, который тоже в ПЛИС, а процессор только запускает DMA этого блока, технически процесс загрузки выполняет аппаратура ПЛИС.

Давайте всё же различать хард и софт блоки в ПЛИС. PCAP это такой же хард-блок конфигурационной логики, как и в остальных ПЛИС Xilinx, только работающий исключительно в режиме ведомого по эд управлением A9. И да, левел шифтеры, ЕМНИП, включаются только после успешного конфигурирования ПЛИС, когда пины ПЛИС настроены и получили управление, а не наоборот. 

15 минут назад, dxp сказал:

Как же -- а декрипту и секурную загрузку кто делает? Вполне себе высокоуровневая функция.

Нет, это лишь часть общего процесса конфигурирования и, главное, ничего другого он делать не умеет. Это блок одной единственной функции, а вы почему-то пытаетесь показать что его подфункция это отдельная высокоуровневая системная функция. 🤦‍♂️ 

Ок, попробуйте её задействовать для чего-то ещё, кроме конфигурирования ПЛИС и расскажите, как вам это удалось. Ядро же А9 после работы FSBL ещё много чего делает, например позволяет гонять Линукс.

15 минут назад, dxp сказал:

Может они тогда главные в системе,а не 4 ядра Cortex-A53?

Я пока ничего не говорил про MPSoC и здесь мы обсуждали не его. Поэтому пример не совсем релевантен.

 

[dxp 198]

1 час назад, makc сказал:

Всё зависит от проекта, для кого-то ПЛИС это вычислитель, а для кого-то glue logic и коммутатор потоков данных в системе. Задачи бывают разные. 

Artix-7 для glue logic? Ну, технически можно, но это то же самое, что на танке ездить за пивом. Надуманная задача. ПЛИС там всё же для серьёзных задач, бо она могёт. Поэтому она главная часть, без неё там всё теряет смысл.

1 час назад, makc сказал:

Не понял, это как? После подачи питания ПЛИС не сконфигурирована, а крипта (например, RSA) и HMAC живут в ПЛИС и ядро A9 их использует чтобы сконфигурировать ПЛИС? Вам не кажется, что получается pkunzip.zip? 

Не знаю про pknuzip, но делается именно так: если секурный бут, то ПЛИС должна быть обязательно запитана, проц должен ждать, пока она будет готова (там есть специальный тайминг для этого), после этого проц настраивает PCAP (маршрут данных) и гонит (опять же с помощью DMA блока PCAP, расположенного в ПЛИС) через него шифрованный поток в ПЛИС, где блоки AES и HMAC декриптуют поток и возвращают его обратно. Проц тут только настраивает источник (QSPI, NOR, SD) и PCAP. Все эти операции делает BootROM, т.е. даже не пользовательская программа. И сами по себе операции простые и незатратные (настроить адреса источника, приёмника, пнуть DMA), с ними легко справится даже мелкий МК (поэтому Zynq MPSoC и не стали к этому процовые ядра привлекать). Все основные и сложные операции выполняет аппаратура ПЛИС.

1 час назад, makc сказал:

Давайте всё же различать хард и софт блоки в ПЛИС. PCAP это такой же хард-блок конфигурационной логики, как и в остальных ПЛИС Xilinx, только работающий исключительно в режиме ведомого по эд управлением A9.

Давайте. Вся ПЛИС -- это набор хардовых блоков. Но это не причина понижать её важность, а в случае цинка так как раз наоборот.

Я, кажется, понял суть наших разногласий. Для меня более главная часть та, которая делает основную работу. А для вас та, которая руководит. Наверное, потому, что я только инженер, а вам, насколько понимаю, приходится и руководство осуществлять, в вас начальник говорит. 🙂 

1 час назад, makc сказал:

И да, левел шифтеры, ЕМНИП, включаются только после успешного конфигурирования ПЛИС, когда пины ПЛИС настроены и получили управление, а не наоборот. 

Нет! Левел шифтеры обязательно нужно включить до любых обращений в ПЛИС -- в тот же PCAP, иначе туда просто не получится достучаться, ведь PCAP живёт на стороне ПЛИС. Я тоже наступил на эти грабли, благо, тут причина неработоспособности очень быстро выясняется. А пины ПЛИС тут вообще ни при чём: она же не сама в себя заливает битстрим из ПЗУшки, она это делает через аппаратуру PS -- например, контроллер QSPI, который живёт на PS части, и интерфейс которого прибит на конкретные ноги конкретного банка PS (500).

 

1 час назад, makc сказал:

Нет, это лишь часть общего процесса конфигурирования и, главное, ничего другого он делать не умеет. Это блок одной единственной функции, а вы почему-то пытаетесь показать что его подфункция это отдельная высокоуровневая системная функция. 🤦‍♂️ 

Дак ты вы объявили это высокоуровневыми операциями (секурный бут), я следую за вами. 🙂 

1 час назад, makc сказал:

Ок, попробуйте её задействовать для чего-то ещё, кроме конфигурирования ПЛИС и расскажите, как вам это удалось. Ядро же А9 после работы FSBL ещё много чего делает, например позволяет гонять Линукс.

Да, может. Как и тыщах других SoC, в которых всё это делается и покруче (ядра новее, быстрее). APU в Zynq-7000 -- это вполне заурядная штука, если её ядра заменить на какой-нить другой проц, было бы тоже норм. Вот, кстати, я был бы очень рад, если бы вместо Cortex-A9 там был бы какой-нить Cortex-M c более простой широй типа AHB, чтобы латетность доступа в ПЛИС была поменьше (AXI, конечно, крута, и пропускная там ништяк, но латентность так себе в случае с Cortex-A), а вместо жручего DDR3 контроллера был бы простой SDR с поддержкой LPSDR (накрайняк LPDDR). Мне бы пропускной хватило, а линукс мне не нужен, мне нужно однокристальное решение для построения гетерогенной системы. Ранее я использовал раздельные  компоненты (ПЛИС и процессор), однокристальное хоть и сложнее, но рулит, вот только жручесть мне не в тему, я пока не придумал, как придушить потребление контроллера памяти (щас он даже без обращения в DRAM жрёт больше ватта, судя по отчёту Vivado. Ну, и греется чип прилично. Сами ядра проца и ПЛИСовая логика там потребляют меньше 200 мВт на текущий момент).

А вот если убрать ПЛИС, это в корне меняет всё -- в этом SoC просто сразу теряется весь смысл.

1 час назад, makc сказал:

Я пока ничего не говорил про MPSoC и здесь мы обсуждали не его. Поэтому пример не совсем релевантен.

Ну, суть-то от этого не меняется: мы выясняем, кто главнее в SoC с FPGA: процессор или ПЛИС. И я лишь оспариваю тезис, что критерий "кто кого загружает" и определяет главного, не отражает суть. Пример Cyclone V SoC -- там ПЛИС вообще сама может грузиться, Zynq MPSoC -- там специальные мелкие процы это делают. А это всё SoC с FPGA. В Zynq-7000 возложили функцию загрузки ПЛИС на штатное ядро процессора, но это как раз частность, а не общее правило. Поэтому не может служить критерием главности.

[makc 381]

2 часа назад, dxp сказал:

Artix-7 для glue logic? Ну, технически можно, но это то же самое, что на танке ездить за пивом.

Мне кажется вы судите излишне категорично,  т.к. в линейке очень много разных кристаллов, включая одноядерные A9:

Есть 7е, 12е и т.п., которые как раз очень хорошо идут в задачи, где нужно много всякого разного сопрячь и связать. А старшие кристаллы, которые на Kintex, логично целятся в другую нишу задач. Но вы почему-то смотрите на это как-то крайне узко.

2 часа назад, dxp сказал:

ПЛИС там всё же для серьёзных задач, бо она могёт. Поэтому она главная часть, без неё там всё теряет смысл.

Ну вот, начали меряться серьёзностью задач... 🤦‍♂️ Можно подумать, что здесь мы шутки шутим. 😉

2 часа назад, dxp сказал:

Не знаю про pknuzip, но делается именно так: если секурный бут, то ПЛИС должна быть обязательно запитана, проц должен ждать, пока она будет готова (там есть специальный тайминг для этого), после этого проц настраивает PCAP (маршрут данных) и гонит (опять же с помощью DMA блока PCAP, расположенного в ПЛИС) через него шифрованный поток в ПЛИС, где блоки AES и HMAC декриптуют поток и возвращают его обратно. Проц тут только настраивает источник (QSPI, NOR, SD) и PCAP. Все эти операции делает BootROM, т.е. даже не пользовательская программа. И сами по себе операции простые и незатратные (настроить адреса источника, приёмника, пнуть DMA), с ними легко справится даже мелкий МК (поэтому Zynq MPSoC и не стали к этому процовые ядра привлекать). Все основные и сложные операции выполняет аппаратура ПЛИС.

Похоже мы с вами говорим про разное. Я говорил про загрузку PL, а вы мне описываете загрузку PS:

А под картинкой такой текст:

Цитата

A device secure boot involves several systems contained within the SoC device. The secure boot
process is always initiated by the BootROM. If RSA authentication has been enabled the BootROM will
use the public key to authenticate the first stage boot loader (FSBL) before it is decrypted or executed.
If the boot image header indicates a secure boot, the BootROM enables the AES and HMAC engines
which reside in the PL. The encrypted FSBL is then sent by the BootROM to the AES and HMAC, a
hardened core within the PL, via the processor configuration access port (PCAP). The FSBL image is
decrypted and sent back to the PS via the PCAP where it is loaded into the on-chip RAM (OCM) for
execution. The PS is then able to securely configure the PL by sending an encrypted bitstream
through the PCAP to the AES/HMAC for decryption, authentication, and distribution to the PL
memory cells.

Обратите внимание на выделенное. Это делает не BootROM, а программа в PS (FSBL), которая гонит битстрим напрямую в PL через опциональное расшифрование.

В общем мы оба правы, только каждый по-своему. 🙂

2 часа назад, dxp сказал:

Давайте. Вся ПЛИС -- это набор хардовых блоков. Но это не причина понижать её важность, а в случае цинка так как раз наоборот.

Нет, не так. ПЛИС это набор блоков общего назначения и выделенных Hard-IP и служебных блоков (таких же Hard-IP, только более обязательных). Конфигурационные блоки типа PCAP они есть везде в том или ином виде, но в данном случае работают под управлением PS чтобы прогрузка PL могла состояться. PS всем рулит, не PL. Кто рулит - тот и главный. 😉 
В конце концов PS может вообще не грузить PL (перекрыть кислород) и поэтому его роль первостепенна.

2 часа назад, dxp сказал:

Я, кажется, понял суть наших разногласий. Для меня более главная часть та, которая делает основную работу. А для вас та, которая руководит. Наверное, потому, что я только инженер, а вам, насколько понимаю, приходится и руководство осуществлять, в вас начальник говорит. 🙂 

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

2 часа назад, dxp сказал:

Нет! Левел шифтеры обязательно нужно включить до любых обращений в ПЛИС -- в тот же PCAP, иначе туда просто не получится достучаться, ведь PCAP живёт на стороне ПЛИС. Я тоже наступил на эти грабли, благо, тут причина неработоспособности очень быстро выясняется. А пины ПЛИС тут вообще ни при чём: она же не сама в себя заливает битстрим из ПЗУшки, она это делает через аппаратуру PS -- например, контроллер QSPI, который живёт на PS части, и интерфейс которого прибит на конкретные ноги конкретного банка PS (500).

А вот давайте посмотрим на описание последовательности включения из TRM:

Цитата

Example: Power-up Sequence

1. Power-up the PL. Refer to the data sheet for voltage sequencing requirements. The slcr.LVL_SHFTR_EN register should be equal to 0x0.
2. Enable the PS-to-PL level shifters. Write 0x0A to the slcr.LVL_SHFTR_EN register.
3. Program the PL.
4. Wait for the PL to be programmed. Read devcfg.INT_STS [PCFG_DONE_INT] until = 1 to indicate that the DONE signals has asserted.
5. Enable the PL-to-PS level shifters. Write 0x0F to the slcr.LVL_SHFTR_EN register.
6. Begin to use the signals and interfaces between the PS and PL.

Вы говорите про шаг 2, т.е. это включение шифтеров для управления логикой PL со стороны PS. А я говорил про шаг 5, чтобы разрешить взаимодействие PS и PL. Так что мы говорили немного о разном, но оба близки к истине. 🙂

2 часа назад, dxp сказал:

Да, может. Как и тыщах других SoC, в которых всё это делается и покруче (ядра новее, быстрее). APU в Zynq-7000 -- это вполне заурядная штука, если её ядра заменить на какой-нить другой проц, было бы тоже норм. Вот, кстати, я был бы очень рад, если бы вместо Cortex-A9 там был бы какой-нить Cortex-M c более простой широй типа AHB, чтобы латетность доступа в ПЛИС была поменьше (AXI, конечно, крута, и пропускная там ништяк, но латентность так себе в случае с Cortex-A), а вместо жручего DDR3 контроллера был бы простой SDR с поддержкой LPSDR (накрайняк LPDDR). Мне бы пропускной хватило, а линукс мне не нужен, мне нужно однокристальное решение для построения гетерогенной системы.

Вот тут я полностью с вами согласен, и было бы просто чудесно, если бы запуск (и доверие к запуску) PS строилось на логике PL, которую я бы сам и написал. Но чего нет, того  нет, такова особенность (кривизна как по мне) архитектуры этих Цинков. Поэтому в других решениях оказывается проще воткнуть ПЛИС потолще и использовать синтезируемое ядро на базе RISC-V или того же Microblaze. 

2 часа назад, dxp сказал:

А вот если убрать ПЛИС, это в корне меняет всё -- в этом SoC просто сразу теряется весь смысл.

С этим я и не спорил, ценность Цинка в том и есть, что это ПЛИС + процессор.

2 часа назад, dxp сказал:

Ну, суть-то от этого не меняется: мы выясняем, кто главнее в SoC с FPGA: процессор или ПЛИС. И я лишь оспариваю тезис, что критерий "кто кого загружает" и определяет главного, не отражает суть.

Ок. На первом этапе (на этапе запуска) как ни крути, а процессор главнее, т.к. всем управляет он и его BootROM. Дальше всё зависит от архитектора и разработчика системы, т.к. в PL может быть ещё какой-нибудь МК, который на самом деле будет всем рулить в риалтайме и будет самым главным. Это не принципиально, может быть по-разному. Если вы думаете, что я этого не понимаю, то заблуждаетесь относительно меня. 🙂

 

[sonycman 2]

Интересно, почему такой застой и отсутствие обновленных версий цинков у Зайлинкс?

Как тут правильно указали - чипы уже древние, им более 10 лет и новых на горизонте не видать.

Почему? В Америке исчезли инженеры\деньги?

 

Вон та же Альтера до сих пор тужится выпустить свои новые Эджилексы, а в продаже их как не было, так и нет.