Средства и методы разработки

[Зачем стековые процессоры в embedded?] Пояснение к топику -> 

https://caxapa.ru/1269363.html

Нет задачи завоевать вселенную, победить Intel Core 13 поколения и даже любой современный ARM, RISC-V.

Есть задача делать умную периферию в мелких плисках.

https://caxapa.ru/1146658.html

https://caxapa.ru/778579.html

Пусть у нас будет 16к кода и 16к ОЗУ. Как показывают материалы по процессору J1

https://caxapa.ru/1269365.html

Это пипец какая сила в варианте стекового процессора. Хватит на полноценный IP стек и даже останется.

Рассмотрим класс задач:

-- встроенное решение с накристальной памятью (борьба с глюками)

-- FPGA для мелкой и средней серии, дубовый ASIC 0.25/0.18 с Mask ROM - массовая серия

-- нет унаследованного кода. Весь код пишется в рамках проекта

-- код пишется маленькой командой 1...5 единомышленников

-- нет задачи сопровождения кода 30 лет. Написали, оттестили на симуляторах, потренировались на юзерах (FPGA), тиснули ASIC, возможно, сделали 2 ревизию, далее серия и "длинная полка" в конце

-- задача достаточно компактная. Условно, IP стек - оценка сверху по сложности. С запасом.

Типовой вариант - коммуникационный контроллер, который решает задачи физического, канального и частично сетевого уровня.

Размер кода и данных в данной ситуации критичнее всего. В простой ПЛИСке будет 1к LE, и продвинутый стековый процессор можно утоптать в 600-700 LE.

Для ASIC экономия площади памяти превыше всего. Меня поражает тупой пиписькомерство создателей ядер, сколь мало их ядро занимает места на кристалле, потому что площадь памяти обоих видов в разы больше ядра. И, кстати, если ядро будет в 2 раза больше, но даст уменьшение памяти в 1.5 раза - это будет очень выгодно.

Поскольку у нас кастомное решение, нет смысла упираться в стандартные 8, 16, 32 бита. Может, целевой задаче 12 или 22 бита отвечают полностью, систему команд можно упростить, чтобы оно только с машинным словом работало. "Остаток" на шинах, кстати, не пропадет. Можно наоборот, сделать 11 битный процессор, к которого все данные будут сразу с Haming (16, 11). Включая регистры. Для части применений это ну очень круто будет.

Кастомность позволяет делать специализированные команды под задачу.

Кодить все это на кастомном асме. С очень хорошей IDE, которая сразу визуализирует все стеки прочее.

Написал стекового кода, тут же прогнал по шагам в симуляторе, оно красиво показало, как и куда движутся данные в стеке с именами переменных.

Что должно быть публичным - это инфраструктура для синтеза такого асма, симулятора и прочего.

Прежде, чем кодить *HDL, мы пишем в максимально удобном для написания виде, что за команды мы придумали, и пишем, что они делают.

Кодирования команд нет - это просто БД, где в каждой строке мнемоника и поля команды.

Это подхватывает симулятор и IDE с визуализатором.

Симулируем, думаем, оптимизируем. В итоге что-то вырисовывается. Вот его уже начинаем кодить в HDL. Желательно стартовав с некого каркаса, например, 16 битного стекового процессора, который умеет делать только 4 операции над операндами.

Вначале пишем тупой HDL код но с продуманной системной структурой. Чтобы интерфейсы между блоками были продуманы, а внутри говнокод, лишь бы работало.

На толстой ПЛИСке верифицируем в железе.

И потом оптимизация для целевой плиски.

Вот как то за этим нам нужны стековые процессоры