Pull to refresh

Comments 17

Причина 1. Если роцессор работает на ядрах разной битности

Во-первых, очепятка в этом подзаголовке :)

А во-вторых, правильней говорить всё ж о разных архитектурах, а не "битности" (разрядности). Например, в STM32MP15x имеется одно или два 32-разрядных ядра Cortex-A7 и одно 32-разрядное ядро Cortex-M4. "Битности" совпадают, но архитектуры-то реально разные (ARMv7-A и ARMv7-M).

Неверно, тут речь идет именно о "битности":

  • System (SYS) — группа процессорных ядер, принимающих всю нагрузку; на них запускается Linux, пользовательские приложения, они 64-битные. 

  • System Control Unit (SCU) — процессорное ядро, среди прочих функций которого — управление системой питания и загрузкой ОС. Оно 32-битное.

Архитектура у них одинаковая RISC-V. Есть AMP с одной разрядностью, но разным функционалом например Sifive Unmatched, там и разрядность одинаковая, но например на 0 харте отсутвует MMU, и они как раз эмулируются в размках одной машины QEMU.

И все же в данном примере лучше говорить о разных архитектурах :) Да и сам автор пишет:"Так как у ядер чипа разная битность — читай, разная архитектура ".

Ну, вообще-то самое понятие "архитектура" подразумевает программную совместимость -- по меньшей мере, "снизу вверх". Если прогу, написанную для 32-разрядного RISC-V, можно без перекомпиляции запустить на 64-разрядном, тогда можно считать их одной архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому и говорю про "если")

Ну а если сравнить с тем же ARMом одинаковой разрядности, то с одной стороны имеем M-профиль, а с другой -- A- и R-. Хотя почти все собственно команды из M-профиля будут нормально выполняться на процах A- или R-профиля, считать эти разновидности одной архитектурой, как по мне, всё же неправильно: у них кардинально отличается, так сказать, системная архитектура -- в первую очередь, обработка прерываний, и соответствующий код абсолютно непереносим. С другой стороны, A- и R-профили можно считать одной архитектурой: основная разница -- наличие MMU (A) или MPU (R). Ну а 64-разрядная архитектура ARM, понятно, имеет к M-профилю ещё меньшее отношение.

В общем, подозреваю, что с RISC-V примерно так же, как и с ARM: типа одна архитектура, а реально -- несколько, имеющих как общие, так и кардинально различающиеся элементы. Но, как уже сказал, пока в этом вопросе некомпетентен.

Прокомментирую -

Если прогу, написанную для 32-разрядного RISC-V, можно без
перекомпиляции запустить на 64-разрядном, тогда можно считать их одной
архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому
и говорю про "если")

И да, и нет. Общим кодом можно в три команды определить разрядность и сделать jmp на нужный вариант, но что-то сложнее этого требует раздельного кода.

addi t0, x0, 2
sll t0, 31
bne t0, x0, is_64bit

Так намеренно сделали. Но я не видел, например, двухархитектурных бинарников в ELF с компанией.

Хуже то, что архитектура подразумевает 100500 профилей, составляющих ориентированный граф добавления фич, некоторые из них можно получить стандартными средствами вроде чтения служебного регистра misa, но многие - нет, и надо выкапывать где-то отдельно (device tree, ACPI и тому подобное). Грануляция серьёзнее в разы чем с ARM. Но оно на 25-30 лет моложе, так что пока наблюдаем, что выживет из этих промежуточных уровней...

Мы привели пример, когда мы не можем запустить ядра с разной битностью внутри одной виртуальной машины, так как QEMU не позволяет это сделать.

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

Мы используем POSIX mmap, но не напрямую, а через QEMU API: qemu_ram_mmap().

"Linux на такой конфигурации не запустить — он будет неделю стартовать и в итоге вообще не запустится."

Смотря какой Linux. Простой консольный Линукс на CPU без MMU даже на Icarus Verilog за пол часа стартует. А с верилатором думаю 10 секунд будет.

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

Когда-то давным давно я пытался запустить Amber ARM v2a SoC в ПЛИС.

Как часть той работы была симуляция работы процессора и запуск какого-то усеченного Линукс.

https://marsohod.org/projects/marsohod2/amber-arm-soc/396-amber-arm-v2a-soc-verilator

Там в конце моей статьи написано такое:

Самое интересное, что если с Icarus Verilog на подобную симуляцию загрузки ядра Linux уходило минут сорок пять, то теперь, с Verilator, полный старт симулируемой системы происходит секунд за 30! Невероятно. Я честно говоря очень впечатлен получившимся быстродействием. Очень рекомендую присмотреться к Verilator. В некоторых случаях - отличный инструмент.

А чем Synopsys Virtualizer не угодил ? Ну кроме цены (либо сложности поиска китайского кряка учитывая политику). Или аналоги от Cadence/Siemens/Imperas/Windriver....Там хоть сразу десяток разных архитектур можно в одном прототипе. И анализ узких мест в интерконнекте из коробки. И RTL косимуляция, и с HAPS оно замечательно косуществует.

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

Короткий ответ: проблема в сложности закупки лицензированного продукта, а использование неофициального ПО или его взлом противоречат позиции компании. А вы используете какой-то из перечисленных инструментов? Расскажите, какие задачи решаете.

Спасибо за статью, очень интересно. Мне доводилось симулировать RISC-V (VexRiscV без MMU) + небольшой кусочек своего железа (Verilog) с помощью Verilotor-а, потактово исполняя программу в ПЗУ. При отсутствии опыта задача оказалась не из легких, не смотря на то, что в Сети много материала на эту тему.

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

Не критично, но знать надо.

Sign up to leave a comment.