alman

Здравствуйте, уважаемые коллеги! У меня есть некоторые обновления - http://everest.l4os.ru/what_about_pipeline/ И да, если ничто не помешает, вскоре появится ещё одна подобная статья, в которой описан потактовый разбор более сложного кода.

Конкуренция растёт. :) А я предлагаю 32-разрядный микропроцессор. Точнее, архитектуру. Вот, намедни сделал карту системы команд. Разумеется, по простоте и компактности он не может конкурировать с 8-ми битными микроконтроллерами, но у него есть другие преимущества - отличная расширяемость и высокая плотность кода. Желтым помечены неназначенные коды операций. Когда (и если) заработает встроенная многозадачность, то проект будет достоин отдельной темы в этом подфоруме. А вот так может выглядеть программа на ассемблере для этого процессора Знаю проекты, которые продвинулись значительно дальше моего, но с точки зрения возможностей архитектуры я готов пободаться.:)

Вот такое сообщение при старте: "Your maintenance subscription for the Quartus II software expires in 10 days..." Выбор кнопки "Renew software" открывает следующую страницу: http://www.altera.com/buy/software/buy-software.html Вопрос - что меня ожидает через 10 дней? Он реально перестанет работать? Или это тонкий намёк на необходимость купить платную поддержку. Смысл в том, что как продлить WEB Edition - я не нашёл. Помогите, пожалуйста.

Это должно получиться в результате, но пока ещё работа далека от завершения. В текущем состоянии устройство представляет из себя маленький и довольно простой 32-битный микропроцессор. Единственное, что может оттолкнуть от его использования - отсутствие прерываний. При желании прерывания можно реализовать сверху, обернув ядро, но в конечном устройстве прерывания будут замещены сообщениями, поэтому не вижу особого смысла разрабатывать то, от чего потом придётся откзаться. Посмотрите вот это (кликабельно): Задачи для души, по моему скромному мнению, это самый лучший стимул для разработки. Я использовал мегафункцию ROM для размещения интерактивного монитора и загрузчика по протоколу X-modem непосредственно в ПЛИС. В принципе, в микрокод можно поместить довольно сложные программы. Ой... Вы имеете в виду как загрузить из EPCS пользовательскую программу в процессор и что NiosII умеет это делать. Да, я тоже хотел бы это знать, как можно "программно" прочитать регион памяти из EPCS, в которой зашита прошивка устройства. Некоторая информация есть вот здесь .

Вы будете смеяться, но вся вера построена на одном допущении. Предистория такова - в 2003 году был перенсён код самописной файловой системы из консольного тестового проекта MS Visual Studio в задачу, исполняющуюся поверх микроядра L4Ka::Pistachio на архитектуре ia32. С учётом того, что микроядро L4 синхронное, файловая система заблокировала всю систему в момент чтения со stdin (проще говоря - система заблокировалась в ожидании нажатия клавиши на клавиатуре). Самое смешное, что все писатели операционных систем, использующих синхронные микроядра, сталкиваются с этой проблемой и решают её по своему. В результате, почти случайно, было найдено оригинальное решение развязывания синхронных вызовов в асинхронные, которое давало минимальный оверхед по ресурсам. Собственно, многолетняя убеждённость в том, что решение удачное, уникальное и никому пока ещё не пришло в голову - вот эта убеждённость и придаёт силы. Когда работа ведётся много лет на энтузиазме и вере, когда в работу вкладываюся собственные средства, когда нет кредиторов и хозяев, диктующих что и как делать, то обанкротится сложно. Сильно рисковать желания нет, пусть со стороны это выглядит как риск, а изнутри это смотрится как целенаправленная многолетняя работа. Кстати, собственно почему пришла идея сделать свой микропроцессор? Такие мысли были давно, но желание превратилось в намерение после переноса операционной системы "Хамелеон" с x86-32 на x86-64. В какой-то момент перенести удалось, но само микроядро L4-Pistachio работает нестабильно на 64-битах. Это очень нехорошее чувство, когда то, на что опирается ваш код, работает нестабильно, а трудозатраты на исправление чужого кода сопоставимы с трудозатратами при разработке с нуля. В общем, тут сам Бог велел забыть о "чужих" проблемах и недоработках, а сделать то, что нужно самому. Не то, чтобы в Калифорнии никто не делал аппаратных планировщиков - такие исследования проводились разными командами, но вот чтобы кто-то реализовал аппаратно синхронное микроядро (microkernel) - такого ещё не сделал никто. Во всяком случае не сделал нечто, опирающееся на идеи из вот этой спецификации - http://www.l4ka.org/l4ka/l4-x2-r7.pdf Простите за многословность. Я теряю самообладаение когда речь идёт об микроядре L4.

