Pull to refresh

Comments 18

Как это все до боли знакомо. В универе диплом, когда писал, почти год на асеме процессор программировал. Прям настольгия по тем временам.
Правильно я понимаю, что всё заработало на 100 МГц? Неплохой результат для 3-го циклона.
У модуля самого верхнего уровня SOC AMBER есть входной сигнал тактовой частоты 100Мгц, вход и выход последовательного порта TX/RX, а так же сигналы к микросхеме памяти SDRAM.

А как-же остальная периферия? Те же прерывания?
сейчас процессор работает на частоте 40Мгц, это не много, но Quartus говорит fmax проекта около 90Мгц. Я бы и поднял частоту, но сейчас проблема в том, что контроллер последовательного порта синхронизируется от той же частоты. Поднять частоту системы — сразу поднимется скорость передачи через ком порт и не смогу использовать на компьютере стандартные программы терминала с нестандартной скоростью приема.
Нужно переделать модуль приемопередатчика. Тогда можно поднимать частоту процессора.

В самой системе AMBER есть модуль таймера и контроллера прерываний. На контроллер прерываний идет всего два источника прерываний — собственно таймер и от последовательного порта. Внешних сигналов прерываний пока не использовал.

Так что периферия пока минимальная.
Если бы я что-то понимал в ПЛИС я бы забацал для начала 8086 проц, ибо система команд привычней. Потом бы вообще можно было в теории сделать небольшую хоум-мейд мать и гонять на ней ДОС как в стародавние времена )

Хотя все дело омрачает перефирия будь она не ладна, а именно контролер клавиатуры, таймер, FDD-контроллер, видео… Все это тоже походу нужно будет эмулировать
Все же у 86 жуткая система команд, легче свою СК придумать.
Жуткая в плане разбора или, если угодно, дизассемблирования, но довольно оптимальная с точки зрения размера опкодов, соответственно и размера получаемых программ в целом.
В этом плане хороша система команд PDP11. Если бы эту систему команд отобразить в 32-битах, то могла бы получиться весьма интересная архитектура.
Посмотрите picoblaze, и его клоны, для понимая структуры работы процессора вполне наглядную документацию имеет (KCPSM).
это конечно не арм, но по типу его реально создать свой процессор за несколько недель, имея на руках спек по коммандам конечно.
а вообще есть сапр которые позволяет создавать свои процессоры и компиляторы к ним. CoWare Processor Designer, кажется, но вроде их Synopsys купил…
PS я тоже мечтаю свой проц написать, компилятор и портировать ядро хотя бы RTOS какой нито… но уже понял что это не подъемная задача, максимум это что то типа Picoblaz'а.
Шлите резюме в Интел, там вам предложат закопаться в железо по такие помидоры, что мало не покажется :)) Естественно, если этим действительно хочется заниматься по-взрослому.
Спасибо за статью! Вот если бы на пару дней раньше, то могли бы встретиться и поговорить — в прошлую пятницу я и мой компаньон были в Таганроге и общались со специалистами как раз на тему процессоров (предлагали вот такое расширение — l4os.ru/download/L4_Hard_20130119.pdf).

Раз уж мечтаете сделать свой процессор, то пожалуйста пожалуйста пожалуйста, примите во внимание мечту других разработчиков. Мы сами не потянем разработку процессора, но знаем как оптимально использовать это расширение. Если Вас заинтересовало наше расширение — будем рады сотрудничеству.

хм… я правильно понял, что речь идет об аппаратной реализации планировщика задач для ОС?
Не совсем. Описан базовый плагировщик, на основе которого можно строить различные методы планирования. Основная суть документа — обмен синхронными сообщениями между задачми. В данном случае планировщик выполняет роль функционального устройства для обмена синхронными сообщениями. Т.е. понятие «планировщик» трактуется более широко, чем в общепринятом смысле.

На текущий момент удалось формализовать приблизительно половину спецификации L4 X2 — не описан Memory Management Unit. Так же не решён вопрос вытеснения блока регистров задачи в оперативную память и обратно. Тем не менее, в текущем виде спецификация может быть использована для разработки микроконтроллеров.

