Когда-то давным давно я помню спорил со своим знакомым о «правильных» методах программирования. Суть спора сводилась к следующему. Я говорил, что если задача четко поставлена, то имеет смысл реализовывать ее по возможности с нуля. В этом случае мы можем абсолютно свободно ориентироваться в своем проекте, в исходниках. Конечно, есть риски наделать ошибок, изобретая велосипед. Но и плюсы очевидны – велосипед-то наш: хочешь, можешь руль повыше сделать, хочешь сиденье поудобней. Напротив, мой знакомый говорил: «Прежде чем кодить, нужно поискать готовое решение. Наверняка кто-то уже занимался похожей задачей и есть готовые библиотеки и модули, нужно только использовать их». Ну что тут можно сказать. При таком подходе, если нужная библиотека найдена, наверняка придется изучать документацию по ее применению, изучать ее интерфейс. Это все изучение стоит времени (хотя может оно этого стоит?). Конечно и плюсы есть – скорее всего, найденное решение, если оно по настоящему OpenSource, уже многократно проверено многими людьми, возможные ошибки уже исправлены или будут исправлены в скором времени. Опять же – есть надежда, что готовый продукт будет получен раньше.
Вряд ли в споре рождается истина, но скорее всего она где-то посередине. В моей практике есть и положительные и отрицательные примеры для обоих подходов. Вот, например, наболело, прямо сейчас приходится заниматься проектом в котором автор кажется смешал все возможные стили и методы: в проекте используются библиотеки C++ Boost, Google Protobuf, OpenSSL, Zlib, QT, языки Python и Java, C и C++, make, qmake, cmake и много еще чего. Получился такой зоопарк, что просто волосы дыбом встают. Мало кто понимает как это все вместе работает, но, как обычно, переделывать уже нет ни времени ни желания. Вроде бы и исходники все OpenSource, но разбираться действительно не легко. Общий объем исходников составляет сотни мегабайт. Это был пример Software проекта. Но применимы ли эти рассуждения к аппаратным проектам? Конечно да. Hardware так же бывает OpenSource. Тут так же можно либо писать все с нуля, либо искать, находить, покупать, готовые модули.
Один из самых известных ресурсов OpenSource Hardware – это проект OpenCores.org
Теперь уже я вам советую: «Прежде чем кодить проект Verilog или VHDL, поищите похожее решение на OpenCores». Не обязательно его именно брать и внедрять. Но хотя бы познакомиться с существующими решениями обязательно нужно.
Попробуем посмотреть, что можно здесь найти. Например, посмотрим раздел «Процессоры». Я только что насчитал 136(!) проектов реализующих разные процессоры: 6502, AVR, 68hc05, 68hc08, 8051, 8080, MicroRisc, myBlaze, Amber ARM, OpenRisc 1000, OpenRisc 2000, Z80! Тут даже есть Reduced AVR Core For CPLD – это же наш проект с сайта marsohod.org! Да-да, вы и сами можете поделиться со всем миром своими собственными наработками – регистрируетесь на сайте и выкладываете свои аппаратные проекты на радость людям и во имя прогресса человечества.
В других разделах OpenCores так же есть много чего интересного. Например, раздел Crypto Core предлагает ядра для шифровальных алгоритмов DES, AES, IDEA, RSA, GOST, RC4, RC6, вычислители хэш функций SHA, MD5. И прочее и прочее.
Кажется, на сайте OpenCores есть все – и процессоры и контроллеры памяти, ввода/вывода, видеоконтроллеры, jpeg и видео кодеки. Есть готовые системы на кристалле SoC (System-On-Chip).
Что-то здесь написано на Verilog HDL, что-то на VHDL. Конечно, у проектов разная степень готовности и надежности. Проекты как правило пишутся для какой-то отладочной платы с FPGA Xilinx или Altera. В любом случае – opencores.org – это действительно ценный ресурс для разработчика аппаратуры с использованием ПЛИС.
Что дальше?
Поскольку мы выпустили в жизнь новую плату Марсоход2, то я подумал, что хорошо бы попробовать реализовать на ней относительно простую систему на кристалле. Я предлагаю сейчас по возможности брать для нашей системы компоненты с opencores. Работы будет много, и готовые компоненты надеюсь помогут нам. Даже если взять готовую систему на кристалле с сайта придется многое адаптировать для нашей конкретной платы Марсоход2.
Ну, я тут подумал и решил, нашей отправной точкой будет OpenCores проект Amber ARM.
Во-первых, это все таки ARM – наиболее популярный процессор для встраиваемых систем. Во-вторых, ну... пожалуй хватит и того, что это все таки ARM.
Надеюсь скоро мы увидим, как это все работает.
Подробнее...