Рублевые вклады с повышенной ставкой: как новым клиентам получить максимальный доход 
Украинский институт признал Пушкина пропагандой «российского империализма» 
Пляж «Улетай» в цветах 
Две сказки от классика 
Международная космическая станция (МКС) 
Осенний Петербург прекрасен. Архитектура вам в ленту и Naren трейдер 
Подарок на Покров 
Послепоходный Берн
30.11.2022 —
Как Америка любила и бодалась с Huawei
Как Америка любила и бодалась с Huawei — и как та ответила
panchul — 01.12.2022
10 лет назад в Санта-Клара, Калифорния, неподалеку от Интела и NVidia, стоял кампус Huawei. В нем работали не только китайцы, но и вообще обычная публика Silicon Valley - индусы, американцы, даже русские попадались. Бизнесмены калифорнийских электронных компаний говорили "Huawei - это дверь в Китай" и заключали с ними крупные сделки.
Но американское правительство Huawei невзлюбило. Можно обсусоливать те или иные поводы, но коренная причина понятна - американскому правительству хочется, чтобы Америка сохраняла технологическое преимущество. Ибо если технология коммодифицируется и айфон не будет ничем особенным, то кто будет читать брошурки про продвижение демократии, распостраняемые американскими посольствами в других странах? Над ними будут просто смеяться.
И вот правительство начало Huawei жучить - и от Андроида отлучило, и от других критических технологий. Но на всяких хитрецов найдется гайка с левой резьбой. И вот что Huawei стал делать по этому поводу.
Но начнем по порядку. Вот как выглядел кампус Huawei на пересечении Central Expressway с San Tomas Expressway (Центральное Шоссе и Шоссе Святого Фомы Аквинского) в Санта-Кларе:
Я в эти здания заходил, так как работал с Huawei в совместном проекте от лица MIPS и даже получил за это табличку на стену:
Про сам проект прессе были известны только слухи, хотя с Huawei / HiSilicon работал не только MIPS, но и например IBM Microelectronics. Про IBM я узнал совершенно случайно, наткнувшись на инженера из этого проекта во время отпуска в Юте. Главное СМИ электронной промышленности, Electronic Engineering Times, писало про проект загадочно, в рубрике EE Times Confidential:
Потом настало это:
Но Huawei - не такая компания, чтобы покорно ползти в могилу из-за каких-то госдеповских бюрократов. Они бодро начали импортозамещение, в том числе в области программ для проектировщиков микросхем, и сразу наняли 50 молодых PhD на разработку алгоритмов EDA (Electronic Design Automation - автоматизация проектирования электроники, по русски САПР):
Я вспомнил про случай Huawei / HiSilicon, когда на днях мне прислал емейл Андрей Садовых из казанского Иннополиса и попросил придумать задачку для их хакатона по программам автоматизации проектирования CASE in Tools 2022.
Я уже участвовал в таком хакатоне как задачкодатель в 2020 году и описал задачку по трассировке и размещению логических элементов микросхемы на Хабре (пост до хакатона и после). Вот команда, которая решила мою задачку и получила приз:
Итак, новая задачка. Назовем ее "Подсчет количества D-триггеров в схеме на основе анализа кода на языке описания аппаратуры SystemVerilog (без учета оптимизации)".
Немного картины с высоты птичьего полета.
Разработчика блока микросхемы оценивают не только по отсутствию функциональных багов, но и по PPA - Power-Performance- Area или Энергопотребление-Производительность-Площадь. При этом:
- В энергопотреблении выделают статическое (все время) и динамическое (пропорционально переключениям, зависит от конкретного теста);
- Производительность разделяют на пропускную способность (сколько транзакций проходит через блок за N тактов) и тактовую частоту (1 / сколько длится такт);
- Площадь делят на размер блоков встроенной статической памяти и площадь под стандартные ячейки.
Для грубой оценки площади под стандартные ячейки в микросхемах ASIC удобно использовать количество D-триггеров, минимальных элементов состояния / памяти. Это связано с тем, что пропорция ячеек комбинационной логики к количеству D-триггеров во многих типах схем статистически сходна и именно количество D-триггеров является узким местом. В FPGA ситуация несколько другая - там D-триггеров по сравнению с комбинационной логикой много и их не нужно так сильно экономить как в ASIC-ах.
Количество D-триггеров важно еще и потому, что своими переключениями они жрут много электроэнергии.
Короче, на проектировщика блока архитекторы чипа как правило спускают:
- Функциональную/архитектурную спецификацию;
- Требования к пропускной способности;
- Бюджет тактовой частоты;
- Бюджет количества D-триггеров;
- Общий бюджет площади, включающей площадь блоков статической памяти;
- Пожелания понизить энергопотребление по сравнению с предыдущим блоком на столько-то процентов.
Суть задачи
Подсчитать количество комбинационных логических элементов в схеме, описанной на языке SystemVerilog - это однозначно не хакатонная задача - она требует сложной технологии логического синтеза. Но вот количество D-триггеров подсчитать гораздо проще - достаточно найти в коде все так называемые неблокирующие присваивания и суммировать размеры всех переменных, к которым они применяются.
Варианты задачи разной сложности
Разумеется, при этом возникает много трудностей. В зависимости от формулировки задачу подсчета D-триггеров на основе кода можно решить за любое время от 1 часа до 1 года. Перечислим эти трудности (потом мы перечислим их снова, но уже с картинками):
- Разработчик / писатель кода на верилоге мог по неаккуратности использовать блокирующие, а не неблокирующие присваивания. Мы не рассматриваем этот вариант - мы будем считать, что писатель кода жестко следовал рекомендуемой методологии проектирования.
- Для простейшего варианта хакатона (на час) можно написать простой скрипт на питоне, который будет работать только если все переменные явлются однобитными; для более интересного хакатона (на день) стоит рассматривать многобитовые вектора; для еще более интересного (на пару дней) - многомерные массивы, а для варианта на год - все структуры данных в языке SystemVerilog.
- Для целей хакатона вероятно стоит парсировать код, в котором не используются директивы препроцессора (`define), нет параметризации (parameter, localparam) и нет конструкции generate. Хотя если реализация на хакатоне делается на основе существующего open-source парсера верилога (например из Icarus Verilog или из Yosys), то можно попробывать обрабатывать код и со всеми этими конструкциями.
- Для простого хакатона наверное стоит подсчитывать D-триггеры только в одном модуле. Для более сложного стоит парсировать и модульную иерархию.
Инструментарий
Мне честно говоря самому интересно, до чего дойдут студенты. Как я уже сказал:
1) Простейший вариант (без иерархии, параметризации и с однобитовыми переменными) можно написать на языке типа питона или джавы за час.
2) Если использовать многобитовые переменные и многомерные массивы, на решение может уйти еще полдня, но того же питона тоже должно хватить. Возможно понадобиться применить регулярные выражения.
3) Модульная иерархия вносит дополнительные сложности. Помимо быстрого кодирования на питоне или джаве (на что может уйти день) стоит рассмотреть вариант освоить чужой парсер верилога на C++ (Icarus Verilog или Yosys) и модифицировать его для этой задачи.
Иллюстрации частных случаев
Теперь то же самое, но с картинками. Первые два модуля вообще не содержат никаких D-триггеров - в них нет ни always-блока по фронту, ни неблокирующих присваиваний ("<="). Только блокирующее внутри "always_comb" ("=") :
Такая схема синтезируется в двух-входовый логический элемент И:
А вот как выглядит код, порождающий D-триггер. В нем есть неблокирующее присваивание ("<=") к переменной "c" которая объявлена как выходной порт и имеет размер 1 бит.
Неблокирующее присваивание находится внутри always-блока по фронту тактового сигнала (хакатонное решение может игнорировать этот факт, обращая внимание только на переменную, к которой применяется неблокирующее присваивание).
Также важно не спутать неблокирующее присваивание с операцией "меньше или равно" которая тоже пишется как "<=".
Этот код соответствует следующей схеме. Квадратик на ней - это D-триггер:
Несколько неблокирующих присваиваний к одной и той же переменной не порождают несколько D-триггеров. Но неблокирующие присваивания к разным переменным - порождают. В примере слева неблокирующие присваивания делаются двум однобитовым переменным, что порождает два D-триггера. Синхронные сбросы у этих D-триггеров перед оптимизацией превращаются в мультиплексоры, но это не важно для нашей цели подсчета D-триггеров:
Следующее усложнение хакатона - это добавление переменных шириной в несколько бит. В примере ниже результат умножения двух 3-битных чисел "a" и "b" помещается в регистр "c" шириной 6 бит. Регистр - это просто группа из D-триггеров, которая в данном случае состоит из D-триггеров c[5], c[4], c [3], c [2], c[1] и c[0]:
Если усложнить задачу вне рамок хакатона, такой модуль можно параметризовать - либо с помощью препроцессора (слева), либо с помощью ключевого слова "parameter" справа:
Другое важное усложнение, которое стоит сделать во время хакатона - это неупакованные массивы с размерностью справа от идентификатора. Слева пример схемы сдвигового регистра шириной 3 бита и глубиной 5 элементов, который использует 3 * 5 = 15 D-триггеров.
Вот как выглядит схема такого сдвигового регистра, обратите внимание что D-триггеры одного элемента собраны в "книжечки" по 3:
Стандарт SystemVerilog также поддерживает синтаксис "logic [2:0] a [5]" вместо "logic [2:0] a [0:4]". Вне рамок хакатона можно было бы написать программу, которая подсчитывает D-триггеры для сложных типов данных, например структур:
Наконец, было бы хорошо (возможно не на хакатоне, а после него) написать программу, которая бы парсировала иерархию модулей и подсчитывала D-триггеры на всех уровнях. Модули в верилоге как матрешки, за исключением того, что одной и той же матрешки может быть несколько экземпляров - D-триггеры во всех экземплярах нужно суммировать, это не как в софтвере с вызовами функций;
А вот случай использования конструкции generate. Его имхо можно покрыть на хакатоне только если использовать чей-то готовый open-source парсер:
То что выглядит синтаксически как софтверный цикл - на самом деле не цикл, а своего рода макро, порождающее несколько экземпляров модуля m03 (D-триггеры в них нужно суммировать).
В этой схеме при w=3 будет шесть D-триггеров - три из always-блока на верхнем уровне и три из трех экземпляров модуля второго уровня m03.
Я надеюсь, что какая-нибудь команда в Иннополисе не напугается и примет мою задачу. Она, при разумной формулировке, проще, чем может показаться из моей заметки. В худшем случае можно сделать "grep '<=' | sed ... | sort -u | wc -l" - и объявить задачу выполненной (это вполне ответ для формулировки задачи без иерархии и с однобитовыми переменными).
Так что успехов и вперед. Это поможет вам нарастить скиллы в компиляторах, скриптинге и разумеется основах цифрового проектирования - очень ценный рабочий навык в современной международной обстановке.
Задание уже выложено на сайт
CASE in Tools - Cases 2022
You are welcome to submit a challenge at [email protected]
www.caseintools.info
Вот описание на английском:
Electronic Design Automation (EDA)
Yuri Panchul is an electronic chip designer (MIPS, Juniper and other companies); a founder of an EDA startup C Level Design acquired by Synopsys, an editor of a book published by HSE MIEM and an author of an online course developed by RUSNANO.
Context: When a chip architect gives a hardware block designer the architectural specification for a new block, he also gives the designer a set of requirements. These requirements include:
1. The performance or bandwidth: a number of instructions, transactions, network packets or graphical primitives processed by the block in a number of clock cycles.
2. The timing budget: the number of picoseconds available for the combinational logic to stabilize within one clock period. In order words, the required clock frequency.
3. The total area budget, which includes the area for the embedded SRAMs and the ASIC standard cells.
In addition, the designer gets guidance on power optimization. One of the key metrics related to both area and power is the count of D-flip-flops (DFFs), the main state elements in digital design. DFFs are used to build hardware pipelines, state machines, FIFO queues and CPU scoreboards. The designer:
1. Receives the DFF budget from the chip architect;
2. Estimates the number of DFFs required for each sub-block early in the design cycle; and
3. Tracks this number every week till the chip tapeout.
A digital design is almost always done using a hardware description language: Verilog, SystemVerilog or VHDL. The technology that converts a Verilog code into a graph of logic elements is called logic synthesis. The synthesis technology is complicated and not suitable for a hackathon. However it is possible to approximately count the number of DFFs even without full synthesis, just by finding so-called non-blocking assignments in Verilog code and adding the sizes of the variables on the left-hand sides of non-blocking assignments.
Task: Write a program that estimates the number of D-flip-flops in an electronic circuit by a quick analysis of its Verilog source code.
Instruments: this problem has multiple levels of difficulty, depending on how much Verilog syntax we are willing to support:
1. If we restrict the input code to single-bit variables within a single module, we can write just a few Linux commands that do the job. We can grep for '<=' non-blocking assignment characters, then collect the unique identifiers on the left-hand sides of non-blocking assignments and report their number. An experienced Linux user can write a simple "grep|sed|sort|wc" pipeline for it in a few minutes.
2. A more complicated case, with parsing bit vectors and unpacked arrays, would take longer, up to several hours. You can use regular expressions in Python or Lex & Yacc - style parsers in C or Java.
3. If we are going to support counting DFFs in the Verilog module hierarchy, we need to parse module instantiations and build the instance tree. This adds hours of programming but can still be done during a short hackathon.
4. If we extend the task to support Verilog preprocessor, parameterized modules, "generate" constructs, "struct" types and the assignments inside Verilog "tasks", we probably need a "real" Verilog parser. There are some open-source parsers of Verilog, including Yosys, Icarus Verilog and Verilator. Your hackathon team can study and utilize them if you wish to go this way.
Whatever you decide to do you are likely to get a good experience in scripting, compilers and digital design.
For more details see the description of the project in an article on the Habr website (in Russian) https://habr.com/ru/post/702186/
Оставить комментарий
Популярные посты:
avega_63">
avega_63
Цветущий октябрь
Цветущий октябрь
Предыдущие записи блогера :
Архив записей в блогах:
Не подвёл Дональд. В пиар и медиа он понимает лучше любого другого президента США. Всего за 2 дня в кресле столько инфоповодов «родил», и сам ими же и пользуется в первую очередь. Классические медиа отстают ...
Когда читала эту статью, на автора не поглядела - а потом с удивлением обнаружила, что это Делягин. Значит, не так уж и зря подписалась под очередной "дискурс". Потому и перепостить не грех. Конечно же, я ничего не имею против граждан с польскими и ...
Сегодня села посмотреть на прогресс по стодневке. С одной стороны, странно, что я об этом вообще думаю, а с другой - рутины помогают не свалиться в бездну горя, а письмо так вообще отличный метод терапии. Поэтому как-то стараюсь следовать напоминалкам, когда не напряжно. 1. Полчаса ...
Визуальная часть, бесспорно, радует. Спокойствие, полная уверенность в себе , почти божественное отсутствие суетливости, ощущение абсолютной надежности. Да. Вот с вербально-содержательным аспектом лично у меня возник вопрос, с которым нельзя не разобраться... Понимаете, тут де ...
08:45:46 DSC_4319
Taken on July 12, 2021
Nikon D60 ,18.0-55.0 mm f/3.5-5.6
ƒ/10.0
55.0 mm
1/400
200
Vecāķi, Rīga, Latvia Вецаки, Латвия
dog, ...