Если согласны не передавать исходный код ядра третьим лицам, то могу передать архив с проектом, например, расшарив его через Google диск. Формат QAR, помещённый в запароленный ZIP будет удобен? Пароль сообщу личным сообщением. Прошу понять меня правильно - сам по себе процессор ценности почти не имеет - он создан для реализации аппаратного microkernel совместимого с L4. Таким образом "просто процессор" готов раздать всем желающим, на условиях нераспространения его исходного кода. А вот что касается микроядра, то его пока нет и если оно будет реализовано, то будет коммерческим. p.s. Откровенно, Ваш вопрос выбил меня из колеи. Уже как-то привык, что никакого отклика, а как получил первый вопрос, то лишился дара речи. p.p.s. Прошивку для платы Марсоход2 можно скачать здесь - форум "Марсохода".

В соседней теме кипят нешуточные страсти и люди (язык не поворачивается сказать "народ") активно делятся идеями и наработками. Между тем, кто-то продолжает "тянуть лямку" и не жалея сил продолжает готовить процессор для встраивания в него аппаратного микроядра планировщика. Сегодня расскажу ещё об одном устройстве, выполнящиюм функции арбитра шины. Сейчас оно выглядит как-то вот так: Как видно из картинки, устройство почти полностью симметрично показанному выше ядру, за исключением добавленных ног - serial_rx, serial_tx. Внутри этого устройства находится UART, ПЗУ с микрокодом и два региона ОЗУ. ПЗУ и ОЗУ сгенерированы с помощью мегафункций Altera. Один блок ОЗУ зарезервирован для регистров собщений, второй блок ОЗУ - кэш инструкций. Но это в будущем, а в настоящий момент эти два региона ОЗУ задействованы для тестирования отладки. Выглядит это так. После старта в подключенном терминале появляется следующее меню: ┌────────────────────────> Welcome to Everest core <───────────────────────────┐ │ 1 - Load binary file via X-modem protocol │ │ 2 - Run previously loaded binary file │ │ 3 - Show RAM (0x100000-0x100140) │ │ 4 - Test of message registers │ │ 5 - Show previously loaded ANSI picture │ │ 6 - Show built-in ANSI pic #1 │ │ 7 - Show built-in ANSI pic #2 │ └──────────────────────────────────────────────────────────────────────────────┘ А дальше всё тривиально - после нажатия клавиши 1, устройство ожидает принятия файла по протоколу X-modem Нажатие клавиши 2 в терминале запустит загруженный файл. И т.д. Устройство постепенно обрастает библиотечными функциями. Последние из реализованных - _mul - умножение двух целых числел, _div - деление целых числел, _print_dec - вывод числа в десятичной форме в терминал.

Я не согласен с тем, что процессоры в ПЛИС делаются только под конкретную задачу. Процессоры делают все, кому не лень и никто не может запретить кому-то сделать универсальный процессор. Вопрос, будут ли им пользоваться - это уже другой вопрос. ARM - это в некотором роде фетиш. Ярые сторонники Intel его до сих пор за процессор не считают. Таки что будем сравнивать? Поскольку пока никто не предложил задачу, то в качестве одной из задач предлагаю сравнить реализацию протокола X-modem. Конкретно - ресивер, использующий протокол X-modem. B)

Смысл соревнования? Хотя бы в том, что победитель(победители) имеет шанс - его разработкой могут заинтересоваться сторонние разработчики. Это нормально. Когда "велосипедов" много, начинается конкуренция и естественный отбор. Как в природе. С этим не спорю. Ну вот, к примеру, SoC для платы Марсоход2 - автор даже портировал компилятор Си на свой процессор. Он и на electronix.ru в соответствующей теме рекламировал свою разработку - а в ответ получил ти-ши-ну. А это реально бесит - игнор хуже критики. Если кто-то собирается делать свой процессор, предварительно не потратив хотя бы месяц на изучение проектов с opencores.org, то почти наверняка его ждёт неудача. Кстати, адептов устройств с opencores.org тоже надо пригласить поучаствовать в соревновании.

Не претендую на шибко "умного человека", но Вы можете увидеть мой ответ в теме "Свои процессоры". А... так вот в чём дело. Что ж, давайте устроим соревнования. А именно - соберёмся все вместе, придумаем несколько задач и пусть каждый решит задачу на своём устройстве. И сравним результаты по разным параметрам - быстродействию, компактности ядра, эффективности кода. Можно даже кинуть клич на нескольких форумах - может быть народ подтянется поучаствовать.

