The post has been translated automatically. Original language: Russian
Artificial intelligence already knows how to write code, explain errors, and suggest solutions to problems. But processor design is much more complicated than conventional programming: it requires simultaneous consideration of architecture, memory, device interactions, time dependencies, and a variety of rules that can be violated far from the site of the error.
Therefore, it is more interesting to ask not whether AI is capable of creating a processor on its own. It is much more practical to understand in which parts of the development it can already be useful to an engineer and what needs to change in the design process itself.
We are investigating this issue during the development of the Memora8 processor.
It's not enough just to show the AI the source code
Modern models work quite well with individual fragments of programs. You can pass a function, module, or error message and ask them to find the problem or suggest a fix.
When developing a processor, this quickly becomes insufficient. The value of one module is often determined by rules that are located completely elsewhere in the project.
For example, the memory access code may look completely correct on its own. But to understand its correctness, you need to know who has the right to own a certain area of memory, when this right is transferred, and what actions are allowed before and after the transfer.
If the AI only sees the source code file, it may not know these rules. As a result, he is able to propose a technically correct change that disrupts the architecture of the entire system.
Therefore, for serious AI engineering work, you need not only code, but also context.
The architecture must be described explicitly.
Some of the engineering knowledge usually exists in the head of developers. Why this particular method of data exchange is used, which states are allowed, which combinations are considered erroneous, and which solutions have already been tried before — not all of this is written in the source code.
This situation is familiar to humans. The developer has been working on the system for a long time and gradually remembers a large number of unspoken rules.
This is a serious problem for AI. A new conversation almost always begins with the need to give him the right part of the context again.
When developing Memora8, we try to make the architectural rules explicit: separately describe the memory model, devices, commands, processor states, and connections between components. The more such solutions are expressed in a verifiable form, the less we have to hope that the AI will correctly guess the developer's intention.
This is useful not only for AI. Explicit rules make the system clearer for the person himself.
AI is well suited for finding contradictions.
One of the useful tasks is to compare different parts of the project. In a large system, one rule can be described in an architectural document, another in the source code, and the third in tests.
As the project progresses, these ideas may begin to diverge. The specification says one thing, the implementation does another, and the old test continues to check the outdated behavior.
AI is able to quickly compare such materials and pay attention to possible contradictions. He may notice that the new memory solution does not match the old command description, or that the two documents define the state of the same device differently.
But here it is important to distinguish between detecting a problem and making a decision. AI can show a contradiction, but it's up to the developer or a formal review to determine the correct option.
From code generation to working with rules
The most obvious way to use AI is to ask it to write a piece of code. When developing hardware, this is also possible: the model can offer the implementation of a small block, a test or an auxiliary program.
However, a potentially more interesting area is above the level of individual lines of code. AI can be used to work with the very structure of the solution.
For example, when changing the memory architecture, you can ask to determine which commands, devices, and checks will be affected by the new rule. When adding processor state, find places where the existing logic assumes the old set of states.
This is no longer an ordinary addition to the code editor. AI begins to work with the project as a system of related solutions.
To do this, however, the connections between the solutions themselves must be accessible to the machine.
Formal verification gives AI boundaries
AI has a well-known problem: a convincing-looking answer is not necessarily the right one. In plain text, this is unpleasant, and when designing a processor, an error can lead to incorrect architecture or hardware implementation.
Therefore, the combination of AI with formal verification is especially interesting.
AI can suggest an implementation or a change, but it is not the language model itself that should give the final answer about the implementation of certain rules. These properties can be checked with a separate tool.
For example, AI suggests changing the mechanism for transferring ownership of memory. After that, SJV can check whether the rule remains true, according to which one memory area should not belong to two processors at the same time.
This results in a division of responsibilities. AI helps to find solutions, and the formal system verifies their properties, which can be strictly formulated.
This approach seems much more reliable than trying to just trust the model's responses.
AI can also help with the verification itself.
A formal description is also created by a person, so there is a lot of manual work left here. You need to understand which property is really important, how to formulate it, and which model boundaries to choose.
AI can also help at this stage. For example, according to the architectural description, it is able to offer a list of properties that are worth checking: acceptable states, resource ownership rules, mandatory actions after a command, or prohibited combinations of conditions.
Such suggestions cannot be automatically considered correct. But they are useful as an additional look at the system and can help you notice a rule that the developer has not yet written down.
It is especially interesting to be able to compare the specification with existing checks and find requirements for which there is no formal property yet.
The decision history is also important
During long-term development, it is useful to know not only the current system design, but also the reasons for the decisions made. Sometimes the option was already considered a few months ago and was rejected due to a problem that is not obvious today.
A person can forget such a story. Moreover, AI will not be able to take it into account if it is not recorded anywhere.
Therefore, along with the code and specifications, it is important to preserve architectural solutions, discovered limitations, and experimental results. Then, with a new change, AI can take into account not only the current state of the system, but also the previous experience of the project.
In this mode, it becomes not just a code generator, but a tool for working with accumulated engineering knowledge.
What happens in Memora8
Memora8 is convenient for such experiments precisely because the project covers several levels at the same time. There are architectural rules, a description of commands, a memory model, an implementation of hardware blocks, modeling programs, and formal verification.
AI can be used to transition between these levels. For example, a change in an architectural rule can be traced back to specific implementation modules and tests, and the error found can be traced back to the rule that needs to be clarified.
At the same time, we try not to build the process around the idea that AI is always right. On the contrary, the more he participates in the development, the more important it is to have independent ways to verify the result.
Therefore, formalization of the architecture and automatic verification become no less important than the capabilities of the model itself.
Can an AI design a processor on its own
Technically, AI is already capable of creating individual processor elements and even offering a rather complex architecture. But there is still a big difference between generating a project and creating a reliable system.
It is necessary to define requirements, choose trade-offs, understand the physical limitations of the implementation, and test the vast number of interactions between components. In addition, someone has to decide which properties of the system are generally considered correct.
Today, this responsibility cannot simply be transferred to a language model.
Therefore, we consider AI primarily as an amplifier of an engineer's work. He can analyze materials faster, look for connections, suggest options, write part of the code and help find contradictions.
But architectural solutions must remain explicit, and important properties must be verifiable regardless of AI responses.
What can this approach lead to?
The most interesting result for us is not a processor that was entirely written by AI. A development system in which humans and AI work with the same explicit architecture model is much more useful.
A person defines goals and makes key decisions. AI helps to analyze the consequences, maintain consistency of documents and code, find possible errors, and perform some of the routine work. Formal verification independently controls properties that can be expressed accurately enough.
If such a scheme works, it is applicable not only to processors. Similarly, other complex technical systems can be designed, where it is already difficult to keep a large number of related solutions only in the documentation and memory of developers.
For us, Memora8 is a way to test this approach on a fairly complex real-world task. And the main question here is not whether AI can replace an engineer, but how much more complex systems an engineer can create if AI gets access not only to the code, but also to the explicit rules of the entire system.
Искусственный интеллект уже умеет писать код, объяснять ошибки и предлагать варианты решения задачи. Но проектирование процессора значительно сложнее обычного программирования: здесь нужно одновременно учитывать архитектуру, память, взаимодействие устройств, временные зависимости и множество правил, нарушение которых может проявиться далеко от места ошибки.
Поэтому интереснее поставить вопрос не о том, способен ли ИИ самостоятельно создать процессор. Гораздо практичнее понять, в каких частях разработки он уже может быть полезен инженеру и что для этого должно измениться в самом процессе проектирования.
Мы исследуем этот вопрос при разработке процессора Memora8.
Недостаточно просто показать ИИ исходный код
Современные модели довольно хорошо работают с отдельными фрагментами программ. Можно передать функцию, модуль или сообщение об ошибке и попросить найти проблему или предложить исправление.
При разработке процессора этого быстро становится недостаточно. Значение одного модуля часто определяется правилами, которые находятся совсем в другом месте проекта.
Например, код обращения к памяти может выглядеть совершенно правильно сам по себе. Но чтобы понять его корректность, нужно знать, кто имеет право владеть определённой областью памяти, когда это право передаётся и какие действия разрешены до и после передачи.
Если ИИ видит только файл с исходным кодом, он этих правил может не знать. В результате он способен предложить технически правильное изменение, которое нарушает архитектуру всей системы.
Поэтому для серьёзной инженерной работы ИИ нужен не только код, но и контекст.
Архитектура должна быть описана явно
Часть инженерных знаний обычно существует в голове разработчиков. Почему используется именно такой способ обмена данными, какие состояния разрешены, какие сочетания считаются ошибочными и какие решения уже пробовали раньше — далеко не всё это записано в исходном коде.
Для человека такая ситуация привычна. Разработчик долго работает над системой и постепенно запоминает большое количество негласных правил.
Для ИИ это серьёзная проблема. Новый разговор практически всегда начинается с необходимости снова передать ему нужную часть контекста.
При разработке Memora8 мы стараемся делать архитектурные правила явными: отдельно описывать модель памяти, устройства, команды, состояния процессора и связи между компонентами. Чем больше таких решений выражено в проверяемой форме, тем меньше приходится надеяться на то, что ИИ правильно догадается о замысле разработчика.
Это полезно не только ИИ. Явные правила делают систему понятнее и для самого человека.
ИИ хорошо подходит для поиска противоречий
Одна из полезных задач — сравнение различных частей проекта. В большой системе одно правило может быть описано в архитектурном документе, другое — в исходном коде, а третье — в тестах.
По мере развития проекта эти представления могут начать расходиться. Спецификация говорит одно, реализация делает другое, а старый тест продолжает проверять уже устаревшее поведение.
ИИ способен быстро сопоставлять такие материалы и обращать внимание на возможные противоречия. Он может заметить, что новое решение о работе памяти не соответствует старому описанию команды или что два документа по-разному определяют состояние одного устройства.
Но здесь важно различать обнаружение проблемы и принятие решения. ИИ может показать противоречие, но определить правильный вариант должен разработчик или формальная проверка.
От генерации кода к работе с правилами
Самый очевидный способ использования ИИ — попросить его написать часть кода. При разработке аппаратуры это тоже возможно: модель может предложить реализацию небольшого блока, тест или вспомогательную программу.
Однако потенциально более интересная область находится выше уровня отдельных строк кода. ИИ можно использовать для работы с самой структурой решения.
Например, при изменении архитектуры памяти можно попросить определить, какие команды, устройства и проверки затронет новое правило. При добавлении состояния процессора — найти места, где существующая логика предполагает старый набор состояний.
Это уже не обычное дополнение к редактору кода. ИИ начинает работать с проектом как с системой связанных решений.
Для этого, однако, сами связи между решениями должны быть доступны машине.
Формальная проверка даёт ИИ границы
У ИИ есть хорошо известная проблема: убедительно выглядящий ответ не обязательно является правильным. В обычном тексте это неприятно, а при разработке процессора ошибка может привести к неверной архитектуре или аппаратной реализации.
Поэтому особенно интересна связка ИИ с формальной проверкой.
ИИ может предложить реализацию или изменение, но окончательный ответ о выполнении некоторых правил должна давать не сама языковая модель. Эти свойства можно проверить отдельным инструментом.
Например, ИИ предлагает изменить механизм передачи владения памятью. После этого SJV может проверить, осталось ли истинным правило, согласно которому одна область памяти не должна одновременно принадлежать двум процессорам.
Получается разделение обязанностей. ИИ помогает искать решения, а формальная система проверяет те их свойства, которые можно строго сформулировать.
Такой подход кажется значительно надёжнее, чем попытка просто доверять ответам модели.
ИИ может помогать и при самой проверке
Формальное описание тоже создаёт человек, поэтому здесь остаётся много ручной работы. Нужно понять, какое свойство действительно важно, как его сформулировать и какие границы модели выбрать.
ИИ может помогать и на этом этапе. Например, по архитектурному описанию он способен предложить список свойств, которые стоит проверить: допустимые состояния, правила владения ресурсами, обязательные действия после команды или запрещённые сочетания условий.
Такие предложения нельзя автоматически считать правильными. Но они полезны как дополнительный взгляд на систему и могут помочь заметить правило, которое разработчик ещё не записал.
Особенно интересна возможность сопоставлять спецификацию с уже существующими проверками и находить требования, для которых пока нет формального свойства.
История решений тоже важна
При длительной разработке полезно знать не только текущее устройство системы, но и причины принятых решений. Иногда вариант уже рассматривался несколько месяцев назад и был отвергнут из-за проблемы, которая сегодня не очевидна.
Человек может забыть такую историю. ИИ тем более не сможет её учитывать, если она нигде не записана.
Поэтому вместе с кодом и спецификациями важно сохранять архитектурные решения, обнаруженные ограничения и результаты экспериментов. Тогда при новом изменении ИИ может учитывать не только текущее состояние системы, но и предыдущий опыт проекта.
В таком режиме он становится не просто генератором кода, а инструментом работы с накопленным инженерным знанием.
Что происходит в Memora8
Memora8 удобен для таких экспериментов именно потому, что проект охватывает несколько уровней одновременно. Есть архитектурные правила, описание команд, модель памяти, реализация аппаратных блоков, программы для моделирования и формальная проверка.
ИИ можно использовать для перехода между этими уровнями. Например, изменение архитектурного правила можно проследить до конкретных модулей реализации и тестов, а найденную ошибку — обратно до правила, которое нужно уточнить.
При этом мы стараемся не строить процесс вокруг идеи, что ИИ всегда прав. Напротив, чем больше он участвует в разработке, тем важнее иметь независимые способы проверки результата.
Поэтому формализация архитектуры и автоматическая проверка становятся не менее важными, чем сами возможности модели.
Может ли ИИ спроектировать процессор самостоятельно
Технически ИИ уже способен создать отдельные элементы процессора и даже предложить достаточно сложную архитектуру. Но между генерацией проекта и созданием надёжной системы остаётся большая разница.
Необходимо определить требования, выбрать компромиссы, понимать физические ограничения реализации и проверить огромное количество взаимодействий между компонентами. Кроме того, кто-то должен решить, какие свойства системы вообще считаются правильными.
Сегодня эту ответственность нельзя просто передать языковой модели.
Поэтому мы рассматриваем ИИ прежде всего как усилитель работы инженера. Он может быстрее анализировать материалы, искать связи, предлагать варианты, писать часть кода и помогать находить противоречия.
Но архитектурные решения должны оставаться явными, а важные свойства — проверяемыми независимо от ответов ИИ.
К чему может привести такой подход
Наиболее интересный результат для нас — не процессор, который целиком написал ИИ. Гораздо полезнее система разработки, в которой человек и ИИ работают с одной явной моделью архитектуры.
Человек определяет цели и принимает ключевые решения. ИИ помогает анализировать последствия, поддерживать согласованность документов и кода, находить возможные ошибки и выполнять часть рутинной работы. Формальная проверка независимо контролирует свойства, которые можно выразить достаточно точно.
Если такая схема работает, она применима далеко не только к процессорам. Подобным образом можно проектировать другие сложные технические системы, где большое количество связанных решений уже трудно удерживать только в документации и памяти разработчиков.
Memora8 для нас является способом проверить этот подход на достаточно сложной реальной задаче. И главный вопрос здесь не в том, сможет ли ИИ заменить инженера, а в том, насколько более сложные системы инженер сможет создавать, если ИИ получит доступ не только к коду, но и к явным правилам всей системы.
Share