Чтобы не ходить вокруг да около — вот собственно спецификация L2-X2, на основе которой мы предлагаем реализовать аппаратное микроядро — www.l4ka.org/l4ka/l4-x2-r7.pdf
мне казалось, что переключения контекста задач не такая уж частая и затратная процедура и программные реализации вполне эффективны. разве нет?

А как Вы видите свое аппаратное микроядро? Для каких конкретно применений? Вы хотите выпускать свою микросхему? Или может Вы хотите, например, сделать свою PCIe плату, реализующую Ваш алгоритм для PC и заменить программный sheduler в ядре Linux? Вот практическую сторону вопроса не могу уловить.
Переключение контекста слишком многогранное понятие. Например, можно ли считать переключением контекста вход прикладной задачи в ядро системы? Например, posix функция write, когда данные передаются ядру, это переключение контекста или нет?

В случае микроядра L4 взаимодействие любых задач происходит через обмен сообщениями. Сообщения поставлены во главу угла — системные вызовы и ответы на них, прерывания от устройств и исключения процессора — всё это сообщения. На этой базе строится абсолютно всё. Иногда это можно представить в терминах субъектного программирования — любой программный комплекс представляется в виде субъектов, которые обмениваются сообщениями.

> А как Вы видите свое аппаратное микроядро?

С точки зрения программиста — расширение системы команд какого-либо уже существующего процессора. Предоставленная выше спецификация вводит три новые команды:

  • захват буфера сообщения
  • команда обмена сообщениями
  • освобождение буфера сообщений


Организация работы с буфером сообщений на плечах разработчиков процессора. Если позоволяет система команд, то можно расширить количество РОН, дополнив их регистрами сообщений. Или же ввести команды для работы с регистрами сообщений.

> Для каких конкретно применений?

Планов громадьё, но в данном виде спецификация подходит лишь для микроконтроллеров. Как я уже говорил, чтобы на базе аппаратного микроядра сделать десктопную систему, понадобится решить две задачи — расширенный MMU для работы с универсальными виртуальными страницами и вытеснение задач из регистрового файла процессора в оперативную память. Таким образом конкретная область применения — встраиваемые системы.

> Или может Вы хотите, например, сделать свою PCIe плату, реализующую Ваш алгоритм для PC и заменить программный sheduler в ядре Linux?

Нет нет. В мире есть несколько проектов и команд разработчиков, пытающихся соединить Linux и микроядро L4. Даже с некотором успехом. Однако, я уверен что это не самый лучший путь — слишком разная архитектура у Linux и у микроядра. Таким образом добавляется лишь новый слой, который особых преимущест не даёт.

У меня ушло чуть более десяти лет на разработку операционной системы поверх микроядра L4 Pistachio. Собственно говоря, именно эта разработка и подтолкнула к идее, реализовать микроядро аппаратно — сначала было только желание, но несколько случайных обстоятельств подтолкнули к пониманию, как это можно реализовать в железе.

Если Вы заинтересовались — с радостью поддержу беседу и расскажу о секретах микроядра L4.

ну вот скажем я реализую аппаратный обмен сообщениями в ПЛИС (например, как дополнение к той же системе Amber) — это то, что Вы хотите или нет?
Я просто пытаюсь понять коммерческий смысл в этой затее.
ну вот скажем я реализую аппаратный обмен сообщениями в ПЛИС (например, как дополнение к той же системе Amber) — это то, что Вы хотите или нет?


Возможно это то, что мы хотим. Без подробностей об этом сложно судить.

Для начала я бы предложил «уровнять в правах» регистры Fast Interrupt и регистры общего назначения. Т.е. чуть раньше сделать то, к чему рано или поздно прийдут все остальные.

Я просто пытаюсь понять коммерческий смысл в этой затее.

Запрыгнуть на поезд пораньше, чтобы занять лучшие места. :)
Only those users with full accounts are able to leave comments. Log in, please.