Такое живое обсуждение процессоров в этой теме :) Между тем, процессор "Everest" научился читать из последовательного порта. И кое-чему ещё, о чём можно узнать перейдя по ссылке. Для этого достаточно кликнуть на картинку.

Вы вот смеётесь, но у меня была аналогичная проблема. С паяльником очень сложные отношения, поэтому решение в виде использования ноги отпало сразу. Проблему решил через мультиплексирование последовательного порта - по некоторым событиям переключаю его между модулями. К теме вопроса это отношения не имеет, просто хочу обрабтить внимание, что существуют люди, которым брать паяльник в руки противопоказано.

Разреште поделиться небольшим успехом - процессор научился программно писать в последовательный порт. Подробности по клику:

Жаль, не могу причислить себя к знающим, но мне довольно легко удалось стартануть с платы Марсоход2 - http://marsohod.org/ Можно заказать устройство почтой, но за скорость и качество доставки ничего сказать не могу - ездил за платой сам. Устройство весьма увлекательное и хорошо подходит для изучения основ HDL.

Хотя бы сто тысяч пикселей. К примеру, двенадцатый Квартус умеет экспортировать нетлисты в широкую картинку. А вот тринадатый, похоже, разбивает на листы. Веб браузером.

Попробовал. Оказывается есть некоторые тонкости - окно Wave должно быть активным и встроенным в главное окно ModelSim. Однако, результат совсем не порадовал - такую же картинку (и даже лучше) можно получить сделав копию экрана. А мне бы хотелось на выходе иметь длииииинную широкую картинку, на которой бы был изображен весь процесс моделирования, а не только видимую на экране область.

Простите, если вопрос не в тему, но вот в GTKView есть возможность экспортировать Wave в картинку формата PNG. Не могу найти как экспортировать Wave в картинку. Кстати, а как правильно по-русски назвать Wave? Диаграмма сигналов? К сожалению я не нашёл как экспортировать картинку с сигналами в ModelSim Starter Edition. Вызвано ли это ограничениями весрии Starter Edition, или плоохо искал, или такой возможности нет? Если такая возможность есть, то каковы ограничения на ширину картинки?

Позвольте и мне показать "микропроцессор". Это 32-х битное ядро, которое выглядит так: Ядро использует собственную систему команд, нескромно названную "Эверест": 16 регистров общего назначения позиционно независимый код большой запас для расширения системы команд Частичное описание системы команд: http://everest.l4os.ru/core/ Несколько слов об ассемблере: http://everest.l4os.ru/assembler/ Пример пошаговой отладки ядра: http://everest.l4os.ru/test_of_strlen/ Выполнение команд занимает 2-3 клока, не считая тактов ожидания внешних устройств. Ядро проверено на плате "Марсоход2" и показало возможность работы на 100МГц. В перспективе возможна реалиазция конвейерного исполнения команд. В более далёкой перспективе - одновременное выполнение нескольких команд за такт. Причём, параллельное выполнение некоторых команд можно достичь с небольшими издержками за счёт коротких команд и 40-битной входной шины. Т.е. в перспективе ожидается параллельное выполнение нескольких команд, если они не взаимозависимы и целиком поместились на входную 40-битную шину. Впрочем, это отдалённые перспективы, потому что... Процессор создаётся с надеждой на то, что в скором будущем он обзаведётся аппаратным планировщиком и расширенным MMU с поддержкой универсальных страниц виртуальной памяти. В результате процессор станет первым в мире микропроцессором с аппаратно реализованным микроядром L4. Если успеет... :) Собственно, ради реализации аппаратного микроядра и был затеян этот проект. Процессор создаётся под уже существующую микроядерную операционную систему (точнее - рабочий прототип ОС).

Спасибоо всем принявшим участие за полезное и интересное обсуждение.

Кстати, а чем это будет отличаться от always @(clk) if(clk) begin ... end else begin ... end

