Я работаю проектировщиком аппаратного блока графического процессора в телефонах Samsung, в рамках совместного проекта с AMD. Сейчас наш менеджмент расширяет команду и поощряет инженеров распостранять информацию о новых позициях среди своих знакомых. Я решил написать это пост для более широкой аудитории, так как множество людей, способных пройти интервью на RTL или DV позицию - больше, чем множество моих знакомых. Если вы сможете прислать мне ответ на задачку в моем посте вместе с вашим резюме, я перешлю его нанимающему менеджеру и рекрутеру нашей группы (в комментах прошу ответ не писать). Если резюме им понравится, вам нужно будет пройти стандартное собеседование на несколько часов, с несколькими инженерами, у каждого из которых свой набор задачек.
Также я покажу материалы, по которым можно готовиться к собеседованию, особенно если вы студент или у вас ограниченный опыт в электронной промышлености.
Скажу сразу что для данных позиций нужно разрешение на работу в США. Если у вас его нет, я агитировать компанию за петицию на H-1 визу для вас не могу, но вы можете решить задачку чисто для расширения кругозора или демонстрации молодецкой удали.
Для опытных инженеров задачка слишком простая, но для недавних выпускников вузов по специальности Electrical Engineering или Computer Engineering - в самый раз. Это должен уметь решать выпускник практически любого американского вуза который брал курс типа MIT 6.111 Introductory Digital Systems Laboratory, а также выпускники российких вузов МИЭТ, МИРЭА, ВШЭ МИЭМ, ИТМО, Иннополис, МГУ ..., украинских КПИ, черниговского политеха, топ технических вузов Беларуси, Армении, Киргизии итд.
Ожидается, что вы владеете основами проектирования цифровых схем на уровне регистровых передач (Register Transfer Level - RTL), используя синтез с языка описания аппаратуры Verilog/SystemVerilog. Если вы напишете решение на VHDL - это тоже пойдет. Вы также можете приколоться и написать решение, используя high-level synthesis, графическую схему (schematic entry) или экзотические языки типа BlueSpec или Chisel, можете даже собрать ответ на советских микросхемах К155, транзисторах, радиолампах, реле или гидравлике - но все это я менеджменту не перешлю, хотя мне будет на это интересно посмотреть.
Итак, формулировка задачки:
Вам нужно спроектировать блок, который превращает поток данных шириной w бит в поток данных шириной w*2. Как прием узких данных в блок, так и передача широких данных из блока должна делаться с помощью valid/ready интерфейса в духе протокола AMBA AXI-Stream или каналов AXI4:
Вам также нужно написать тестовое окружение к блоку, которое обосновывает функциональную корректность и демонстрирует оптимальную пропускную способность блока. Большим плюсом будет, если вы еще и напишете код для проверки функционального покрытия, а также утверждения темпоральной логики, которые можно было бы проверить с помощью формальной верификации.
Valid/ready протокол должен следовать правилам, описанным для AXI (это все не ARM-specific и не AXI-specific, просто в армовской документации эти правила сформулированы лучше всего), в частности Valid не должен ждать Ready=1 для перехода от Valid=0 к Valid=1. Ведущий блок должен выставить Valid=1 не глядя на Ready, и потом ждать момента когда и Valid=1, и Ready=1 на положительном фронте тактового сигнала:
Ready может быть выставлен как через несколько тактов перед Valid, так и после Valid, или в том же такте что и Valid. Протокол Valid/Ready должен работать даже если Ready меняется случайно (в нашей задачке случайным может быть Downstream Ready для широкой шины). Также для оптимальной пропускной способности полезно обратить внимание на вот такое замечание в спецификации AXI (читать всю спецификацию не обязательно, я уже привел все что нужно для решения в этом после):
В отсутствие backpressure (то бишь когда downstream_rdy всегда равен 1), блок должен позволять прием данных каждый такт и выдачу данных через такт:
Полезная литература для подготовки к интервью
Вот самый лучший учебник начального уровня по вопросу, доступный сейчас на русском языке. Если вы не понимаете все, что в нем написано, то ваши шансы на трудоустройство в микроэлектронную компанию на RTL или DV (Design Verification) позицию не очень:
Вы также можете можете использовать более старый вариант учебника ниже. Главы 1-5 у учебников совпадают, но в главах 6-7 белый учебник использует модную молодежную архитектуру RISC-V, а зеленый - олдовую архитектуру MIPS. С точки зрения интервью на джуниор позицию RTL или DV инженера для проектирования или верификации GPU - это все равно.
Даже если вы будете проектировать не блок в подсистеме геометрии (как я) и не блок в pixel pipe, а шейдеры или управляющее ядро - даже в этом случае совершенно все равно, вы учились на MIPS или на RISC-V. Хотя с другой стороны, если вы учились (допустим) на микрокалькуляторе МК-54 или (допустим) на компьютерах ДВК и Радио-86, то вам нужно подучить концепцию конвейера (глава 7 и одного и другого учебника) для того, чтобы утверждать, что вы разбираетесь в основах архитектуры и микроархитектуры ЭВМ:
Подспорьем к учебнику Харрисов является вот такая книжка, которая привязывает его к упражнениям на платах с микросхемами регонфигурируемой логики ПЛИС / FPGA:
Но на одном учебнике Харрисов интервью вы не пройдете, так как в нем нет ряда тем, которые регулярно спрашивают на интервью, в частности задачки с очередями FIFO, арбитры, пересечение тактового домена, многопортовые памяти итд. Некоторые из тем, не разобранных у Харрисов, можно найти вот в такой книжке, по которой учатся в Стенфорде.
Например в ней есть про двойные буфера (skid buffers), асинхронные очереди FIFO для пересечения тактового домена (Clock Domain Crossing - CDC), работу с числами с плавающей точкой, немножко про банки памяти итд.
Но учебников недостаточно - стоит еще и читать всякие тексты из интернета, в частности статьи Клифа Каммингса (он на фото справа), особенно про пересечение тактовых доменов, синхронные и асинхронные сбросы. А также материалы сайтов rtlery.com и zipcpu.com, особенно если у вас ограниченный опыт в промышленности. Еще пять материалов про арбитры, credit-based flow control и работе с памятью, которые помогут поднять тонус перед собеседованиями:
Credit Based Flow Control. Архитектура ЭВМ, Принстонский университет
Arbiters: Design Ideas and Coding Styles by Matt Weber
Generating fast logic circuits for m-select n-port Round Robin Arbitration
Building Multiport Memories with Block RAMs
Composing Multi-Ported Memories on FPGAs
Кроме тем, связанных с проектированием, и RTL, и DV инженеру нужно четко понимать, как работает симулятор, иначе вы будете плодить баги, связанные с гонками (race conditions) и различными результатами симуляции до и после синтеза (pre- and post-synthesis simulation mismatch). Из этого понимания следует правильная методология использования блокирующих и неблокирующих присваиваний, которая вскользь упоминается у Харрисов. На тему работы симулятора есть очень полезный Appendix вот в такой книжке, которую я тоже рекомендую:
Для инженеров, которые идут на позиции по design verification, я рекомендую проштудировать следующие три книжки от начала до конца.
В первой книжке (Chris Spear) по человечески описана coverage-driven constrained random verification methodology, а также отличия SystemVerilog от Verilog-95 и Verilog-2001 (если вы их учили в вузе). Без этой книжки вам придется копаться в стандарте, который во-первых написан более мутным языком, а во вторых не объясняет зачем нужны те или иные фичи языка.
Вторая книжка (Vanessa Cooper) - это короткий тьюториал по UVM, который можно изучить быстро. UVM не так широко используется в электронных компаниях, как утверждает маркетинг компаний, которые продают тулы, поддерживающие UVM. Но что такое UVM и с чем его едят должен в 2022 году знать каждый верификатор, так как шанс нарваться на кусок UVM-а в том или ином проекте существует. Только не копируйте из этой книжки шаблон писания драйвера шины - он совершенно не подходит для более сложных шин, типа AXI с конвейерностью и внеочередным получением ответов (для них нужно поддерживать табличку "транзакций в полете" и строить конечный автомат, использующий такую табличку).
Третья книжка (Janick Bergeron) описывает философию верификации и индустриальные практики. Если вы никогда не работали в команде верификации чипа или блока, эта книжка съэкономит время вас и ваших коллег, когда вы будете задавать им вопросы.
Помимо книжек есть полезные сайты, например www.testbench.in
Если у вас нет доступа к дорогим промышленным тулам для симуляции Synopsys VCS, Cadence Xcelium и платной Mentor / Siemens EDA Questa, то я рекомендую вам получить бесплатный доступ через сайт под названием edaplayground.com . Бесплатные тулы вне этого сайта (Icarus Verilog и бесплатная версия Questa) достаточны для тренировки решения интервьюшных задач на тему RTL, но в них нет поддержки covergroups, constrained random generation и concurrent assertions, чем необходимо владеть для позиций по DV.
Кстати о concurrent assertions, утверждениях темпоральной логики. Они в последние годы становятся важным инструментом не только инженеров-верификаторов (DV), но и инженеров -проектировщиков (RTL), особенно в связи с развитием тулов формальной верификации типа Jasper Gold. Эти тулы позволяют автоматически получать ответы на вопросы типа "допустим на входе в блок у меня такие-то сигналы установлены так-то. Следует ли из этого, что потом, через много тактов, на выходе будет (или не будет) то-то?" Тул автоматически проанализирует ваш RTL и ответит "увы, вот контрпример" и покажет сценарий, когда ваше предположение нарушается, например в логике участвует сигнал, который вы забыли.
Очень полезно для анализа чужого кода. Я вообще думаю, что вузы могли бы вводить такие тулы для обучения студентов в самом начале учебной программы, чтобы они сразу правильно ставили мозг на анализ событий в конвейерах и вообще сложных последовательностных схемах.
"А как же графика?" - спросите вы, - "ведь железо, которое я буду проектировать, предназначено для быстрого вывода на экран монстров в шутерах, не так ли?" Да, вам нужно будет в конце-концов изучить графику, начиная с софтверного API, посколько все эти объекты - треугольники, матрицы преобразований координат, плоскости для отрезания и т.д. будут приходить к вам в виде данных на шинах и всяких установок извлекаемых из регистров, в которые будет писать софтверный драйвер. Но это необязательно учить сразу. Сразу нужно уметь решать микроархитектурные задачки, писать на верилоге и понимать что такое статический анализ тайминга. А монстры и шутеры - это потом, в процессе.
Комментарии (31)
Armmaster
02.11.2022 19:22А в московском Samsung hw разрабатывают?
YuriPanchul Автор
02.11.2022 19:32Я не могу за них комментировать. Я знаю, что они активны в программировании NPU и встроенных чипов, а также у них есть люди владеющие FPGA, но про ASIC design там не в курсе.
Brak0del
03.11.2022 11:44Очень полезно для анализа чужого кода.
Вот кстати, а какие требования промышленные ASICоделы в целом и Samsung в частности предъявляют к коду? Как управляют сложностью? Может быть какие-то метрики тулзами считают и дают по рукам за превышения? Вопросы навеяны такой книжкой.
YuriPanchul Автор
04.11.2022 09:00+1Это очень обширный вопрос - про управление сложностью, в это входит и IP reuse, и методологии верификации, и автоматическая генерация кода для регистров и интерфейсов итд. Но метрики как везде - блок должен вписываться в бюджет тактовой частоты, количества D-триггеров, площади, статического и динамического (зависящего от количества переключений). Первые четыре метрики меряются во время синтеза (грубого, без floorplan , и более точного, после размещения). Последняя метрика требует более тонких методов - симуляции на уровне графа логических элементов после синтеза с помощью тулов типа Synopsys PrimeTime PX или Cadence Joules, или оценки с помощью Mentor Power Artist.
Brak0del
04.11.2022 10:39+1Но метрики как везде - блок должен вписываться в бюджет тактовой частоты, количества D-триггеров, площади, статического и динамического (зависящего от количества переключений).
Спасибо за развернутый ответ. Да, это ожидаемые и понятные метрики. Вопрос появился потому, что читал про ребяток, которые в качестве метрик в дополнение к этим ещё используют метрики сложности кода: т.е. стремятся минимизировать кол-во входных/выходных/внутренних состояний, кол-во конечных автоматов внутри одного модуля, кол-во строк кода и т.д. Их посыл в том, что это упрощает верификацию, уменьшает сложность и снижает кол-во ошибок. Не было понятно, стало ли это распространенной практикой в индустрии, или это больше их теоретические изыски в недрах Synopsys без особого продолжения.
vkni
Это же ваши ровесники, получается.
Спасибо за статью. А как вы видите будущее RISC-V? Вроде бы китайцы забабахали ноут на RISC-V, так что "универсальные машины разработчика" скоро должны появиться. Соответственно, есть шансы, что софт под Linux будет довольно хорошо работать на RISC-V (и быть соответственно оптимизирован).
Есть вообще ощущение, что RISC-V — закрывающая универсальная RISC архитектура? То есть, следующей, имеющий шансы на широкое распространение уже не будет, вернее это будет не RISC.
YuriPanchul Автор
*** Это же ваши ровесники, получается ***
Ну дык я же не эйджист
*** А как вы видите будущее RISC-V ***
RISC-V уверенно занимает разные встроенные ниши - ядра для контроллеров дисков, housekeeping ядра в SoC итд. Он фактически находится в той же позиции, что MIPS 10 лет назад, за исключением того, что за RISC-V стоит движуха, а MIPS рассматривался как выдавливаемый ARM-ом и утрачивающий поддержку. Теперь такие компании как SiFive, Andes и другие могут отвоевать часть рынка у ARM. RISC-V также заместил позиции MIPS при преподвании микроархитектуры в университетах.
Линукс на RISC-V разумеется работает. Для существенного распостранения RISC-V на high-end рынках (мобильный, ноутбуки, суперкомпьютеры) нужно две вещи: 1) инвестировать в микроархитектуру(*) (продвинутые предсказатели переходов, load-store units с multiple pipes, продвинутые суперскаляры и векторные расширения 2) поддержка RISC-V крупными софтверными компаниями, в первую очередь Гуглом для андроида.
(*) Архитектура = система команд и формат видимых программисту регистров, а микроархитектура = аппаратное устройство конвейера и структура вычислительных блоков.
На рынке КНР, где действуют санкции против Huawei, которому не дают использовать Google Store, у RISC-V есть возможность win big, если китайцы наймут достаточно продвинутых специалистов по микроархитектуре, которые смогут переплюнуть топовые Cortex-A ядра на бенчмарках типа CoreMark.
"закрывающей универсальной RISC архитектурой" RISC-V имхо не будет. Дело в том, что в процессе развития электроники могут появиться изобретения (например трехмерные чипы с хитро устроенной памятью), под которые нужно будет по другому оптимизировать систему команд. По сути, RISC-революция с load-store архитектурным подходом произошла на фоне быстрого роста отношения скорости арифметических вычислений к скорости доступа к памяти. Из-за этого оказалось выгодным строить кэши и редуцировать сложные методы адресации, чтобы избавляться от зависимостей между инструкциями и делать спекулятивное выполнение в суперскалярных конвейерах.
Что-то такое же, но в другую сторону, может появиться и в будущем, из-за чего в RISC-V могут обнаружиться неудобные вещи. Примеры неудобных вещей в прошлом: сегментные регистры в x86, branch delay slots в MIPS и регистровые окна в SPARC.
UPD: я прочитал вас невнимательно. "это будет не RISC" - ну да, при таких фундаментальных изменениях как я описал, это запросто может быть не RISC. Но может и RISC, трудно сказать.
Armmaster
Большинство из такого рода проблем вполне решаются дополнительными расширениями. Я вот сходу не могу придумать какой-то разумный пример, где это не поможет и потребуется реально новую архитектуру придумывать. Хотя в теории всё возможно, конечно.
Мне кажется, главная угроза RISC-V - это потенциальный риск получить очень фрагментированную архитектуру, где будет куча как-бы RISC-V, но между собой не совместимых.
vkni
и
вот!
Возможно есть решение сделать какой-то надъязык? Близкий к RISC-V байткод, из которого получалась бы заточенная под конкретный набор расширений оптимизированная программа? То есть, аналог AOT в Андроиде, но для вот этого конкретного семейства процессоров?
Armmaster
Вряд ли нас ожидает такое количество каких-то фундаментальных изменений, они происходят не так часто. Проблема фрагментации RISC-V в первую очередь проистекает от обширности текущих направлений для применения.
Так сама ISA RISC-V в каком-то смысле и является таким байт-кодом. Архитектурные команды можно будет потом преобразовывать в что-то более удобное внутри аппаратуры. Вопрос в том, что в будущем парадигма может настолько серьёзно измениться, что делать это в hw будет либо слишком накладно, либо невозможно. Разработанный байт код сейчас, даже очень абстрактный, потенциально обладает той же проблемой.
vkni
Ну есть же транспилеры. Будет просто ещё один компилятор из RISC-V в RISC-V. Фактически, при установке программы будете прогонять "оптимизатор под процессор системы". Но, насколько я понимаю, в настоящих скомпилированных программах вырезана значительная часть информации, которая может быть крайне полезной для такой перекомпиляции. Поэтому байт-код может быть удобнее.
Можно раскрыть?
Armmaster
Удобнее всё это сделать в проце и не городить не нужный огород в софтварном стэке. Тем более если это ничего не даёт по сути
RISC-V претендует на то, чтобы стать общей архитектурой для широкого набора примений - микроконтроллеры, высокопроизводительные GP процессоры, мобильные процессоры, AI-процессоры и т.д. Везде выдвигаются разные требования и необходимы разные расширения. Например, где-то нужен мощный блок SIMD, где-то нет. Где-то нужны всякие криптографические расширения, где-то нет. Где-то есть поддержка только 32 бит, а где-то только 64 . И таких различий достаточно много. В итоге архитектура может существенно расползтись - это проблема.
vkni
Это поможет избежать комбинаторного взрыва поддержки расширений в скомпилированном тексте программы. То есть, вам не надо будет делать ветвлений в случае если у нас AVX512 есть или нет.
Armmaster
Конкретно проблема SIMD в Riscv V решена достаточно универсально ( даже слишком на мой взгляд). Если интересно - ознакомьтесь. Остальное - это очень абстрактно, нужны какие-то конкретные примеры, потому что я не уверен, что понимаю ваше предложение до конца. Я лишь могу сказать, что не вижу варианта внедрения какого-то байт кода, который реально был бы полезен по сумме плюсов и минусов.
mpa4b
Ну всё же risc-v задокументирован достаточно хорошо, чтобы получать несовместимости, следуя стандартам. Но вот если кто-то будет пилить свои нестандартные расширения -- несовместимости будут.
Есть ещё более тонкая проблема -- пусть даже несколько контор сделали несколько ядер со стандартными расширениями, но всё равно под каждое ядро будут свои способы оптимизации кода и что тут делать -- не очень понятно. У того же gcc например поддержано оптимизациями довольно ограниченное кол-во ядер у ARM, а код для старых ядер (например cortex A8) с каждым релизом gcc становится только хуже (медленне, то есть налицо деоптимизация). Что будет в случае 100500 разных risc-v ядер -- пока не очень ясно, но хорошо точно не будет.
Armmaster
Я на комент выше ответил в том числе и на данный тезис.
vkni
RISC-V принципиально отличается от других Рисков только реализованной открытостью (вокруг него есть движуха и сообщество). Но ведь и открытости часто достаточно — тот же Linux взлетел именно из-за неё.
Вот это я и имел ввиду, что стоимость перехода с одного API микропроцессоров на другой API микропроцессоров чудовищно велика. Поэтому только такие масштабные изменения смогут сместить RISC-V с его положения, коли он займёт место универсального набора инструкций. Кмк. Хотя нельзя загадывать, конечно.
А что может быть из серьёзного? Открытость есть. Другая элементная база, приводящая к совершенно другой микроархитектуре? И только. Ну ещё "весь мир в труху" :-(, но это столь же неконструктивное предположение, как и солипсизм.
YuriPanchul Автор
Какой смысл вы вкладываете в слово "открытость" когда говорите о RISC-V (я знаю значение этого слова в нескольких контекстах и перед комментированием просто хочу удостовериться, что мы говорим об одном и том же).
vkni
Это интересный вопрос. Я имел в виду free software, то есть, коммунизацию и соответствующее снижение рисков. То есть, то, чем gcc отличается от Sun Studio: лицензия GPL со всеми вытекающими.
YuriPanchul Автор
Так я и думал. У процессоров это другое. Я это говорю уверенно, потому что мне где-то полгода платили зарплату как MIPS Open Technical Lead, то есть за то, что я разъяснял людям значение слова Open.
Так вот. Главным отличием RISC-V от скажем ARM является так называемая архитектурная лицензия. Это другое, чем лицензия на ядра, которые могут быть не-open и с архитектурой RISC-V. Разберем сначала другие аспекты.
Читать документацию на архитектуру (API процессора) и для RISC-V, и для ARM, и для MIPS могут все - в этом смысле она Open, хотя на ранней стадии разработки для ARM она закрыта, а для RISC-V она относительно открыта, так как определяется комитетом из академии и представителей индустрии.
Движуха по использованию процессоров и поддержки их со стороны софтверного коммьюнити есть и у ARM, и у RISC-V - в этом смысле они обе Open (слово Open в этом значении использовалось в 1980-х для например шины у PC).
Код на верилоге и документация по микроархитектуре высокопроизводительных RISC-V ядер от SiFive и других коммерческих проектировщиков IP не является Open. Этот код лицензируется за суммы в сотни тысяч или пару миллионов долларов (текущий ценник я не знаю, но это порядок). То есть это не как у Линукса, это скорее как Sun Solaris до открытия его кода - API общий (POSIX), код ядра закрыт. В этом аспекте RISC-V от SiFive и ARM одинаковы.
И вот теперь архитектурная лицензия. Это лицензия на право сделать микроархитектурую реализацию (написать свой код процессора на верилоге) которая является совместимой по API (по бишь по архитектуре) с соотвественно ARM или RISC-V. Пример использования архитектурной лицензии - процессор M1 от Apple. В ранних Apple iPhone Apple лицензировал готовые ядра на верилоге от ARM, а потом купил у ARM архитектурную лицензию и стал разрабатывать ядра сам. Вот тут есть ключевое отличие - архитектурная лицензия от ARM стоит суммы порядка десятков миллионов долларов или выше (я не знаю точный ценник сейчас), а вот архитектурная лицензия от RISC-V стоит 0, ничего. Если процессор совместим с архитектурой RISC-V - продавайте на здоровье без отчислений роялти, хотя нужно согласовать с комитетом RISC-V.
Из пункта (4) следует важное отличие для исследовательских проектов в academia. Ранее любой студент, который строил собственное ARM или MIPS ядро, и при этом использовал инструкции свежее чем 17-летней давности (патенты в США истекают через 17 лет) технически нарушал текущие патенты на архитектуру ARM или MIPS. MIPS смотрел на это сквозь пальцы, но ARM иногда присылал письма от юристов "cease and desist" то есть "прекратите немедленно".
Кроме этого, если этот студент утверждал, что его процессор является "процессором с архитектурой ARM", то он тем самым нарушал еще и трейдмарку (про это есть отдельный закон) - даже если не нарушал патент, то есть даже если использовал только версию архитектуры 20-летней давности.
Так вот: RISC-V это убрал, то есть из нулевого ценника на архитектурную лицензию следует свобода процессоротворчества для academia без риска получить письма от юристов. Вот тут главная openess (хотя, еще раз подчеркиваю, коммерческие ядра у RISC-V продаются за значительные деньги с закрытым кодом, то есть они не как gcc
vkni
То есть, RISC-V можно перебить по открытости, создав, скажем RISC-6, который будет давать то же самое, что RISC-V, но ещё и будет предоставляться более-менее полная линейка лицензированных под условной GPL исходников на верилоге для FPGA/ASIC/чего-только-можно + все тесты + разные кодогенераторы компиляторов. Так?
Я имею ввиду, что RISC-6 будет своей отдельной, несовместимой архитектурой.
И спасибо за детальное разъяснение!
YuriPanchul Автор
Да, можно, и если у этого risc-6 будут ядра которые победят по бенчмаркам coremark и другим коммерческие ядра от ARM , SiFive итд, то такая архитектура может даже выиграть на рынке, хотя и не сразу.
YuriPanchul Автор
На самом деле даже перебивать не нужно, достаточно просто сделать конкурентоспособные открытые (с открытым верилогом в гитхабе) high-end ядра архитектуры RISC-V которые бы выиграли бенчмарки у SiFive, Arm итд. Вот это будет действительно как Линукс и gcc.
Foror
>выиграли бенчмарки у SiFive, Arm итд
Зачем их выигрывать? Половина производительности при открытом исходном коде хватит за глаза для микроконтроллеров, носимых устройств и ноутбуков. Остальное можно со временем наверстать и догнать high-end ядра.
YuriPanchul Автор
Тут есть несколько проблем. Рынок микропроцессорных ядер делится на несколько крупных сегментов.
Открытые RISC-V ядра микропроцессорного класса уже достаточны по производительности, но для рынка микроконтроллеров помимо ядра нужен еще и набор периферии - то есть нужно делать набор открытой периферии.
Открытые RISC-V для встроенных систем типа контроллеров дисков уже тоже близки к практичности, например есть SweRV EH1.
Но вот с ядрами для мобильных телефонов и ноутбуков сложнее - если они остают от топовых ARM-ов вдвое, то они могут стать немаркетируемыми - то есть будут интересовать только энтузиастов. Я на эту тему слышал от маркетологов MIPS в свое время .
Foror
Можно упирать на безопасность. Когда у конкурента наспех залатанные спекулятивные дыры, проприетарный процессор и его сложная проприетарная софтовая обвязка, то на твоей стороне всё прозрачно (пусть и за счет падения производительности). Понятно, что еще нужно решить проблему со всей прочей обвязкой - сделать её полностью открытой.
На такое позиционирование найдётся массовый покупатель. Особенно в мире, когда на мобильном или ноуте у тебя финансы (банки, крипта и т.д.) и переход веба на Web Auth API.
vikarti
А что в этом плане значат идея https://www.securitylab.ru/news/532586.php (Китайский проект сделать форк под названием RISC-X),
Куда в RISC-V можно санкциями ударить если хочется?
Ну кроме производства и запрета продавать лицензии SiFive и прочим.
Некуда же? Зачем тогда идея с RISC-X ?
YuriPanchul Автор
Возможно китайцы хотят делать расширения без согласования с комитетом в Америке. Или может быть там что-то непростое по линии патентов.
YuriPanchul Автор
*** Другая элементная база, приводящая к совершенно другой микроархитектуре? ***
Вы не путаете тут архитектуру и микроархитектуру? Я написал выше, что другая элементная база може привести не только к изменению микроархитектуры, устройства конвейера (это происходит с каждым новым ядром), но и к изменению архитектуры, системы команд (помимо примера с отношением скорости арифметики к скорости доступа к памяти можно ещё вспомнить и про прогресс от аккумуляторных архитектур к архитектурам с большим количеством видимых программисту регистров).
vkni
У вас в поле термин "архитектура" — дурацкий. Реально это тип API процессора или тип языка ассемблера.
Я не путаю микроархитектуру и API процессора, то есть архитектуру. В том контексте, который мы обсуждаем, то есть, развитие производства микроэлектронике, ведущее к "увеличению отношения скорости арифметических вычислений к скорости доступа к памяти" напрямую действует на микроархитектуру. А уже на архитектуру (API) действует опосредованно, поэтому и возможно иметь х86 вот сейчас, несмотря на то, что соотношения скоростей изменились принципиально.
То есть, зависимость там такая:
1. физические принципы определяют предельные параметры электрических схем,
2. предельные параметры эл. схем определяют принципы архитектуры электрической схемы компьютера (мат. плата, отдельный ЦП, отдельная память, встроенная или отдельная видеокарта, шины, связывающие их)
3. принципы архитектуры эл. схемы компьютера определяют микроархитектуру процессора (и, видимо, других частей компьютера)
4. и уже микроархитектура процессора, GPU, памяти, определяет интерфейсы => ассемблер => архитектуру процессора (RISC/CISC, что там ещё)
-------------------
Поэтому микроархитектура получается первичнее архитектуры ЦП. И она первой изменится, если мы перейдём, скажем, на графен. А вот изменится ли при переходе на графен архитектура ЦП (ассемблер) — это не факт, т.к. там есть некоторые "резервы адаптивности" (не знаю, как именно это назвать).
YuriPanchul Автор
Хорошо, тогда мы in sync. Физические принципы меняют сначала микроархитектуру, а потом опосредованно архитектуру.