module reg_ram ( input clk, input [3:0] address_a, input [3:0] address_b, input [31:0] data_a, input wren_a, output reg [31:0] q_a, output reg [31:0] q_b); reg [31:0] ram[15:0]; always @ (posedge clk) begin q_a = ram[address_a]; q_b = ram[address_b]; if(wren_a) begin ram[address_a] <= data_a; $write(" REG: SET %x A[%d] = %x B[%d] = %x\n", data_a, address_a, q_a, address_b, q_b ); end end endmodule Простите, просто я неправильно выразился. Конечный автомат уровнем выше - в модуле который использует этот регистровый файл. я экспериментировал разными способами, в некоторых экспериментах использовал клок, но тогда ещё не знал о проблемах возможных при асинхронном дизайне. В одной из версий использовал такую конструкцию: always @ (clk) begin if(wren_a) begin ram[address_a] <= data_a; $write(" REG: SET %x A[%d] = %x B[%d] = %x\n", data_a, address_a, q_a, address_b, q_b ); end end assign q_a = ram[address_a]; assign q_b = ram[address_b]; Но это не решило проблему. Правильно ли я понимаю, что симулятору можно подсунуть sof файл? А где бы почитать о том, как использовать нетлисты при симуляции?

Stewart Little, огромное спасибо! Это действительно помогло. Но при этом потребовалось ввести дополнительное состояние в конечный автомат. В результате некоторые операции "потяжелели" на один такт. С этим очень трудно смириться. Неужели только конвейер поможет решить проблему "лишних" тактов? И ещё несколько вопросов. Почему симуляторы "правильно" моделируют поведение асинхронных модулей? Если асинхронный модуль описать схематикой, то можно ли тогда заставить его работать в ПЛИС асинхронно без вышеописанных проблем?

Не получается. :( Это результат симуляции в ModelSim (полноразмерная картиинка по клику) А это результат работы схемы на FPGA Проблемное место пометил красно чертой - на первом рисунке ему соответствует желтая вертикальная линия. В случае симуляции на шине o_data выставлено значение 32'h77777777 и это правильное значение. При тесте в ПЛИС в этом месте на шине o_data выставлено значение 32'h12345678, которое использовалось несколькими тактами ранее. Данные на шину o_data выбираются из такого устройства: module reg_ram ( input clk, input [3:0] address_a, input [3:0] address_b, input [31:0] data_a, input wren_a, output reg [31:0] q_a, output reg [31:0] q_b); reg [31:0] ram[15:0]; always @ (address_a or wren_a) q_a = ram[address_a]; always @ (address_b or wren_a) q_b = ram[address_b]; always @ (wren_a or address_a or data_a) begin if(wren_a) begin ram[address_a] <= data_a; $write(" REG: SET %x A[%d] = %x B[%d] = %x\n", data_a, address_a, q_a, address_b, q_b ); end end endmodule При этом Квартус генерирует множество замечаний на каждый используемый бит массива ram: В чём же может быть дело? Больше всего бесит факт, что при моделировании схемы ошибок нет. Имеет ли смысл опубликовать здесь полный код в надежде, что кто-нибудь "ткнёт пальцем" в ошибку?

Внимательно читаю обсуждение. Что касается кода, то помещать фрагмент особого смысла нет, поскольку "глючное" место находится внутри конечного автомата - если вырезать фрагмент, то понятно ничего не будет. Пока пробую решить проблему сам - всё же хотелось создать новую тему на форуме с работающим решением, но если не осилю, то выложу ошибочный код в этой теме. Кстати, поставил ModelSim Starter Edition - эта штука оказалась посильней чем Icarus Verilog. С помощью ModelSim удалось найти и исправить несколько ошибок, в результате чего схема заработала и в нём. При тесте в ПЛИС - проблема не решилась. Осталось подозрение на временные характеристики входных сигналов - в "железке" присутствует асинхронное воздействие извне, а в симуляторе сигналы генерирую синхронно. Думаю переписать тестбенч таким образом, чтобы асинхронно устанавливать входные сигналы, т.е. максимально близко к поведению в железе. Спасибо всем принявшим участие в обсуждение. Узнал много нового.

Уважаемые коллеги, помогите разобраться в причинах разного поведения при симуляции в Icarus Verilog и при работе в ПЛИС. В симуляторе всё работает как и задумывалось - в логе всё красиво и в GTKWave все сигналы соответствуют задуманному. Всё меняется при переносе проекта в ПЛИС - в какой-то момент сигналы на одной из выходных шин "портятся". Выходной порт объявлен как регистр. Возможно стОит обратить внимание, не пишут ли в него друге модули? Проостите, если вопрос глупый, но ответа в FAQ и на первых 5 страницах я не нашел. Думаю, что причины различного поведения в симуляторе и в "железе" могут быть разные. В идеале, хотелось бы получить список в виде приоритетов причин, по которым поведение может отличаться. Спасибо. p.s. Использую Quartus II v12.1 Говорят, в тринадцатом Квартусе есть встроенный симулятор?