BCD на CoolRunner II

http://digitalinvitro.blogspot.ru/2009/06/61.html
http://digitalinvitro.blogspot.ru/2009/06/61_26.html

Глянул я статьи одним глазком. Судя по всему в 256 макроячеек должно влезть BCD АЛУ и весь остальной мини процессор. Аппаратная поддержка BCD это ж шикарная тема, быстродействие должно получиться даже выше, чем у всяких АРМов. У вас уже есть аналог АЛУ МК-61 на Verilog ? По сути ресурсов CoolRunner II c 256 ячейками должно хватить для реализации МК-61. А если поколдовать с внешней памятью, то можно размер программ и количество регистров значительно "раздуть".
Я тут FRAM прикупил 32 килобайта, SRAM быстродействующая мегабайт конкретно для калькуляторного проекта. Слот для SD карты подрубить, можно гигабайтами хранить и менять на ходу. Вот что мне не нравится в МК-161, что там нельзя нормально организовать библиотеки. Я не знаю обязательно ли для этого давать символьные идентификаторы файлам и программам, но недурно было бы сделать такой финт - подключаешь карточку с библиотекой, оно туда лезет и исполняет прямо с карточки (кэширует или медленно шурует по карте), тогда бы прибор был целостным и всё что в него закинешь могло бы друг друга использовать. Метод придуманный в МК-161 плохой, надо явно загружать, выбирать адреса и т.п.

Если CPLD не хватит, есть ещё Spartan 6 c 9 тыс. макро ячеек., там тоже хвастают что мол потребление снизили. В 9 тыщ ячеек и МК-161 небось влезет прямо аппаратно :-)

Дежавю меня самого этак лет с десяток назад, такое же рвение. Лишь бы Ваш энтузиазм не иссяк также быстро как и появился. А то мы на этом форуме я думаю все такие "попаданцы" :) с закупленным MRAM/FRAM и кучей микроконтроллеров.

Смотрите написать BCD сумматор хоть для 8 разрядов - не проблема. Просто от слова совсем, я прям тут могу это сделать :) не сходя с места. Проблема на самом деле не в этом. У msp430 целая команда для сложения BCD есть, это и то меня не спасло. Незадолго до раскопок в микрокоде МК61, я как раз занимался осуществлением такой библиотеки для msp430. Нельзя сказать что я никуда не продвинулся - продвинулся, но только до сложения/вычитания целых BCD чисел. Дойдя до умножения, я начал медленно подбуксовывать, но и тут еще проехал до его частичной реализации.

https://pmk.arbinada.com/ru/node/1300

И это я не перешел к делению. Вот почему главная заслуга СЕМИКО это BCD арифметика. И если Вы хотите обойти Семико по любой характеристики калькулятора то надо начать с библиотеки арифметики. Я думаю как только Арви прейдет к пониманию сложности этой задачи он вернется к МК-161, именно это не дает нам уйти от этого монстрика. Я уж не знаю кто писал эту библиотеку в Семико но ее исходы мы не увидим никогда, да это нам бы и мало чем помогло. Это я к чему, это я к тому что сложение и вычитание целых (сколько угодно разрядных) не вопрос. Как только появится порядок - нужно будет эти числа привести к одному порядку и это тоже не сильно страшно, это можно. Но вот с умножением - у меня, например, получилось такое кол-во тактов, что я начал сомневаться на верном ли я пути. Поэтому главное это запас хода, и хотелось бы что бы он реализовывался не за счет запаса энтузиазма. В этом движении вперед нужно будет все время рыть, бесконечно рыть. Сможете? Тогда начните с самого трудного с алгоритма деления BCD чисел разрядностью 8. Я думаю нужно применять табличный метод деления, тогда его довольно легко будет просунуть в конечный автомат для ПЛИС. Потом - умножение, потому что сумматор для BCD разрядностью 8 считайте, что у вас в кармане.

Как Вы верно заметили CoolRunner не имеет памяти. И это будет проблемой № 1. Следующей проблемой будет программный автомат. Скажем так этот узел можно будет реализовать и на меньшем кол-ве ячеек, но он будет сильно примитивным и с этим нужно будет смириться. Процессор - вероятно это будет стековый механизм ввиду необходимости узкой машинной команды и легко реализуемого аппаратного стека. Кодировать надо будет на ассемблере настолько низкого полета, что для него придется писать кроссредство для отладки и трансляции. Готовы к этому!?

P.S. В общем и целом я готов Вам помочь во всех Ваших начинаниях с ПЛИС. Лишь бы Вы с дороги не ушли :) и пробили нам туннель к МК-61м.

Ну я как бы 100% не уверен, но по арифметике есть всякие книги (не одна) и есть описание команд из MCS-51, которые выполняются всякие коррекции. Есть вроде как библиотека BCD для MSP (если мне не показалось). Как может быть что в начале 21-века, люди забыли как умножать BCD числа. Я согласен, что с этого надо начинать, потому как практически реализует большую часть самого калькулятора. CoolRunner потянет похоже пару 4-битных сумматоров, а дальше надо вертеться чтобы протащить через них все операции. Но не факт, что 20 мгц 4 тактный MCS-51 окажется быстрее :-)
Давайте совместно эту тему с BCD добъём.

Всякие микросхемы и платки я засаливаю уже давно, так что ничего страшного. У меня бывают припадки энтузиазма и периоды депрессии, но это дело постоянно вызывает у меня интерес, так что опасности совсем его бросить нет. Кстати очень интересным показалось описание работы комплекта микросхем в МК-61, но эмулировать их в ПЛИС смысла особого нет, по крайней мере с таким желанием (надо сказать настойчивым) надо бороться :-)

Рыть бесконечно я могу, это основное моё идиотское умение, причём рою я сразу во все стороны (изучаю очень много вещей параллельно), поэтому рою очень медленно, но всегда докапываюсь до цели, что является плюсом. Поставим цель - разобраться с BCD арифметикой на всех интересных платформах включая ПЛИСы. Друзья, давайте рыть вместе ! :-)

BCD меня как раз не пугает. Есть готовые библиотеки, есть литература. Для Z80 я писал bcd, правда до деления дело не доходило. Только целочисленное деление делал. Но и опыта было меньше. Кстати, a/b = а*(1/b), где 1/b можно хоть рядами вычислять. Формул много. BCD-библиотека это подвиг. Но будничный, просто месяцы упорного труда.

Мне не нравится, что мы до сих пор не умеем опрашивать клавиатуру МК-161 и выводить информацию на индикатор. Мой опыт показал, что даже имея схему я не знаю, где дёргать линии самостоятельно. А где кристалл их сам дёргает, в процессе обращения к чему-нибудь.

За 14800 рублей пускай СЕМИКО само опрашивает клавиатуру, очевидно тупиковая ветвь эволюции, жаль что вы тратите на неё свой время.

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

Сделаете хорошую платформу, мой труд поможет откомпилировать уже отлаженный входной язык под неё. Будет платформа пораньше, может обойдёмся и без bcd под 8051. :-)

Хотя мой экземпляр больше для коллекции, потрошить не хочется, кстати там тоже процессор на панельке. К тому же раз она стоит 14800 рэ, как же не жалеть :-)
Неужели для 8051 никто не делал BCD арифметику ранее ???
Вообще читаю про архитектуру, это конечно не подарок для Форта, а скорее кошмар фортера :-)

Схемотехника МК-161 не показалась мне какой то таинственной, опрос клавиатуры не должен быть таким уж сложным делом. Может на работающем экземпляре осциллом послушать ?

Где то я уже видел как на переходнике-плате (диповского конструктива) был разведён ARM контроллер и заменён 51-й и при этом там уже и USB интерфейс оказался добавлен.

Конструктивно МК-161 состоит из платы контроллера и отдельно плат индикатора и клавиатуры.

Проще уж менять не камень, а всю плату контроллера — поставив на новой плате совместимые разъёмы на клавиатуру и индикатор в нужных местах. Ну и отверстия под шурупы. :-)

BCD-арифметика под 8051 есть, например, в MCS BASIC-52. Особых проблем с ней не вижу, кроме трудоёмкости. Тем более, что со временем всё равно уходить на более развитую архитектуру.

Схемотехника не должна быть сложной. Однако за 10 лет никто пока не довёл опрос устройств ввода-вывода до уровня библиотеки или кода на 8051, который можно было бы использовать для разработки прошивки. Возможно, это принцип «Неуловимого Джо» и никто просто не лазал с осциллографом. Возможно, что-то серьёзней.

Если не хотите перепрошивать свою ЭКВМ, я могу пробовать код на своей. Специально приобрёл одну «для опытов». :-) Со временем можно будет просто купить на Али альтернативную W77 с нормальным загрузчиком по RS-232C — и слать туда прошивки без программатора.

Откуда "трудоёмкость" если уже вся работа выполнена в MCS BASIC-52 ?

Есть какие то атмеловские камни с 5 вольтовым программированием, но у них кажется ноги не совместимы. Ещё у меня был проект вклячить туда другой контроллер вставив в панель переходник-заглушку, но на тот момент это было слишком тонкой операцией и я не смог спаять всё как следует.
Вот на какие извращения нас обрёкло СЕМИКО :-)

Плавучка BASIC-52 скромная, содержит всего 6 цифр мантиссы. Надо будет разобраться с лицензией, посмотреть код и адаптировать к проекту, где хотелось бы видеть плавучку минимум 14+4. Также в МК-61 большой набор разных логарифмов и тригонометрии — это тоже придётся делать самим.

W77LE516P заказывается на Али без проблем. Никаких извращений не надо.

Новосибирск не «обрёк». Он внезапно подбросил заснувшее было сообщество до следующего пункта на карте, и весьма неплохо — на 2-3 порядка увеличив быстродействие и ёмкость памяти. Что не стал тащить до нашего пункта назначения, так и оплачивать дорогу по их расценкам вы почему-то не сильно спешите.

Я свой экземпляр купил, дальше оплачивать дорогу по завышенным вдвое ценам мы не будем. На этой раздолбанной шохе мы далеко не уедем, придётся собирать иномарку :-)

Нашёл исходники и там есть код BCD плавучки
http://www.kswichit.com/8051kit/BASIC52/basic.asm

Думается оно должно масштабироваться из 6 цифр на большее.

Любопытно ознакомиться с более менее готовой штуковиной. Но программировать под MCS-51, что то не хочется :-)

Кстати видели какая у них шикарная железка http://www.kswichit.com/8051kit/BASIC52/BASIC52.html
По сути BASIC калькулятор :-)

https://github.com/KnightOS/kernel/blob/master/src/02/fp-math.asm

Вроде как 14 разрядов мантиссы ???

Головная страница с объяснениями
http://www.knightos.org/2017/08/19/Decimal-math-support.html

http://forum.6502.org/viewtopic.php?f=2&t=2202 Calc65: a BCD floating point package
На этом форуме и Форт активно обсуждают.

У меня много книжек по 6502, надо глянуть как там народ страдал, небось арифметику нередко делали.

Даже он потянет как минимум 8 разрядный BCD сумматор. Если хотите могу синтезировать и предъявить.

Вы бы не могли изложить саму теорию, кроме того ей ещё надо тянуть сам процессор и какую то периферию, поэтому думаю, что после 8 разрядного сумматора там может не остаться ресурсов.

Не переживайте в C256 лезет 4-х разрядный сумматор (16 - бит) и даже вычитаель, поскольку тут не все так просто с вычитанием как в двоичке, просто инверснуть не получится.

Теория, ну давайте слегка к ней хотя бы приблизимся, очертим круг применимости CoolRunner в микрокалькуляторе.

Сначала ограничиваемся шириной ШД, исходя опять же из размеров и низкого потребления конечного устройства. С большой вероятностью это - 8 разрядов.
Поскольку "Гарвард" мы себе позволить не можем, то используем Фон Нейман, в котором ШД будет и шиной поставляющей код и шиной поставляющей данные. Это диктует два цикла работы вычислителя - цикл выборки кода - машинной команды, цикл доступа к ОЗУ для записи/чтения данных. Это так поскольку у нас всего одна ША используемая для обоих типов операций. Для нас оптимальней всего будет безадресная система команд, так в машинном слове не нужно будет оставлять место для полей операндов. Таким образом все 8 разрядов становится возможно использовать как линии управления ФУ процессора. И значит инструкция это не упакованное управляющее слово или его порядковый номер в ЗУ микрокода, а сам микрокод на прямую (т.е. по сути своей RISC). Для безадресной системы команд характерно наличие стека, учитывая наши скромные возможности я бы остановился на трех-уровневом стеке top,subtop,overtop. Для управления таким стеком напрашивается использование линии управления - разрешение записи. Таким образом 1 старший бита машинной инструкции мы заняли. Для направления движения в стеке будем использовать дешифрацию команды с выделением этого бита. Далее рассмотрим операции со стеком, предположительно хватит 8 операций - BCD сложение, BCD вычитание, логическое "И", логическое "ИЛИ", логическое "Иск.ИЛИ", POP, PUSH, размен тетрадами у top (тут еще можно подумать и что то выкинуть, что то вбросить). Когда операцию нужно пропустить, то влияем линией управления стеком - разрешение записи, делая любую из операций - но запрещая запись в регистры стека. Таким образом мы заняли еще три линии для управления АЛУ и TOP. Осталось 4 разряда машинного слова. Нам необходим условный и безусловный переход, по содержимому вершины. Будем считать что содержимое вершины можно выгружать по команде POP в один из приемников (IP, @SUBTOP, @IP+, ???). Если применяется команда PUSH то эти источники автоматически становятся источниками, и тогда @IP для приемников лучше заменить на TOP. Адресация источника 2 бита. Из условий хорошо бы иметь переполнение и вероятно сравнение на ноль вершины стека. Для упрощения можно считать что у нас есть только условные переходы jc/jnc и jz/jmp. Таким образом для реализации переходов, применим поле условий тогда любая команда будет условной-безусловной, поле условий на 2 разряда - С,NC,Z,any. Вот и не осталось у нас не одного бита машиннного слова :) Тепеперь надо понять чего же мы не можем делать при помощи полученного процессора и пересмотреть его структуру.

Вообще говоря околофортовский процессор будет очень кстати, может быть он же будет реализован софтварно в STM32 в других вариантах этого ряда. В общем попробовать разработать не мешало бы. Есть ещё какой то Tiny CPU специально заточенный под эти мелкие CPLD. Сейчас глянул, у меня четыре 8-килобайтных FRAM, они оказывается тоже низкого потребления (во время работы и простоя). Хорошее подспорье для такого процессора для хранения каких нибудь прошивок вместо флэша.

Но это экзотика - http://opencores.org/project,mcpu.

Спасибо, полезно изучить что да как

Ватник wrote: CoolRunner потянет похоже пару 4-битных сумматоров, а дальше надо вертеться чтобы протащить через них все операции.

Summary
Design Name sum
Fitting Status Successful
Software Version P.20131013
Device Used XC2C64-5-VQ100
Date 9-12-2017, 9:34PM

RESOURCES SUMMARY
Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used
36/64 (57%) 77/224 (35%) 33/64 (52%) 41/64 (65%) 40/160 (25%)

PIN RESOURCES
Signal Type Required Mapped
Input 8 8
Output 32 32
Bidirectional 0 0
GCK 1 1
GTS 0 0
GSR 0 0
Pin Type Used Total
I/O 33 57
GCK/IO 3 3
GTS/IO 4 4
GSR/IO 1 1
DGE/IO 0 -1

GLOBAL RESOURCES
Signal mapped onto global clock net (GCK0) clk

Как видите даже есть еще куда пихать, правда BCD 8 разрядный последовательный, т.е. для полного сложения нужно 8 тактов. Но и частота уж не 25МГц, а вполне может быть и 80МГц, а то и больше. Я думаю 10 миллионов сложений в секунду 8 разрядной десятичной мантиссы более чем достаточно?

Ну вот, всё не так страшно как нарисовали мне старшие товарищи, оказывается BCD лезет и в 32 ячейки, а у меня микросхема с 256 ячейками, ещё и проц влезет с внешней памятью. Надо посмотреть какая там разрядность у МК-161, они там гордились, что она недостижима для зарубежных калькуляторов. Пишут 12-14 разрядов. Придётся потратить 14 тактов :-)

Не знаю, поможет ли. Нашёл перевод статьи проф. Вирта с его реализацией процессора в FPGA.

Это полный работающий процессор, включающий плавучку, в том числе деление. К сожалению, не в bcd. Процессор написан на обероноподобном языке Лола (сам по себе может быть интересен), который транслируется в Verilog. Также в процессоре есть интерфейсы RS-232, SPI, PS/2 мышь и клава.

https://habrahabr.ru/post/259755/

Этот RISC профессора Вирта, в 256 ячеек CPLD не загнать. Кроме того питать его придется строго от сети, кушать он будет аж до по полуампера. Тут не прокатят стандартные ядра, мы же не в ASIC, Арви.

Всё ядро не обязательно использовать. Я надеялся, например, что двоичная реализация деления в FPGA (с исходным кодом) чем-то поможет вам в разработке bcd-деления.

Про питание — это же справедливо для всех ПЛИС, не только FPGA? Может быть интересно в них копаться и строить процессор под задачу. Но для карманных ПМК лучше взять что-то уже готовое, с малым энергопотреблением.

CoolRunner может снизиться и до 10-20 mA

В разных вариациях. А с CPLD тоже надо поупражняться, может что интересное выйдет. Аппаратная поддержка BCD операций, или BCD соопроцессор - это дело великое для калькулятора то. Этот МК-161 выжимает 12-14 разрядов, а с сопром можно скажем выжать 15 :-) И подключать сопёр можно только при питании от сети, а от батареек STM допустим будет скромно колбасить :-)
Причём никто не заставляет делать это магистральным направлением, пускай будут такие экзотические варианты Just for fun, польза нам и другим людям в обучении и тренировке как такие штуки выпекать. Глядишь на тестах ещё буржуйские калькуляторы уроем такой нестандартной архитектурой :-) Я пока не знаю как лучше извне контролировать тактирование CPLD, может подавать тактовый сигнал с ноги микроконтроллера ? Если надо замедлиться можно остановить тактирование вообще, в идеале - уметь отключить питание ПЛИС части полностью (транзистор ???).
ИМХО эта задача сама по себе уже прикольная. Программная педаль газа для CPLD вычислителя :-)

Да всегда сколнялся к тому что совместно с МК применять ПЛИС намного удобней. И тактировать с МК и код с данными выдавать с МК, не совсем правда понятно как в такой модели масштабировать сам МК, вроде бы он самодостаточен. Но как это сказать не спортивно что ли :) Будет намного сложнее ставить к ПЛИС дополнительно SRAM и ПЗУ, шить ПЗУ. Но и более спортивно.

Вот потребления из ДШ ядра CPLD CoolRunner на разной частоте, конечно это все очень примерно, но ориентироваться на это можно.
Frequency (MHz)
0 30 50 70 100 120 150 170 190 220 240
Typical ICC (mA) 0.021 11.68 19.40 27.01 38.18 45.54 56.32 63.37 70.40 80.90 88.03

BCD-сопроцессор очень хорошая идея. Он сильно разгрузит основное CPU, даже если будет включаться по праздникам. :-)

Но здесь придётся учитывать, что BCD это сердце ПМК. «Десятичные числа» МК-161 разработаны с любовью. Это не просто «плавучка» FPU. Это тип INTEGER и REAL в одном флаконе — когда порядок от 0 до 12, BCD-числа работают в формате «с естественной запятой».

Насколько я понимаю, даже обычную «плавучку» реализовать в камне — подвиг. Здесь же всё должно быть надёжно, чтобы не стать ненароком теми самыми «шпиёнами с контр-гайкой». Возможно, стоит тщательно продумать архитектуру BCD-библиотеки. Что нам нужно на выходе, какая арифметика и функции. Как конкретно эти вычисления предлагается реализовать, тут выбор большой. Какие именно операции будут наиболее трудоёмки для основного процессора, что оптимально вынести в «железо».

Расширим и углубим, догоним и перегоним ! Кстати, я не очень верю, но если мы хоть что то выпустим с лучшими характеристиками, может быть СЕМИКО по принципу собаки на сене, чем ни будь ответит, всё таки они начинают не нуля. Хотя мне то уже будет по барабану, надоело клянчить у больших дядь сделать игрушку, мы теперь сами умеем их делать :-)

Пока кажется логичным иметь 15 разрядов мантиссы и 4 разряда порядка. При этом один байт будет содержать флаг — знак мантиссы и, возможно, порядка.

Такие bcd-числа будут занимать 20 разрядов или 10 байт (80 бит). Но самый писк, конечно, это decimal128. :-)

Придерживался бы вполне логичной позиции отца народов - сначала скопировать имеющиеся, то есть МК-61 8 + 2, а потом уже замахиваться на что то сверх технологичное, когда технологии уже отработаны.

Какая принципиальная разница между 8 и 15 ?

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

  1. Делать внешний сумматор на 8 десятичных цифр к маргинальным CPU, вроде 8051.
  2. Ставить внешний процессор для обслуживания стека и десятичных регистров, куда выносить всю bcd-математику.
  3. Разработать сопроцессор самостоятельно.

Первый подход интересен в плане перспектив импортозамещения. Но непонятен, т.к. МК-161 на 8051 уже вполне успешно щёлкает bcd-числа безо всяких наворотов. Зачем в ПМК следующего поколения втыкать 8051? Да ещё «плавучку» с меньшим количеством значащих цифр, чем у МК-161. UPDATE. Ниже написали, что для STM32 может пригодиться.

Второй подход красив. Хотя если в качестве основного процессора будет зарубежный, он сможет и без сопроцессора справляться с bcd-числами. Проблем с быстродействием не предвидится. Нужно ли усложнять схемотехнику?

Третий подход имел бы патриотический смысл, выпускай наши ПЛИС с малым потреблением. Но сейчас это просто разработать «на коленке» свою архитектуру и надеяться, что когда-нибудь её сможем выпускать в камне.

Будем курить.

Ну не в 32 правда а в 36 ячеек :)

А у вас CoolRunner xc2C256 уже на макетке? Или только сама ПЛИС-ина? Посмотрите референс какой либо для правильного разведения питания насколько я понимаю у нее 1.8В и 3.3В питание ядра и периферия. Т.е. еще много работы по макетированию, видимо? Кроме того - программатор есть, или будете через параллельный порт? Среду установили?

Насколько понимаю у Вас - 100-ногое изделие, значит порядка 80 входов/выходов у Вас есть. Предположим что программный автомат внутри будет - 8 битным (ну пока только предположим) и того на ШД - 8 линий, на ША - 16 линий, на дисплей 7 + 12 линий, на клавиатуру те же 12 что и на дисплей + грубо 10. Итого приблизительно 53 ноги занято. То есть Вы в бюджете IO.

Ну и вовсе не обязательно тратить 8 тактов на 8 разрядов, это для примера я сделал одноразрядный BCD сумматор как основу (то есть только на один 4-битный разряд), ничего не мешает сделать его 2 разрядным, ячеек то хватает, тем самым сократить кол-во тактов вдвое. Но это уже исходя из того что полезет в качестве программного автомата внутрь ПЛИС. А вот тут то конечно хочу Вас предупредить на что то сверх технологичное (ну например 8051) не рассчитывайте, будет примитив. Если есть желание то могу накидать вам в черне и схематично какой нибудь примитив, если уж непременно на ПЛИС хотите зарубиться :). Только смотрите кросс средства для него нужно писать самостоятельно, осилите?

P.S. Я то только за, поскольку к ПЛИС сильно тяготею.

Конкретно это XC2C256-7TQG144C, 144-pin TQFP with 118 user I/O

У меня есть квадратая макетка QFP-144, она все ноги в стороны растаскивает под штырьковые разьемы, жаль на ней нет места чтобы приделать компоненты. Я взял регуляторы напряжения специальные (изучал как устроены чужие платы) и тактировать пока не знаю как (думается вообще от микроконтроллера). Как думаете стоит париться ЛУТовать (фоторезистировать) свою плату или пока припаять на эту квадратную и помучить подключая остальные штуки извне проводками ? На частоте 100Mhz волновые эффекты будут проявляться ? Я хочу подключить асинхронную SRAM через параллельный интерфейс. Что будет если плата этого SRAM (допустим сделаю ЛУТом) будет подключена длинными проводами к соответствующим штырькам ног, в любом случае сантиметров 10 получится, емкость там и всё такое. Читал статейку где чел такой же SRAM подрубал, он там специально разводил всё по рекомендациям лучших собаководов. На чтение завёл на максимальной скорости, а запись почему то оказалась в 3 раза тормознее.

Мне тема ПЛИС КРАЙНЕ интересна, вероятно я мог бы стать образцовым ПЛИСофашистом, но не было времени с ними как следует поиграться, закупился то я по полной и альтерами и ксайлинксами, программаторы под обе платформы. Книжек по HDL тьма, кое что конечно уже освоил. Время собирать камни !

Программатор есть. Среда есть, должно работать.Если что у меня на работе есть гуру ПЛИСоводства (причём не один), может и они подскажут, если что то пойдёт не так.

По поводу архитектуры надо думать и экспериментировать.Надо завести этот CoolRunner и поморгать диодом для начала. До этого я имел дело только с CPLD Altera MAX3000, проблем с прошивкой не возникало.

Вообще есть и другой путь, у меня есть готовые Xilinx FPGA платы например Core3S500E или Pynq c Zynq-7020, там конечно совсем другая архитектура, но базовые вещи можно отработать на них (экономя ресурсы), а потом попытаться вклячить в CPLD.

А именно впаивайте TQFP-144 на макетку про которую писали с пинхедерами по сторонам, тактируйте от микроконтроллера - это самое простое что вообще можно предложить, кроме того с него же заведите ШД и ША, пусть будет синхронной/асинхронной памятью программ/данных для CPLD.

При 100Мгц конечно уже все проводочки начнут как минимум "звенеть" а как максимум валить фронты. На 10см скорее всего Вы ничего не почувствуете, но при определенных обстоятельствах разность хода и емкость параллельных проводников могут сыграть злую шутку. А потому не стоит пока лезть в такой скоростной дизайн, до 50-70МГц на небольших отрезках проводников (до 9-10 см) вполне можете макетировать. На 20-30МГц думаю даже на "дурацкой" доске будет нормально.

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

Не забудьте что у ввода-вывода должна быть совместимость с выбранным режимом IO (как правило LVTTL или LVCMOS). Это когда ПЛИС стыковать будете с микроконтроллером или памятью.

Заказал неподалёку пару кварцевых генераторов на 60 Мгц. Если что задействую делитель. Попробую обойтись без микроконтроллера и так заморочки приличные. В принципе если SRAM прицепить практически на гребенку IO контактов, то длина будет несколько сантиметров, вопрос выравнивания по длине конечно останется, но у того чела на большей длине со шлейфом память заработала. Фронты попробую посмотреть осцилом, в принципе полезно знать что происходит. Вероятно стоит сделать ЛУТом одну платку где будут все необходимые вещи - питание, память и кухонная раковина :-) и воткнуть туда эту макетку. Если получится, ту же операцию провернуть с Spartan-6, этак я смогу прорваться к собственному производству ПЛИСоплат (мечта идиота), а там и до ПЛИСофашизма недалеко :-)

На первых порах бы рекомендовал все же заменить ОЗУ+ПЗУ+Осцилятор на микроконтроллер :) Будет зело проще, будете знать что происходит на ШД и ША и как то отлаживаться.

Да и одно другому не мешает, напаять CPLD на макетку, а дальше можно разными штуками её пытать :)
По поводу ПЗУ у меня закуплен FRAM 4 микросхемы FM16W08-SG в SOIC по 8 килобайт каждая. Она мало потребляет и питается от низких вольтов, прямо отлично вписывается в low power устройство :-)

Я как-то раз собирал себе макетку на ПЛИС EPM3064-10N, это самая медленная версия кристалла на 100МГц, так у меня вполне нормально работал самодельный генератор полос для VGA 1024х768 75Гц от кварцевого генератора 80МГц (не нашёл на 100) при несколько пониженном о 3В напряжении питания. Саму программу я в схемном редакторе рисовал, но поэтапно, сперва регистр, потом логическую схему для использования в качестве синхронного счётчика, формирователь синхроимпульсов и из самодельных блоков уже рисовал схему :) но это только на первых порах, дальше нужно в языке разбираться. Программатор на буфере НЕ заработал, поэтому пришлось прошивать через пять проводков, но все кристаллы прошивались без нареканий. Если на ПЛИС портировать эмулятор МК-61, то можно получить тысячекратный прирост быстродействия :)

При разных режимах. Судя по даташиту, потребление около сотни миллиампер. Видимо меньше или как минимум не больше потребления МК-161 с выключенным экранчиком. Тогда зачем этот убогий хард процессор 8051, если софт процессор и гибче и потребляет меньше даже на старом MAX3000 ???

Потребление всего 50мА, но у меня занято чуть больше половины кристалла. Нет, ЕРМ3064 годится только для первоначального обучения, но не более, для этого собственно и приобретал. Для количественной оценки рекомендую почитать тему на Марсоходе, там упрощённый AVR микроконтроллер сожрал свыше 80% объёма кристалла вчетверо более ёмкой ПЛИС. Так что, самопальный процессор лучше делать на FPGA, на ней спектрум сделали, на FPGA Миландр 1886-ю серию (PIC17) макетировал.

Вот приведенный мной выше процессор - занял 160-180 макроячеек CoolRunner, на первом приближении. MAX-II на котором Марсоходовцы сделали reduce AVR, имеет 240 LE's (это не совсем макроячейка, это полноценный LE с FPGA). Тут проблема в том что регистровая машина сожрет все что есть в CPLD под мультиплексор в АЛУ, вот так за здорово живешь профукает все LE's под входной мультиплексор по моему на 5 регистров только AVR. Так тут нельзя подходить к делу, поэтому и не регистровая машина. А если уж регистровая то как PIC с одним аккумулятором. Либо удобство программирования, либо размер - одно из двух.

В репозитории немецкой FIG
https://www.forth-ev.de/repos/microcore/trunk/

Изучим штуковину.

Вот тут потребления то что надо :) тоже 64 ячейки.
Frequency (MHz)
0 25 50 75 100 150 175 200 225 240
Typical ICC (mA) 0.017 1.8 3.7 5.5 7.48 11.0 12.7 14.6 15.3 17.77

50МГц - 3.7 mA это вполне терпимо

Честно говоря прослезились в итоге все равно будет хуже МК-161, ну или чуток обгонит его :)

Вот сейчас и думаю если бы это был ускоритель BCD арифметики то как его загружать? Предположим 10 разрядов (8 мантиса и 2 порядок, знаки передать отдельно) это 10 тактов загрузки по тетрадно. И 5 тактов загрузки по байтно - на один операнд. Предположим 10 тактов на два операнда то есть синхронная шина шириной в 8-бит и сам сингнал синхронизации. Получается нечто подобное шине к LCD модулю. В принципе не так напрягает по требованию к свободным ногам контроллера.

Далее что же ему ускорителю делать что бы в итоге победить хотя бы тот же МК с которого он получает упакованные BCD (кстати - упакованные, это важно). Я думаю как минимум сложить с учетом порядка. То есть подогнать мантиссу меньшего по порядку числа сдвигом влево. Если в этом есть какой то смысл, что бы не тратить на сложение время, так как может получиться просто один из операндов! Сложить и выгрузить обратно по той же шине но уже в два раза быстрее, т.е. 5 тактов.

Загрузка-выгрузка - 15 тактов.

Приведение мантиссы будет сильно зависеть от того на сколько нужно двинуть меньшую мантиссу, но как максимум это 8 разрядов. А значит и 8 тактов на операцию.

Суммируем параллельно (если хватит ячеек в XC2С64) или не параллельно - 1 или 4 такта.

И опять надо привести мантиссу к принятому в МК-61 виду. Т.е. как максимум 7 тактов.

ИТОГО 10 + 5 + 8 + 4 + 7 = 34 такта.

Так вот стоит ли биться?

Допустим нет способов грузить больше разрядов за такт, можно же шину сделать 16 битную и по 4 разряда за раз грузить. А сколько же хотя бы суммирование займёт на 8051, на STM32 ????
При том что суммирование одного разряда у 8051 занимает небось 4 такта ? В итоге получим 10 разрядов 40 тактов без коррекции. А на всю операцию тактов 60 уйдёт ???? Это только суммирование и то без параллельной загрузки. Можно АЛУ сумматора заставить выполнять серии операций, например суммировать числа и умножить на поданное ранее или дополнительно число. При том этот примитивный сумматор небось может работать на частотах выше 100 ???

У тех контроллеров, что я думаю использовать очень много ног, можно грузить по 16-32 бита за раз, до 8 разрядов получается, то есть это пара тройка тактов на загрузку, а не 10.

Можно не возвращать число после операции, а ждать новых операндов, возвращать только по требованию.

так как имеет аппаратную команду BCD сложения, правда неупакованных BCD, тратит один такт при сложении двух регистров с 2-х разрядными BCD числами.

Example The two-digit BCD number contained in word BCD (16-bit address) is added decimally to
a two-digit BCD number contained in R4. The carry C is added, also. R4.19:8 = 0
CLRC ; Clear carry
DADD.B &BCD,R4 ; Add BCD to R4 decimally. R4: 0,00ddh

Но я то говорю про xc2c64 которая всем легко доступна чуть ли не за 170 рублей уже распаянная и с осциллятором. Так вот у нее ног дай бог бы на это хватило :)

Вот, как раз призывал подумать перед тем, как делать. Просто загрузить два числа, сложить и выгрузить результат — не так интересно.

Но уже для аппаратного умножения столбиком нужны цепочные операции. Загрузить, умножить, сдвинуть, сложить. При этом не все промежуточные результаты нужно туда-сюда гонять.

Также если определиться с алгоритмом вычисления функций (логарифмы, синусы, квадратный корень и т.д.), там можно найти повторяющиеся операции для реализации в сопроцессоре. Чтобы считывать только конечный результат, а всю «магию» делать в сопроцессоре. Её можно сделать собственным микрокодом или на костылях, под управлением центрального процессора.

Как вариант, можно хранить в сопроцессоре два-три верхних элемента стека и таскать их в центральный процессор лишь при необходимости. В этом случае сопроцессор должен уметь вычислять «настоящие» синусы вроде ПМКшного Fsin — то есть уметь приводить аргумент к тому диапазону, который покрывается основной формулой. Этим может управлять и специальная программа, написанная в системе команд сопроцессора.

Считывать числа из ОЗУ в свой мини-стек сопроцессор может либо самостоятельно, либо это дело CPU. Работать над bcd-сумматорами АЛУ хорошо, но все эти архитектурные вопросы лучше заранее продумать.

Необходимо помнить что МК на ввод-вывод тратит порой больше тактов, чем на вычисление внутри, таким образом нужно обеспечивать неоспоримое преимущество вычислений за бортом.

Насчет "не интересно" загрузить два числа. Разберемся вот наши два числа представленные в упакованной BCD форме:

12345678 ^ E-10
98765431 ^ E-5

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

Нужно привести !первую! (это мы определили орагнолептически :)) мантиссу ко второй путем ее сдвига вправо на 5 тетрад. Т.е. пока порядки не уровняются.

1. И так - первая совсем не очевидная операция выяснить какое слагаемое двигается вправо и на сколько!

Вышесказанное означает что
а) должен быть компаратор и сумматор(вычитатель) - вычисляющие слагаемое для сдвига и кол-во сдвигов.
б) аппаратура должна уметь двигать оба слагаемых, еще лучше грузить с той тетрады с какой укажет пункт а)

00000123 ^ E-5
98765431 ^ E-5

2. Ну теперь вроде бы проверенная временем операция суммирования BCD упакованного числа - согласен это просто, мы уже это проверили.

98765554 ^ E-5 (кстати на МК61 эта операция дает 987.65555 (что то несуществующее округляет?)

3. Теперь выгрузим все это переключив коммуникационную шину на вывод, предварительно уведомив микроконтроллер о том что результат можно забирать, линией готовности.

Вот Вам и не интересно, Арви, это только кажется что это не интересно. А можно еще добавить интересу, попытавшись складывать мантиссы при их загрузке, для этого числа нужно отправить в "сопроцессор" перевернув и порядком вперед (что бы вычислить сдвиг мантисс предварительно), т.е. вот так

87654321 10(-) ---> 12345678 ^ E-10
13456789 5(-) ---> 98765431 ^ E-5

А если учесть что знак есть и у мантиссы! То вообще трындец, поскольку наш сумматор умеет только складывать :) и ему надо давать разжеванные числа на СЛОЖЕНИЕ.

Вот сколько всего надо обдумать Арви.

МК может вообще не тратить на ввод вывод если это в обход CPU, в STM32F4 есть матрица интерконнекта, которая позволяет пересылать данные не занимая центральный процессор. Придумать бы такой порядок выполнения, чтобы всё что надо считать на сопре в него заранее грузилось, этакий небольшой кэш ближайших операндов. Может так статься, что до запроса значения какой то переменной сопёр ни разу не перешлёт результат обратно в МК, будет добавлять к нему и добавлять, а некоторые вещи он мог бы выполнять вообще без добавления новых данных, например 1/X или X^N (насчёт квадратного корня побаиваюсь :-) В FPGA есть DSP блоки всякие, может быть есть смысл ориентироваться на Spartan-6 он недорогой и жрёт вроде умеренно (Xilinxы хвастали, что жрёт вполовину от предыдущей серии). Может быть его можно конфигурировать прямо с процессора без конфигурационного флэша (ибо этот флэш малость дороговат).

Может! И в STM32 и в MSP430 DMA присутствует и вполне себе умеет данные вытряхать самостоятельно. Это Вы верно заметили. Но встает вопрос их организации, CPLD-шке их нужно подавать поразрядно параллельно, а это значит в памяти два операнда BCD лягут как макароны, и микроконтроллер будет тратить время на их трансляцию для использования самому.

Фух да все это есть и DSP и умножители и ПЛИС-ны с памятью, но нам это все не "катит", это все жрет в три глотки. Давайте ориентироваться на что нибудь скромное до c256, а лучше набор из C64, что бы любой мог это приобрести и использовать. И ориентироваться надо на что нибудь попроще - от простого к сложному.

Да пускай даже сопроцессор не так важен, но и просто иметь в системе CPLD полезно,
можно к ней периферию подключать и её саму как периферию использовать, считай марсоход улучшенный.

Сдвиг слагаемого не обязателен. Быстрее переставить один из указателей и поменять число складываемых цифр.

«Не интересно» в смысле интерес (доход, выгода) от реализации указанного алгоритма на сопроцессоре. Это мне мой личный интерес. :-) Если в ПЛИС только сумматор, выгода небольшая из-за тасования чисел по медленной шине туда-сюда.

Другое дело, полноценный процессор с продуманной системой команд и прошивкой — вы скидываете ему адреса двух операндов и результата. Он сам их грузит из памяти и реализует описанный вами древний алгоритм — впервые с ним я столкнулся ещё подростком в советское время, разбирая код MSX-BASIC'а на Z80. В этом случае выгода от использования сопроцессора будет. Во время вычислений CPU сможет заняться чем-то другим.

P.S. Кстати, стековая память может быть доступна только сопроцессору. Когда CPU потребуется считать что-то из стека (в BCD или Integer), он может это делать услугами сопроцессора. Операции типа DUP SWAP ROT ROLL центральный камень может тоже ставить в очередь команд сопроцессора и продолжать заниматься своими делами.

Ведь матрица могла бы сама лазить в память за данными, я же планирую использовать внешнюю SRAM.

Доступная матрице память не обязательно должна быть включена в адресное пространство главного камня. Это упростит схему.

Размер bcd-памяти лучше выбрать больше 10К — чтобы улучшить тысячу «десятичных регистров» МК-161 из расчёта 10 байт на регистр (15+4).

В такой памяти Каллисто хранит десятичный стек и десятичные переменные. Каллисто-2 будет использовать десятичную память также для хранения хэша имён слов. Это позволит пройти узкое место Каллисто 1.0, из-за которого та тормозит на МК-161.

В принципе, роль десятичного сопроцессора не обязана играть матрица. Это может быть любой микроконтроллер или процессор. Главное, чтобы мало тока жрал.

Это как это Вы себе внутри CPLD представляете указатель? Ближайший аналог - мультиплексор, ну так он сожрет все что есть и без того в маленькой CPLD.

С чего бы вдруг медленная шина внутри ПЛИС? Эта шина внутри ПЛИС с таким сумматором от 100МГц и выше.

Чем тогда не устраивают уже имеющиеся процессоры? STM32 в руки и вперед реализовывать BCD. И опять же непонято как CPU может заниматься чем то другим если он уже будет занят перекручиванием операндов в памяти.
Не может так быть сопроцессор отдельное устройство, процессор отдельное - между ними шина для передачи данных, никто ни к кому в память лазить не сможет.

Ватник прав в том что для передачи данных в порты можно воспользоваться DMA, одно плохо все это накладывает ограничение на организацию данных, и если уж их сильно "замиксовать" что бы было удобно подавать сопроцессору посредством DMA то тогда уже процессор (микроконтроллер) начнет тратить время на их представления для себя в необходимом порядке.

Может быть стоит явно указывать или как то детектировать в коде массивные операции, особенно умножения и всякие хитрые функции, когда в сопёр можно закидать много данных. Если это единичные операции, но нефиг его дёргать вообще, в идеале сразу срезать тактирование, если он не занят ничем. В отличие от серии МК-61 и т.д. я считаю, что надо таки различать целые и плавающие типы, для счётчиков использовать бинарные типы,а не десятичные. Всякие целочисленные расчёты вообще не будет попадать в сопёр, операции перестановки в памяти тоже. Вопрос надо ли сравнение BCD (больше меньше) в сопроцессоре, думается сравнить два числа можно эффективно и на контроллере ??? Если сопёр будет типа сопроцессором, то он конечно может сам играть роль DMA, например переставлять элементы матрицы, пока центральный процессор решает что переставлять в следующих столбцах и т.п. Правда не ясно как автоматически такие операции распределять между ними, потребуется анализ зависимостей в потоке данных (что вполне реально). Инструкции (микропрограммы) он сам допустим получает пачками из ОЗУ, поэтому куча собственной памяти ему не потребуется. В FPGA конечно можно бы всё кэшировать в блочной памяти.

Медленная шина не та, что внутри ПЛИС — а та, что между ПЛИС и CPU. Если мы хотим повышать производительность, по ней надо передавать как можно меньше данных.

«Чем тогда не устраивают уже имеющиеся процессоры? STM32 в руки и вперед реализовывать BCD.» — о том и речь. Поставить отдельный процессор на bcd-арифметику с отдельным ОЗУ под десятичный стек. Простое и надёжное решение, чем городить ПЛИС на сомнительных верёвочках от CPU.

Арви, так хватит и одного STM32 что бы Ваши интересы покрыть.

Ускоритель на CPLD или FPGA, это что то что делает сложение 8 разрядного BCD быстрее одного STM32. Ну что тут не понятного.

Вот реальный пример я просчитал такой ускоритель в CPLD, получается 16 тактов на загрузку/выгрузку и расчет суммы. Попробуйте на STM32 сделать это быстрее. Посмотрим. На одинаковой тактовой. Вот только одного триггера мне в C64 не хватило, поэтому либо С128, либо С64 + С64, либо С64 + триггирование линии с МК.

Учитывая что операций BCD арифметики в STM32 нет, то лучше проверять на MSP430, который два неупакованных BCD складывает в регистрах за такт (но регистры еще надо заполнить). 8 неупакованных msp430 сложит за 4 такта, но загрузка регистров минимум по 2 такта на каждый и сдвиг мантиссы скажем до 20 тактов (на вычисление где больше и преобразование адресов загрузки). Итого 16 тактов если не учитывать выравнивание мантисс и 36 тактов если ее учитывать - очень приблизительно.

Если результат вычислений не выгружать, а использовать повторно — ускорение будет ещё больше. Поэтому и писал о сдвиге на 1 разряд и умножении на цифру, для ускорения bcd-умножения.

8 разрядов это ещё один клон МК-61. Сейчас state of art это 12-разрядные числа МК-161.

Уже есть готовая библиотека, насколько я знаю. Надо буде пошукать. А что сомнительного в верёвочке ПЛИС, если плис будет прицеплена как 16 битная память через FSMC. 4 разряда BCD улетают с частотой 36Mhz это очень хорошая верёвочка и происходит прозрачно для программиста. Вы просто пишете данные в нужные адреса, а они вместо этого улетают по шине. 12 разрядов BCD, это 3-4 такта. Для ПЛИС не составит труда работать на такой частоте.

Не забудьте что первый код должен как то попасть в FRAM.

Надо конечно предусмотреть выводы для программирования

Я ни разу не против технического творчества, однако, хотел бы предостеречь: без четкого ограничения рамок предполагаемого изделия инженерный проект превратится в типичную маниловщину. Проектировать процессоры интересно (мне со времен вуза более не приходилось), однако если цель - создание калькулятора, то подобные отступления несомненно приведут к печальному итогу: по истечении нескольких лет все по-прежнему будет оставаться на стадии "скоро все должно заработать".

Ограничился бы полным 8 разрядным BCD сумматором внешним к управляющему контроллеру.
А перед реализацией, просчитать:
а) наксколько быстрее такого же сумматора но силами самого МК
б) как много все это будет потреблять в расчете на одно BCD число

Хорошо бы предусмотреть возможность сдвига влево на 1 ниббл (без пересылки в CPU) и умножения на 1 десятичную цифру. Разрядность сумматора должна быть больше, чем разрядность основных bcd-чисел.

Арви, черт возьми - один сумматор BCD полностью автоматический, только грузи в него порядок и мантиссы и то в C64 еле полез! Ближе к земле.

RESOURCES SUMMARY
Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used
85/128 (67%) 175/448 (40%) 65/128 (51%) 14/80 (18%) 124/320 (39%)

Так что можно предусмотреть умножение на 10 :), только все равно у меня нет C128 что бы это проверить. А не полез в частности из за того что пришлось городить мультиплексор который мантиссу двигает. Подумаю как можно без этого обойтись а вдруг вколочу ее в С64.

Удалось обойтись без сдвига влево и с одним сумматором обычной разрядности, но внезапно со сдвигом вправо.

От «сопроцессора» потребуется аппаратное умножение на 1 цифру (например, по таблице из ПЗУ 4×4×8) и сохранять числа в регистрах, но можно попробовать реализовать «в железе» весь алгоритм.

** Нужно пять bcd-регистров **

Два 4-разрядных:
  a3..a0 Множимое, полноразрядный вход умножателя
  b3..b0 Множитель, подаётся поразрядно на второй вход умножателя

Два 5-разрядных:
  s4..s0 Регистр на выходе умножателя, перед вторым входом сумматора
  c4..c0 Накопитель, регистр на выходе сумматора и перед первым его входом

Один 8-разрядный (только на запись):
  ответ7..ответ0 Произведение

** Иллюстрация **

            a3 a2 a1 a0
            b3 b2 b1 b0
       ————————————————
         b0×a3 a2 a1 a0
      b1×a3 a2 a1 a0
   b2×a3 a2 a1 a0
b3×a3 a2 a1 a0
———————————————————————
c7 c6 c5 c4 c3 c2 c1 c0

** Алгоритм **

Загрузить a3..a0 множимым
Загрузить b3..b0 множителем

c4..c0 := 0 ; Можно сразу перенести s4..s0, без сложения

s4..s0 := a3..a0×b0 ; Вот эту операцию и хочется «в железо»
c4..c0 += s4..s0    ; Сумматор «в железе» уже есть

Получена цифра: ответ0 := c0
Сдвинуть c4..c0 вправо на 1 разряд

s4..s0 := a3..a0×b1
c4..c0 += s4..s0

Получена цифра: ответ1 := c0
Сдвинуть c4..c0 вправо на 1 разряд

s4..s0 := a3..a0×b2
c4..c0 += s4..s0

Получена цифра: ответ2 := c0
Сдвинуть c4..c0 вправо на 1 разряд

s4..s0 := a3..a0×b3
c4..c0 += s4..s0

Получены последние цифры: ответ7..ответ3 := c4..c0

BCD-умножение можно реализовать проще, размещая младшие (первые) цифры ответа в освобождающихся старших разрядах множителя b3..b0. Сдвигая множитель вправо, чтобы всегда подавать на вход умножителя его младший разряд b0. В этом случае отдельный регистр ответа не нужен. Регистр b3..b0 можно открыть для чтения и записи со стороны CPU, а старшие разряды ответа будут считываться процессором из b7..b4 (бывшие c4..c0).

** Нужно три bcd-регистра **

Один 4-разрядный (CPU W/O):
  a3..a0 Множимое, полноразрядный вход умножителя

Один 5-разрядный (внутренний, без доступа из CPU):
  s4..s0 Регистр на выходе умножителя, перед вторым входом сумматора

Один сдвиговый 9-разрядный объединяет два регистра (5+4):
  b8..b4 Накопитель, регистр на выходе сумматора и перед первым его входом
  b3..b0 Множитель, разряд b0 подаётся на второй вход умножителя
         Также сюда засовываются слева разряды ответа

b8     внутренний, без доступа из CPU
b7..b4 CPU R/O
b3..b0 CPU R/W

** Иллюстрация **

            a3 a2 a1 a0
            b3 b2 b1 b0
       ————————————————
         b0×a3 a2 a1 a0
      b1×a3 a2 a1 a0
   b2×a3 a2 a1 a0
b3×a3 a2 a1 a0
———————————————————————
d7 d6 d5 d4 d3 d2 d1 d0

** Алгоритм **

Загрузить a3..a0 множимым
Загрузить b3..b0 множителем

b8..b4 := 0              ; Можно сразу перенести s4..s0, без сложения

s4..s0 := a3..a0×b0      ; Вот эту операцию и хочется «в железо»
b8..b4 += s4..s0         ; Сумматор «в железе» уже есть

Сдвинуть b8..b0 вправо на 1 разряд  ; Цифра d0 сейчас в b3

s4..s0 := a3..a0×b0
b8..b4 += s4..s0

Сдвинуть b8..b0 вправо на 1 разряд  ; Цифры d1 d0 сейчас в b3 b2

s4..s0 := a3..a0×b0
b8..b4 += s4..s0

Сдвинуть b8..b0 вправо на 1 разряд  ; Цифры d2 d1 d0 сейчас в b3 b2 b1

s4..s0 := a3..a0×b0
b8..b4 += s4..s0                    ; Цифры d7..d3 сейчас в b8..b4

Сдвинуть b8..b0 вправо на 1 разряд  ; Теперь ответ в b7..b0

Последний сдвиг можно не делать, если это упростит схему. b0 подаётся на вход умножителя, делать обвязку для считывания b0 процессором не обязательно. В этом случае ответ считывается из b8..b1.

P.S. Написал ниже, как выполнять умножение на один разряд.

Давайте двигаться медленно.

Начнем все таки опять с загрузки. Какие проблемы вижу.

а) При загрузке сопроцессора по DMA на внешний порт, нет возможности выставлять SYNC.

Остается синхронизироваться по тактовой, вытащив ее на внешнюю ногу МК.

б) При загрузке сопроцессора по DMA грузить придется байтами и не в два потока, а в один.

в) Плохо то что не ясно какой операнд идет первым, больший или меньший. Необходимо готовить обе стратегии сложения. Если бы порядок загрузки всегда бы был "больший операнд, меньший операнд", то удалось бы в некоторых случаях проводить вычисление досрочно.

г) Что делать если операнды имеют порядок больший разрядной сетки. Скажем складываются 1 E 8 и 1 E3. Первый будет захвачен как 00000001 E 8 а второй как 1000 E 0. Сейчас аппаратура вычислит дельту порядка получит 8 и вообще ничего не сложит. Нужно приводить мантиссу в крайний левый разряд и изменять порядок. Вот первая засада.

1. Можно сделать в матрице просто bcd. А плавучку, выравнивание мантисс уже реализовывать программно.

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

Выполнять ли нормализацию результата аппаратно или в CPU, тоже вопрос. Можно сделать в матрице отдельную операцию «нормализация», которую CPU запускает при необходимости. Хоть на операндах, хоть на результате.

Надо бы понять сколько тактов убивается на нормализацию МК. Конечно нормализовывать надо и так и так. Если бы расчет проводил STM32 то работали бы с не упакованными BСD в формате

X+1[00:M7_00:M6_00:M5_00:M4] X[00:M3_00:M2_00:M1_00:M0]

Поскольку BCD арифметики у STM32 нет то пришлось бы читать 32 р-р словом 4 разряда мантиссы

  LDR R4, BCD_TABLE    ;(2) смещение таблицы BCD сложений
  LDR R5, #000000FF    ;(2) маска очистки
  LDR R0, X            ;(2) 4 младших разряда X
  LDR R1, Y            ;(2) 4 младших разряда Y
  LSL R0, R2, #4       ;(1) сдвинем
  OR  R1, R2, R2       ;(1) совместили X3:Y3_X2:Y2_X1:Y1_X0:Y0

  AND R5, R2, R6       ;(1) маскируем разряд
  ADD R4, R6, R6       ;(1) смещение в таблице BCD
  LDR R7, R6           ;(2) загрузка суммы 1 р-р
  MOV R7, R8           ;(1) накопитель

  LSR R2, R2, #8       ;(1) следующая пара 2 р-р
  AND R5, R2, R6       ;(1) смещение
  LDR R7, R6           ;(2) загрузка суммы 2 р-р
  LSR R7, #8           ;(1) 
  OR  R7, R8           ;(1) накопитель

..... и так далее (все очень примерно может и можно еще оптимизировать)
Подготовка 4 такта
На подготовку к суммированию 4 разрядов - 6 такта
На первый разряд затрат - 5 тактов
На следующие 3 разряда затрат - 6 тактов
Выгрузка на место - 2 такта
ИТОГО без нормализации 4 + (6 + 5 + 3*6 + 2)*2 = 66 тактов

P.S. Забыл про перенос в каждом разряде, так что к 66 тактам надо будет еще 20-ток накинуть

Если бы расчет проводил MSP430 (я запамятовал он работает именно с упакованными BCD) то число лежало бы в ОЗУ (вероятно так как в регистрах бы на весь стек МК-61 не хватило бы место x,y,z,t,x1 - заняли бы 10 регистров и с оставшимися тремя много не навоюешь) в виде:

X+1[M7:M6_M5:M4] X[M3:M2_M1:M0]

  MOV   #Y, R15      ; (2)
  CLRC               ; (1)
  DADD  @R15+, &X    ; (5)  суммируем младшие 4 разряда
  DADD  @R15,  &X+1  ; (5)  суммируем c переносом старшие 4 разряда

Итого на полное суммирование без нормализации - 13 тактов.

Вот с кем мы будем бороться, Арви и я не уверен что msp430 можно победить CPLD-хой :)

P.P.S Поправил msp430 DADD выполняет уже с учетом переноса!

Вечером уже сообразил что я делаю не так. И вот что у меня получилось, если DMA микроконтроллера:
а) высылает обе мантиссы в порядке чисел от большего к меньшему числу
б) внутри мантиссы передает данные байтами от младших разрядов к старшим
в) выставляет на линии три разряда dP - абсолютное значение разницы порядков
г) синхронизирует C64 тактовой частотой в два раза выше частоты выгрузки байт по каналу DMA
д) забирает значение по тетрадно с выхода результата C64, каждый такт с момента подъема C64 сигнала Ready

То за 16 + dP тактов можно получить результат сложения двух мантисс, без их предварительного приведения к друг другу по значению порядка.

Это занимает

Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used
52/64 (82%) 136/224 (61%) 39/64 (61%) 17/33 (52%) 68/160 (43%)

Синтезатор рассчитал максимальную частоту работы устройства: 49,751 МГц

Это, в принципе, совсем не плохо. И есть еще пространство для маневра.

P.S. Продолжаю "кумекать" дальше.

А почему при загрузке по DMA придётся грузить байтами, когда 16 битная передача там тоже есть, особенное если это Flexible Static Memory Controller, а ПЛИС будет брать из памяти с 16 битной шиной данных, параллельная загрузка по два байта это должно быть очень быстро !

Схема Микроконтроллер <==> Статическое ОЗУ <==> ПЛИС. Если это спец. ОЗУ для обмена с ПЛИС, то оно может быть небольшим. Зная что ПЛИС не занята, контроллер наваливает данных в ОЗУ и сигналит ногой мол "поехали!". ПЛИС всё делает и сигналит ногой "приехали!". Контроллер забирает результаты опять же через 16 битную параллельную шину и все довольны ???

По поводу 1E8 и 1000E0 - это ж вопрос парсинга, после ввода числа приводятся к необходимому виду. Если это происходит при редактировании программы, то в программе она уже будет 1E3, то же самое при вводе в регистр и другую память. При чём тут момент вычисления ?

Да ПДП можно и словами, безусловно. Я думал про реализацию байтами на тот момент когда писал, но ничего не мешает шпарить словами. Только одно "но" - сигнала SYNC на выставление нового данного не будет и тогда сопроцессор на CPLD вынужден работать синхронно с МК, что бы разностью фаз синхронизации не "порвать" данные.

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

По поводу 1E8 и 1000E0, а вот так эти числа хранятся в памяти МК-61, поэтому перед передачей в сопроцессор их придется привести к виду 1Е8 и 1Е3, иначе результат вычислений будет неверный, ну и после выгрузки из сопроцессора привести обратно к виду к которому все привыкли в МК-61. Вот и при этом момент вычисления в МК.

Зачем ориентироваться на устаревший формат МК-61? В МК-161 уже предложен новый формат, где старшая тетрада отлична от нуля (для ненулевых чисел) и таких глюков больше нет:

http://mk.semico.ru/d1_p5.htm#d1_5_3_8

Всякими 1E8 и 1000E0 занимается подпрограмма вывода десятичного числа на экран.

каких то чувств к МК-161. Задача минимум - повторить МК61.

Если ПЛИС будет иметь интерфейс ОЗУ, то обойдёмся без него, только у CPLD памяти мало, чтобы хранить программу и операнды.

В CPLD нет памяти совсем. В MAX-II есть последовательный флеш очень неудобный но ОЗУ нет совсем.

мало но есть, на 4 уровня стека бы хватило 256 ячеек ? :-)

брутально было бы. :)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

хватило бы на 16 уровней стека :)

Я уже 4 разных схемы обсчитал по ускорение BCD, что характерно:
а) не лезет в xc2c64 даже если половину работы делает МК
б) мало того 13 тактов msp430 на суммирование пока не удается побить, а это значит что внешний сопроцессор должен делать приведение мантисс самостоятельно.

Взять можно только частотой, но учитывая что из применения ПДП CPLD становится синхронной с МК, то и этого козыря нет. Если их десинхронизировать то понадобиться механизм квитирования приема от МК, чего опять же нельзя реализовать при помощи ПДП.

Какие отсюда мысли - "забороть" msp430 на BCD суммировании можно только если регистры во власти внешнего CPLD/FPGA и это МК получает их от сопроцессора, а не наоборот. Все это слишком монстровито выглядит. Буду еще кумекать какие есть перспективы.

Предлагаемое аппаратное BCD-умножение основывается на вот таком элементарном «умножителе»:

s4..s0 := a3..a0×b0

Как его реализовать? Делаются два ПЗУ на 100 разрядов с таблицей умножения: младшая цифра ROM [a,b0] и перенос ROMσ [a,b0]. Например ROM [9,9] = 1, а ROMσ [9,9]=8 в полном соответствии 9×9=81. (Можно наколдовать восемь логических функций от 8 бит вместо честных ПЗУ, не суть важно.)

Потом ставятся в ряд шесть десятичных полусумматоров, трём из которых даже не обязательно вычислять σ — перенос в следующий разряд (см. ниже замечание про Σ'). Ну или двумя полусумматорами обходимся, протаскивая через них всё за четыре такта.

s0 := ROM[a0,b0]
s0σ := ROMσ [a0,b0]

s1, σ1 := Σ (ROM[a1,b0], s0σ)
s1σ := Σ' (ROMσ [a1,b0], σ1)

s2, σ2 := Σ (ROM[a2,b0], s1σ)
s2σ := Σ' (ROMσ [a2,b0], σ2)

s3, σ3 := Σ (ROM[a3,b0], s2σ)
s4 := Σ' (ROMσ [a3,b0], σ3)

Поскольку полусумматор Σ складывает две цифры (максимально 9+9=18), его переносы σ1, σ2 и σ3 могут быть только 0 или 1. Для их передачи достаточно одного проводника, а полусумматор Σ' с ними предельно прост и (т.к. в ROMσ все цифры строго меньше 9) не может приводить к переполнению разряда.

Даже если реализовать в матрице только это, а не полную схему, этот элементарный «умножитель» существенно ускорит умножение процессором bcd-чисел. Конечно же, в рабочем варианте должно быть умножение 12-разрядных чисел минимум. Полную схему можно реализовать программно-аппаратно. Добавив в матрицу сдвиговый регистр с полноценным сумматором и продумав способ не гонять промежуточные результаты в процессор и обратно.

Аппаратные реализации судя по всему доходят до тысяч логических ячеек. Надо конечно курить(копать) дальше.

Наткнулся на формат decimal64. В этом формате 16 разрядов !!! при экспоненте ~+-338. Неплохая точность ? Плотно упакованный формат.
https://en.wikipedia.org/wiki/Decimal64_floating-point_format
О плотной упаковке:
https://en.wikipedia.org/wiki/Densely_packed_decimal

Вот здесь есть вся реализация
https://github.com/semihc/qdecimal

Аппаратная реализация таких плотных штуковин бы была просто убойной фичей !!! В сети есть статьи на эту тему, правда, как я уже сказала, у них там FPGA и тратятся тысячи ячеек. Проскакивали какие то поточные реализации, может в них меньше будет тратиться ????
Удобно тратить на одно высокоточное число всего 8 байт, а ещё есть и двойной точности 16 байт. Это же праздник для калькуляторства !!! МК-161 был продвижением в своё время, неплохо бы улучшить результат по точности :-)

Как по мне, так dpd больше формат для хранения. Он основан на том, что 1024≈1000, значит три десятичные цифры можно «плотно» упаковать в 10 бит, а не 12 как в bcd.

Можно попробовать, конечно, реализовать арифметику напрямую в dpd. Но пока что занимайтесь этим сами. Каллисто-2 ещё завязан на bcd, т.к. предназначен выжать последнее из МК-161 (где bcd в прошивке), победив Каллисто 1.0 по производительности.

Я думаю он основан на том в 4-х битах можно хранить больше 10 комбинаций. По поводу арифметики, я и не настаиваю. На 8-битных платформах с упакованными бороться будет слишком накладно.

У десятичных чисел три уровня упаковки:

  1. Неупакованный или символьный. Когда в 1 байте одна цифра, в 4 младших битах. Именно эта мерзость родная на msp430, если я правильно понял digitalinvitro.
  2. Упакованный. Когда в 1 байте две цифры, в старших и младших 4 битах по цифре. Именно это и есть то bcd, что используется в МК-61, МК-161.
  3. Плотно упакованный (dpd). Когда деление на байты игнорируется, и в каждые 10 бит (0…1023) засовывается по 3 цифры (000…999). Действительно перспективный формат, но сложнее в реализации.

Обычные упакованные мы давно и успешно используем, никакой борьбы. А вот плотная упаковка — дело будущего. С радостью бы занялся ею прямо сейчас, но это оторвёт меня от Каллисто и прошивка к моменту готовности оборудования готова не будет.

Самая бескровная реализация dpd на существующих технологиях это распаковывать их в bcd при считывании из регистра (ИП) и запаковывать обратно при записи (П).

На месте Новосибирска я бы прямо сейчас это и реализовал в прошивке «Электроники МК-161». АЛУ у них 14-разрядное, а регистры всё ещё 12-разрядные.

12 разрядов мантиссы в bcd это 48 бит, которые используются плохо. В эти же 48 бит идеально укладываются четыре dpd-упаковки по 3 цифры и две bcd-тетрады на сдачу. Получается, МК-161 прямо сейчас может начать хранить в своей тысяче десятичных регистров полноценные 14-разрядные десятичные числа, которые до сих пор использовались только в стеке.

Жаль, гражданин Степанищев испортил отношения с сообществом и стал «страшно далёк» от народа, уйдя с сайта Арбинады. Получил бы отличный апгрейд своих легендарных устройств, реализовав в своей закрытой прошивке нашу «очередную хотелку».

Думаю лучшим применением будет использовать эту плотную упаковку в более сильных машинах и ПЛИС, на МК-161 конечно достаточно будет упакованного формата, хотя для хранения в долгих ящиках может быть стоит и плотный реализовать. Лучший апгрейд этих устройств был бы их тотальный ремэйк в новом корпусе, новом типе клавиатуре, новом микроконтроллере и экранчике, но на это у них уже ресурсов и мотивации нет, распродают последнее по цене, обеспечивающей покрытие предыдущих расходов. Для СЕМИКО игра закончена. Зато я вижу начало игры в образовательной сфере и робототехнике. TI например выпустила вот такое
https://education.ti.com/en/products/micro-controller/ti-innovator-rover...
Версия МК-161 выглядела бы интересно. Я работаю над версией для CASIO Prizm. Неплохо было бы завершить это дело ещё отечественным калькулятором и реализовывать в робототехнические кружки и классы.

Предложенное умножение использует два ПЗУ на 100 4-битных значений — которые можно заменить подобранными логическими функциями, конечно.

Если мы хотим вычислять 8 разрядов одновременно, придётся делать 16 таких ПЗУшек — 1600 тетрад во сколько ячеек транслируются? В случае поразрядного вычисления будет в 8 раз медленней, зато всего два ПЗУ.

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

Вот примерно столько ячеек и надо. Но в таких случаях используют встроенную или внешнюю память. А почему нельзя это в флеш микроконтроллера разместить? Чем не ПЗУ уж 2 то Кб там всяко найдется.

В ПЗУ 8051 или другого мк это заняло бы 200 байт. Там не надо размещать ПЗУшки параллельно, т.к. параллельных вычислений для каждого разряда всё равно не сделать.

Идея была помочь в реализации аппаратного умножения, чтобы «ускоритель» действительно его ускорял.

Если 16 ПЗУ по 100 терад каждое (50 байт х 16 = 800 байт) - на каждую тетраду 4 триггера, то поступить можно двумя способами

а) использовать блочную встроенную память, она двухпортовая, таким образом в 1K/2К BRAM можно уложить две таблички. Всего 8 BRAM не сказать что бы это было ужасть как много, но это точно не CPLD, а уже полноценная FPGA. Например xc3s200 (Spartan-3). Можно подыскать что-то из Altera. Стоимость будет в районе 1000 рублей с инфраструктурой из конфигурационного ПЗУ и стабилизаторов напряжения.
б) использовать disrtibuted memory поостроенную на LUT, тогда пойдет xc3s50, правда окажется она не многим дешевле пункта а. В случае с Altera можно воспользоваться CPLD MAX-II имеющих LUT как в FPGA вместо макроячейки. В самом маленьком MAX-II имеется 240 LE's, а это значит 240 триггеров, следующая MAX-II имеет 570 LE's и как видите их обоих не хватает. Идти дальше по номенклатуре MAX-II не имеет смысла поскольку EPM570 стоит в районе той же 1000 рублей, что и FPGA. Единственным преимуществом CPLD является готовность по включению, так как FPGA еще требуется заливка "битстримом" из конфигурационного ЗУ.
в) использовать внешние 32 р-р ПЗУ (8 терад с линейной шиной адреса, так что бы емкости его хватило на 8 таблиц. Адресация 100 значений (адрес для 0x64 - 6 бит) внутри адреса происходит группами по 6 бит на каждую таблицу. Но думаю что ПЗУ с линейным адресом в 6*8 =48 р-р не существует. :) Ну 18 (6х3) р-р (на 256х16) то точно существуют. Тогда 3 таких ПЗУ заменяют набор из 3 таблиц. Для 16 таблиц соответственно 6 таких ПЗУ. Управлять ими с CPLD попроще и подешевле. Если хотелось бы снизить кол-во ПЗУ применять мультиплексирование и работать с 1-2 ПЗУ, либо искать 32 р-р ПЗУ.
г) Опять таки воспользоваться память МК и несколькими каналами DMA в принципе 8х1байт или 4х2 байта каналами, а то даже и 2х4байта каналами. Но поскольку версионность хранения выросла (тиражирование информации аж 1 к 8) то понадобится приличный флеш в самом МК. Этот вариант пока исключительно умозрительный, подразумевающий что из МК информацию можно выводить не по средством вычислительного ядра а при помощи ПДП механизма, либо при помощи механизма обращения к внешней памяти.

ПЗУ нужно для аппаратного умножения тетрад. Итого адрес это 4+4 бита (две перемножаемые тетрады), а результат это 4+4 бита (две цифры результата).

От этого уже отталкиваются два более крупных вложенных блока — умножение 8-разрядного целого на тетраду и умножение этого же 8-разрядного целого на другое 8-разрядное целое.

1. Внешнее ПЗУ не подходит, т.к. умножение всех 8 тетрад на один и тот же 4-битный множитель происходит одновременно. Если каждой тетраде придётся стоять в очереди к внешней шине, параллельного умножения не получится и достаточно будет одной внешней таблички умножения, ПЗУ 8x8.

2. Существуют шаблоны для реализации ПЗУ в FPGA. Для данного приложения схему можно оптимизировать. Например, если на входе ПЗУ стоит дешифратор, нам не обязательно транслировать 4 бита тетрады в 16 колонок — достаточно реализовать десять. Из 256 возможных комбинаций на входе адреса для нас важны только 100.

3. Для умножения тетрад вообще не обязательно тащить всю схемотехнику ПЗУ. Таблица умножения десятичных цифр хорошо известна, можно расписать и оптимизировать логику. Например, последний бит (чётность) зависит только от двух последних битов перемножаемых тетрад. Его совершенно необязательно записывать в ячейки ПЗУ. Можно посидеть и расписать на чистой логике остальные 7 бит этой основной ячейки bcd-умножения.

Первое - 100 тетрад, 100 тетрад это 100 значений или 6-битный адрес. 4-х битный адрес это 16 значений.

1. По ПЗУ я предлагал 32 бита в параллель, сколько в 32-х битах тетрад? Именно 8 штук. Две 32-х битные ПЗУ - 64 бита, или 16 тетрад. Что тут не правильно?

2. Про шаблоны реализации ПЗУ в ПЛИС я вроде бы все написал, более добавить нечего. Либо это блочная память, либо distributed ram. 4 бита то зачем дешифровывать? Подача адреса в ПЗУ не требует его дешифрации. Если для нас важны 100 и 256, так все еще хуже потому что 256 значений это 8 разрядный адрес.

Грубо говоря если мы перемножаем табличным способом две тетрады - то в адрес ПЗУ подставляется - 8 разрядов!!!!!! A x B = MUL_TABLE[A<<4 | B]. Если Вы хотите каким то образом сузить 8 разрядов до 6 то скажите мне что это за метод кроме табличной шифрации, опять же построенной на ПЗУ с входным 8 р-р адресом и выходным 6 р-р.

Всё просто, т.к. это обычная школьная таблица умножения 10x10. Сложности могут возникнуть лишь оттого, что обращение к ней идёт из двоичной системы счисления, точнее из bcd.

Индексация таблицы умножения проводится двумя тетрадами. Это 4 бита — но лишь 10 значений из 16 имеют смысл. Итого получаем 8-битный адрес. Но из 256 клеток таблицы 16×16 заполнены только 100 клеток 10×10.

1. Если делать одно огромное внешнее ПЗУ, адрес должен содержать все 8 тетрад множимого a7..a0 и ещё одну тетраду множителя b0. Итого 9×4=36 бит адреса, по которому считывают 8×4×2=64-битный ответ. Восемь ПЗУшек по 64 Гигабайта каждая — плохое решение. Более экономное 36-битное ПЗУ заменит сумасшедшей таблицей всю логику, отвечающую за умножение 8-разрядного bcd-числа на тетраду.

Но можно поставить восемь отдельных ПЗУшек (по одной на разряд) с одинаковой прошивкой, но раздельной адресацией. Каждую адресуют две тетрады множителей a и b0, в каждой по 100 заполненных байт из 256. Из каждой такой ПЗУшки считываются две тетрады (8 бит) — умножение соответствующего разряда множимого a7..a0 на общий множитель b0.

2. Да, 8-битный адрес. Перемножаются два 4-битных числа. Но всего может быть только 100 комбинаций. Остальные комбинации могут быть на входе только в теории, обслуживать их не обязательно.

Можно, конечно, сделать преобразователь из 8 бит в 6. На мой взгляд, это только усложнит конструкцию.

Возможно, проще вместо ПЗУ написать программу, которая сгенерирует в нужном базисе и оптимизирует восемь булевских функций (в моих обозначениях перемножаются тетрады aN и b0, младшая тетрада произведения в ROM, старшая в ROMσ):

ROM.0 := f0(a.0, b0.0)  (* чётность результата зависит лишь от чётности сомножителей *)
ROM.1 := f1(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)
ROM.2 := f2(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)
ROM.3 := f3(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)

ROMσ.0 := f4(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)
ROMσ.1 := f5(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)
ROMσ.2 := f6(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)
ROMσ.3 := f7(a.0, a.1, a.2, a.3, b0.0, b0.1, b0.2, b0.3)

1 и 2. Именно потому что адрес 64 бита - это просто сверх гигантский объем, именно поэтому и говорил Вам о том, что его можно уплотнить в 6 бит, а потом подать уже 6х8 = 48 бит на ПЗУ. Понятно что никто этого делать не станет в здравом то уме. Но возможность такая существует.

3. Говоря о табличном умножении в одном разряде Вы забываете то, что получаемый результат - 2-х разрядное BCD число, а это все таки 8 бит на выходе. Эти 8 бит надо сдвинуть относительно предыдущего результата, сложить и учесть пернос в следующий разряд. И это сделать параллельно всему остальному не получится, так как сложение в этом случае последовательная операция, а точнее 8 таких операций. Так какой тогда смысл делать параллельное сложение?

3. За один такт считываются все значения из таблиц умножения — дальше они не меняются. Все значения на входах и выходах из ПЗУ заморожены. За второй такт двух-разрядные числа из таблиц умножения просуммированы, в том числе получена первая информация по переносам. Это и есть наша твёрдая экономия.

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

Согласен, проще не умножать все разряды параллельно, а делать это последовательно. Это сильно сэкономит число ячеек на ПЗУ, вдобавок не надо геройствовать на переносах. Просто потом будет ещё один внешний цикл, по тетрадам второго сомножителя — и его уже не избежать. Получится N² по времени вместо N. К счастью, это всё равно быстрее CPU.

Описание сложения табличных значений действительно было запутанным. Теперь всё просто, см. пункт 2. Там обычное сложение двух многоразрядных чисел, считанных из ПЗУ, проверил на Обероне. Делать сложение с быстрым переносом, многотактовым или поразрядным — на вкус реализатора.

Арви, да можно залепить такой BCD - но это уровень FPGA, либо очень большой CPLD с внешней памятью и это уже без дураков очень дорогое и довольно жрущие изделие.

Я бы хотел что бы Вы как и я подумали о следующем. Вот есть у нас STM3L4 и есть MSP320FRxxx и есть малопотребляющая, дешевая и легко доставаемая CPLD xc2c64A. Нам надо выяснить будет ли эффективна связка msp430fr+C64 или связка stm32l4+C64 по вычислительной способности (скажем сколько сложений 8 р-р BCD чисел в секунду) и затрачиваемой энергии на это (сколько mA на сложение). Для C64 я уже сделал все что наверное мог, там хоть и осталось с десяток макроячеек и триггеров, но скорей всего улучшить уже не удастся.

Что меня удручает - то что msp430 сверх эффективно работает с BCD и просто сумматором BCD его не заткнуть. Остается выяснить как эффективно msp430 не только складывает но и приводит к нужному порядку мантиссу. Как я это вижу - упакованная мантисса находится в памяти (два 16-р-р слова на 8 разрядов), отдельно параллельно хранится порядок (что бы доступ по индексу к мантиссе и порядку был эффективен). Так вот далее необходимо произвести действия с порядком - выяснить его разницу со знаком, что бы понять какую мантиссу относительно какой двинуть. Как Вы уже заметили движение мантиссы удобно выполнять изменением указателя на нее, но а) такая возможность существует при сдвиге кратном 8, а вот при кратности 4 придется додвигать мантиссу побитно б) сдвиг на байт не гарантирует лидирующих нулей в мантиссе и необходимо хранить мантиссу с ведущими нулевыми 8 разрядами. Вот такой алгоритм надо разложить в команды msp430 и посмотреть что дает нам применение C64. Не забыть при этом что загрузку-выгрузку С64 надо организовывать сверх-технологично при помощи ПДП (а это еще та задача). Но хотя бы посмотреть во что обойдется сдвиг мантисс. У меня стойкое ощущение что msp430 мы проигрываем в скорости сложения 8-р-р BCD чисел. Тогда вопрос как при помощи C64 организовать ускорения умножения и деления, заставить msp430 заниматься вычислением слагаемых - которые C64 будет складывать возможно менее эффективно, но зато параллельно. И возможно имеет смысл точно так же обдумать вычитание, так как для BCD чисел сложение в дополнительном коде это не просто поразрядная инверсия и тут может быть выигрыш с C64.
Для STM32L4 вообщем то ясно что даже просто загружать C64 записью в порт и чтением из порта забирать результат будет эффективней чем считать на самом STM32, причем на любой частоте.

Ну вообще надо честно признаться, что удовольствие от творчества в данном случае - это и есть главный мотиватор проекта. Зачем нужен калькулятор, когда их и так дофига всяких разных ? Патриотизм тоже и синдром Not Invented Here, но главным образом - удовольствие от творчества.

В этой ситуации я думаю "скоро всё должно заработать", это как раз гораздо лучше, чем готовая и относительно качественно сделанное изделие от СЕМИКО "когда нибудь (через 1000 лет) сделаем лучше, а сейчас хавайте что дают".

Для того чтобы результаты всё таки были мы начнём разбивать проект на ряд мелких задач:
1) Вычислительный сопёр на CPLD или FGPA - это довольно компактная самодостаточная задача.
2) BCD для STM32 (и других микроконтроллеров попутно)
3) Форт(или подобие) на SMT32
3) Разговор с экранчиком.
4) Опрос клавиатуры
5) Изготовление платы клавиатуры и ответной части корпуса с кнопками, нанесение надписей (технология создания корпусов и клавиатур).
7) Изучение технологии литья корпусов и клавиатур из двухкомпонентных пластиков, (литьё силикона) изготовление силиконовых форм.
8) Создание окончательного проекта платы (плат) с экранчиком и креплениями в корпусе.
Батарейные держатели (аккумулятор ????) Разъемы для периферии и т.п.
9) Производство N экземпляров для заинтересованных лиц.

Это примерные задачи

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

Согласен, надо начать именно с последнего пункта. Но только надо уточнить, что именно предлагается в последнем пункте. Похоже, в ветке собралось в кучу несколько хотелок, как минимум, три: 1) самодельный калькулятор "высококачественного вида", 2) Форт и 3) ПЛИС сопроцессор/процессор.

Вангую, что наберется 5 человек, не больше

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Для реализации любого клона МК-61 :)

:)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Я так понимаю, что вы хотите создать обновленный "клон" МК-61. Допустим с таким же количеством регистров, уровней стека, шагов памяти, но не обязательно эмулируюя прошивку оригинального МК-61 ? Думаю насчёт BCD можно попробовать сишный вариант, не знаю на сколько он оптимален, если не ошибаюсь, то всякие функции реализуются на основе десятичного формата через ряды и т.п. ? А если делать более жирный вариант, то это будет просто один из режимов "большого" калькулятора.

Видите ли у нас уже есть эмулятор МК-61, и он прилично быстрее своего аналога на К145. Но по прежнему медленней чем МК-161, при этом там уже нечего оптимизировать и некуда задирать тактовую частоту :) Опять же таки даже разгон в 10 раз не даст возможности обойти МК-161. Вот отсюда стремление сделать на основе BCD арифметики уже симулятор платформы МК-61, в сотни раз быстрее.

Сишный вариант: не видел библиотек не под msp430 не под stm32 основанных на BCD арифметике.

Конечно, можно сделать МК-61 со скоростью МК-161. Но с теми ресурсами (105 шагов, 15 регистров) эта скорость останется невостребованной.

Хорошая скорость требуется именно для ПМК поколения МК-161, где задача по компилированию экрана (48 строчек по 64 символа) может занимать минут 15. Таких задач у МК-61 не так много.

Вообще-то я имел в виду, что задумка уровня МК-61 не так плоха. Ведь фактически мы не выпустили ещё ничего даже такого уровня. Кстати я бы не прочь завести "клячу", которая может обгонять автомобили, на работу бы на ней ездил :-) По сути в плане последовательных приближений МК-61 как бы вложен в задачу МК-161, а некий МК-252С с символьным программированием включает то что умеет МК-161. Так что всё ОК с клячей :-) Я правда не уверен что надо париться с 8051 и MSP430, лучше сразу тратить свою жизнь на 32-битные платформы, которые по энергоэффективности уже отлично дозрели.

говорил о том что возможностей косвенной адресации МК-61 достаточно и даже более чем достаточно. По программной памяти, никто не мешает все это расширить как угодно. Метками ли, Шитым ли кодом глубиной в две BCD тетрады, либо еще как то. МК-161 это не флагман, может быть для Вас разве что? И если хоть что то у меня будет получаться индекс X61 оно никогда не получит.

Во-первых, на этих штуках (ПМК-образных) можно сделать куда больше чем на "ардуинах", а на "ардуинах" сотни тысяч людей набрались. Какой то круг пользователей есть у "Марсохода", у такого аппарата он будет больше, потому что тут HDL часть не главная.
Во-вторых, не нас...ть ли сколько там наберётся ? Зачем вообще массовка нужна ? Производим, программируем и конфигурируем ТО ЧТО НАМ ХОЧЕТСЯ, вплоть до того, что каждый может распечатать себе персональный корпус: один в виде МК-161 (для суровости), другой в виде R2-D2 потому что фанат "Звёздных Войн", третий в виде DM-42, потому что нефиг им одним рулить :-)
Договоримся за формфактор плат и расположению основных кнопок на относительно универсальной клавиатуре и порядок, не хочешь как все, лепи как на душу ляжет !

Касательно прошивки. Делаем поддержку BCD в железе, поддержку BCD программную. Делаем или адаптируем Форт среду, а кто то может уже свернуть на этом этапе. Рисуем на ней что надо, обмениваясь общими моментами.

У Ардуин очень низкий порог вхождения, стоят копейки, среда разработки вылизана до уровня "обычного домохозяина". Поэтому там и сотни тысяч, если не миллионы, пользователей, библиотеки есть под что угодно и шилды есть кто во что горазд. У меня на Ардуине-УНО через Ethernet светом дома управляет сервис www.blynk.cc

Как можно с ними сравниваться?

А массовка нужна, если не для того, чтобы покупали по дешевке изготовленные в Китае платы и напечатанные корпуса (скажите еще, что нас#ать на деньги?), то хотя бы для того, чтобы наполнять общественный гитхаб софтом.

З.Ы. Если напомните мне я не забуду, то вечером выложу фотки и видео около-калькуляторного шилда для Ардуино-НAHO, который я паял редкими свободными вечерами, пока энергия, как обычно, не рассеялась в гудок энтропиях обыденности. Потому что нет массовки...

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Не хотите высоко порогово входить, программируйте на встроенном языке (я думаю мы тут небольшим числом ЧТО-ТО уже напишем), хотите хардкора, программируйте CPLD сопроцессор или прошивку (помогайте или форкайте свою). Не вижу проблем с порогами. От слова ВООБЩЕ! Можно даже на Ардуино среде это и прогать.
Доверять управление электроприборами в своём доме какому то левому сервису - ЭТО АДСКАЯ ЖЕСТЬ !

Я лично столкнулся с некоторой глючностью ардуиновского компилятора, после чего и думать забыл ардуину в станок ставить.

Они дохнут и глючат

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Разве там не gcc ??? И кто мешает писать прошивку на IAR ? Даже самые чудики не пишут для станков на самих библиотеках Arduino, они нужны чтобы диодиком помигать ну или какие то простые вещи сделать. Написаны крайне толсто и криво, работают медленно и глючно, это всем известно. GPIO в Ардуино библиотеке работает в 100 раз медленнее, если рулить ногами вручную !

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

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

Вот обещанный около-калькуляторный шилд для Наны.

З.Ы. Blynk очень крутой сервис. Но, конечно же, я не доверяю ничего важного онлайн сервису - ардуина на другом конце включает выключает свет и меряет температуру с влажностью. Максимум, что смогут хакеры - включить 40 Ватт светодиодного света, пока я вечером не замечу это, придя домой :)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Разница в том, что я на каком то уровне сам ВСЁ МОГУ, пускай во многих местах по урюпински. Зато никто не может сказать, что за его счёт кто то предлагает что то делать. Не предлагаю. Я делаю потихоньку и ищу попутчиков, чтобы по пути можно было интересно пообщаться, а не напрашиваюсь в пассажиры.

Не надо клавиатуру делать специализированную сразу, по большому счёту они все одинаковые. На этом рушатся все ваши остальные доводы. Не надо делать входной (юзерский) язык один и директивно заставлять на нём только программировать. Повторяю, если вы не прочитали моё предыдущее сообщение: НИЧЕГО НЕ НУЖНО, ВСЁ И ТАК УЖЕ ВЫПУСКАЕТСЯ по вполне доступным ценам!!! Есть и сопроцессоры и Форт процессоры, и ПМК всякие разные, и ПЛК. Для чего вы эту шарманку НА ЭТОМ САЙТЕ заводите не понятно, типа вы деловой человек, не терпите пустых разговоров, бизнес надо делать, а тут облом-с, бизнеса не получится, сопроцессор гадский и Форт всё портят :-)

На этом сайте тема "Изобретем микрокалькулятор" поднималась раза три минимум, поищите, ознакомьтесь с историей вопроса, чтобы не повторяться.

Задача №1 - получить готовую аппаратную платформу под программируемый калькулятор с возможностью простой перепрошивки силами неспециалиста в "железе". Чтобы написать под неё все ваши "хотелки". Пока эта задача не решена, все уходит в пустые разговоры.

В отличие от уходящего в свисток пустопоржнего трепа про патриотизм и прочее "импортовозмущение", швейцарские и многие другие коллеги с "загнивающего Запада" такие платформы уже делают.

Зная реалии, я просто предлагаю пойти стандартным "совково-китайским" путем и скопировать какую-то готовую разработку "загнивающих".

В качестве аппаратной платформы, на мой дилетантский взгляд, наименьшим злом будет одна двухсторонняя платка, с одной стороны простенький арм с микросхемой памяти и сигнальной/питающей обвязкой, с другой стороны - тактовые кнопки и ЖК COG дисплей, чем проще, тем лучше, питание - маленький литиевый аккумулятор. В идеале - запредельно нищебродский вариант на ворованных китайцами детальках с алиэкспресса. Как я уже писал, даже в РФ за четыре тысячи рублей можно десяток платок заказать, это с лихвой хватит на всех участников.
Главное-прошивка, без программы будет кирпич вместо аппарата, но я в программировании чайник, я калькуляторную прошивку точно не осилю.
В качестве языка предлагаю обратную польскую запись оставить, чтобы не возиться со скобками.

Мне не удалось найти приемлемых вариантов по экранчикам. Только e-Ink, они дороговаты, но как раз соответствуют задаче энергосбережения. Я предлагал поступить извращённей и пока не откажусь от первоначального плана. Взять готовые платы, приделать плату с клавиатурой SMD мембраны или низкопрофильные кнопки, и какими то вспомогательными вещами (слот для SD карты) ? Вероятно хватит чуть ли не односторонней платы сделанной ЛУТом на коленке.
Экранчик также модулем. И вклячить всё это в пластиковый печатный корпус, где толкатели будут висеть как в DM42 и HP Prime на паре "усиков" над тактовой кнопкой. Профит.
Очевидный плюс в том что не надо ждать 1000000 лет пока кто то разведёт плату, закажет и установит компоненты, плату же клавиатуры любой криворучка сможет изготовить на левой или правой коленке по выбору.

Вот исходник с прошивкой простого самодельного калькулятора на микроконтроллере PIC16F873 и ЖК индикаторе HY-1602B3, описанного в статье журнала "Радио" восемь лет назад.

Материалов, как видно не мало, надо сконцентрироваться и победить минимально калькуляторную часть с BCD и математическими функциями.
Если не ошибаюсь HY-1602B3 это обычный алфавитно-цифровой экранчик на две строки. А я имел в виду, что хотелось бы графический экранчик трансфлективный и чтобы в высоту был пикселей 90 хотя бы, а самые ходовые в ужасных корпусах продаются на 64 пикселя. В комплектации экранчиков (и вообще компонентов) я ничего не понимаю, не знаю правильной логистики и т.п., может быть этот вопрос яйца выеденного не стоит все заказывают в Digikey как тот швейцарец ???

Экран в DM42, скорее всего, из Дигикей, просто швейцарец берет сразу очень много оптом. Экран в DM42, пожалуй, лучший из графических монохромных LCD, что я видел

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Ну для динамических вещей может быть тот экранчик хорош (хотя на HP 42 трудно представить видеоигры), а так мы ещё поспорим, мне кажется e-Ink перспективней для малого потребления и контрастней должен быть. К тому же e-Ink стали выпускать с несколькими цветами, это очень удобно. Оси рисует цветом, а график чёрным, или наоборот. Быть может они пойдут 3-х цветные.

двухцветные было бы совсем круто

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Честно говоря, мне глубоко чихать на счётчик поднятия тем. Сомневаюсь, что вопрос ставился так же как сейчас, иначе бы я в поиске вышел на эти темы.

Не надо мне навязывать свои задачи, я вовсе не уверен, что именно "программируемый микрокалькулятор" кому то упёрся в 21-м веке. Задача получить ЛЮБУЮ платформу, похожую на ПМК по стилю, но не обязательно целить в ваш "загнивающий запад" с их клонами HP, делать разрешается всё что угодно. Даже медленную хрень на CPLD без микроконтроллера вообще, никто не запретит сделать, и она ещё будет пользоваться спросом, потому что я не вижу таких в продаже, а поиграть с такой штукой был бы не прочь.

Считаю, что пещерная антисоветщина также убога как и псевдопатриотизм ! Не знаю, что вы имеете в виду, про якобы повальное копирование "загнивающего Запада", но я вот читаю как создавались первые ЭКВМ и путь этот совершенно отличался от копирования. А что скопировано при создании МК-61 ??? Буран такая же "копия" шаттла, как 9-ка жигулей является "копией" фиата.
Один такой "специалист" трындел, что мол "Ну погоди" скопировали вообще лениво мол 1:1, просто мол программисты текстуры заменили (на сегментном то экране!!!).
Швейцарские делают DMы, а американские если что тоже до сих пор делают свои TI и HP и не УЖЕ, а изначально делали и делают и что нам теперь, повеситься что ли ?

И по поводу "пустопорожнего трёпа", вон Арви умножения BCD препарирует, уже псевдокод на пальцах разъясняющий идею выкатил, остальные тоже варианты всякие предлагают и делятся ссылками и документацией, а кто то просто зашёл обвинить ВСЕХ в пустом трёпе, ничего не давая взамен.

Насколько возможно реализовать более сложный процессор на простейшем вроде tinyCPU, который влезет в 256 ячеек CoolRunner-II ? Учитывая что тактовая частота CPLD на два порядка выше настоящего Z80. Может стоит замахиваться на что-то архитектурно более простое вроде MOS 6502?

Считаем, что CPLD соединяется 16 битной шиной с внешней быстродействующей SRAM размером в 256Kb (т.е. хватит и на адресное пространство эмулятора и на сам эмулируемый процессор с его прошивкой и памятью).

Сколько будет жрать эмулятор Z80 или MOS 6502 на TinyCPU и каково будет быстродействие итогового чипа ???? Судя по навороченной формуле в одном из апнотов Xilinx, потребление на предельной тактовой будет сотни милливат, что вполне допустимо для активного режима процессора.

Конечно вы спросите НАК... такое чудо юдо надо ? А может и не надо. Интересно узнать, на что способны эти недорогие CPLD

Z80 на FPGA есть, он занимает 2084 логических элементов — это 11% от Altera DE1 (Cyclone II). Выложен он под свободной лицензией (LGPL).

Z80 намного сложнее TinyCPU и не самый простой в реализации 8-битный процессор.

Вот про это речь?
http://www.bigmessowires.com/cpu-in-a-cpld/

Как видим взят CPLD MAX-II EPM570, 570 - LE's насколько он заполнен не знаю, но думаю процентов на 80. В xc2c256 не залезет. Ну и 2К LE's это конечно очень много, это не для CPLD.

Z80 очень сложный процессор - два набора регистров, реп-команды и самое главное это CISC, т.е. микрокод, а его надо где то хранить.

Если там будет обычное АЛУ - проиграете однозначно.

Если все будет заточено под BCD судите сами
формат чисел 8 + 2 (знаки), значит на хранение нужно 42 бита. На РОН ну хотя бы 4 регистра, а значит 168 триггеров только на РОН. Мультиплексор под это РОН 42х4 сожрет очень прилично, да плюс АЛУ хотя бы на 8 операций. В c256 это не полезет, в EMP570 - может быть. Но главное как работать с BCD регистрами при трансляции их в обычное бинарное адресное пространство, адресоваться то придется к двоичному адресу ОЗУ. Транслировать в BIN при выдаче на адресную шину? Может быть конечно во всем этом сумасшествии что то и есть - но C256 на это точно не хватит. Да и EPM570 пожалуй тоже. Тут есть над чем подумать согласен.

Организовать вычисления так чтобы данные входили и выходили, не хранясь в ряд по 8 тетрад ? В МК-61 тоже была 1 битная шина. Всё таки мегагерц 60 это лучше, чем небольшие мегагерцы в какой нибудь процессоре прошлого.

Чем сложнее процессор - тем ниже его возможная тактовая частота. Если конечно он не конвейерезирован. Но в 256 ячеек, боюсь даже 6502 не полезет, не то что Z80 с его двойным набором регистров. Тут так сказать ничего кроме RISC-а не дано, да причем не просто RISC-а ,а сильно зарезанного.

Ну и с тактовой - два порядка тактовой это только один триггер переключается, а возьмешь мультиплексор 8х1 и вот уже и порядка не будет, а так раза в 3-4.

Недорогие CPLD способны на очень примитивные вещи, скажем что то подобное 8080 - это даже EPM570 не в состоянии обеспечить. Рассчитывать можно только на что-то крайне простое. Как правило это 8 р-р RISC или OISC. Ну и на частоты порядка 10-15МГц без конвейера, и 40-50 с глубоким конвейером.

Невозможно впихнуть Z80 и даже 6502 в 256 ячеек. Предлагалось на CPLD реализовать простой процессор (зато работающий на частоте скажем 80 Mhz), типа tinyCPU, под него написать эмуляцию более сложного, который будет иметь эквивалентную частоту какие то мегагерцы или меньше. За то типа низкое статическое потребление и может быть цена (хотя FPGA уже дешевле этого кул ранера).

Кстати ещё вопрос, в современности какая ПЛИС имеет как минимум 256 ячеек (будем считать это необходимым минимумом), но стоит очень дешёво ? Я тут глянул те же Spartan-6 потребление не высокое, ячеек тысячи и цены уже на сотни рублей идут, а не на тысячи.

Сейчас глянул на Али китайцы XC2C256 (CoolRunner-II 256 ячеек в QFP-100) хотят 613 рэ

XC6SLX4 (Spartan-6 3840 ячеек в TQG144 ногом корпусе) будет стоить примерно 400 рэ
+ конфигурационная память XCF04SVOG20C ~250рэ

EPM240T100C5, правда всего 240 ячеек, но просят всего 540рублей за пять штук, а здесь в микросхему упрощённый микроконтроллер впихнули.

Почти 100 рэ за штуку, это тема. Можно и две штуки истратить.

В 4004 даже операцию AND надо самому реализовывать. Количество транзисторов явно меньше CoolRunner-II с 256 ячейками. Тот TinyCPU из статьи ещё толком не смотрел, чел написал что вроде 120 ил 140 ячеек истратил, так что всё не так страшно. Эмулировать то Z80 не надо, смысл то в том, чтобы именно калькуляторную арифметику реализовать на таком дохлом "процессоре", как когда то смогли реализовать на МК-61 под однобитную закольцованную шину. И чтобы жрало электричества поменьше, особенно в ожидании.

То есть Вы хотите BCD арифметику и какой то набор операций с ней?

Так ведь в msp430 есть команда DADD - для BCD сложения. BCD вычитание с такой коамндой дело техники - довольно просто дополнить до "9" и сложить.

На чем выиграть?
Только на сложении двух чисел с 8 разрядной мантиссой и 2 разрядным порядком за пару тактов?

Но тогда РОН в этом процессоре - регистры для хранения 8+2 р-р BCD. Очень жирный АЛУ! Не понятно как адресоваться такими регистрами в двоичном адресном пространстве забортного ОЗУ. Все операции будут над BCD.

аж до 7 регистров РОН и десяток команд. Но MAX-II потребляет значительно больше чем CoolRunner. С64 например стоит - 190 рублей уже с кварцевым осцилятором, и впихнуть туда супер примитивный процессор тоже возможно из 4 команд и самомодификации кода для наращивания возможности доступа в ОЗУ. Но этим не заткнуть за пояс msp430/STM32. Чем это лучше будет микроконтроллеров? Оно даже потреблять меньше не будет. А вот геморроя с такой системой команд будет предостаточно!

Хотя кто его знает. Может быть в дальнейшем появятся дешёвые, но ещё более низкопотребляющие ПЛИС с малым количеством ячеек, тогда и получится заткнуть. Тут расчёт был на низкое статическое потребление и нативную поддержку BCD в таком "процессоре". Кроме того интересный "инженерно-исследовательский" проект, в терминологии Серегея Тарасова, но он правда видимо интересуется только своей Рапирой. :-) Реально я вижу только STM32 в качестве первого средства реализации, но остальные идеи тоже нельзя так просто сбрасывать со счетов.

требует еще и конфигурационное ЗУ. Время инициализации не микросекунды, а десятки миллисекунд. То есть на время выключать не вариант, а CPLD готова сразу по включению. Спартан 6 будет кушать дай бог.

Симулировать конечно можно любую систему команд. Как только при этом опередить тот же msp430? Ну заведется что то на 80МГц, что то черезмерно простое, на реализацию команды Z80 уйдет прилично тактов, ну например 4-5 на доступ к памяти и какое то действие с этим операндом. Но как это может превзойти хотя бы msp430 на частоте 25МГц или тот же STM32L4 на частоте 80МГц?

digitalinvitro wrote: Симулировать конечно можно любую систему команд. Как только при этом опередить тот же msp430? Ну заведется что то на 80МГц, что то черезмерно простое, на реализацию команды Z80 уйдет прилично тактов, ну например 4-5 на доступ к памяти и какое то действие с этим операндом. Но как это может превзойти хотя бы msp430 на частоте 25МГц или тот же STM32L4 на частоте 80МГц?

Алексей, я получаю извещения о новых постах в этом обсуждении с некоторым содроганием :) Возможно я ошибаюсь, но маниловщина оказывается неистребима и вместо конкретных шагов по созданию конкретного изделия, т.е. сугубо инженерно-исследовательского проекта, начинается конструирование воздушных замков. Я также начинаю лучше понимать, почему групповые опенсурсные проекты в своей массе быстро превращаются в тыкву, тогда как индивидуальные живут десятилетия не снижая уровня качества.

Нытье по поводу замков продолжается. А меж тем разница в том, что одни что то обсуждают, мало ли какие варианты могут прийти в голову, а Сергей осуждает их за это, но не видно чтобы Сергей сам что то делал в этой области. Я понимаю, если бы у Сергея была бы реализация Рапиры под STM32 и он бы подгонял мол "ребята, мне нужна BCD арифметика и работа с периферией".И вообще, зачем кому то что то делать в этом проекте, если интереса не будет ? Ваш "чисто инженерный подход" работает только за бабки, а их никто не предлагает.

Вот как раз ими то я и занят. Первым шагом мне необходимо было выяснить сколько тактов займет сложение с использованием аппаратного ускорения встроенного в современные микроконтроллеры. Как вы уже догадываетесь таких архитектур ровно одна - msp430. Это так скажем актив который мы в данный момент имеем в руках, и можем выдавливать из него какие то результаты по BCD арифметике. Вот такое исследование я провел и выяснил что для сложения 8+2 bcd без учета знака характеристика затрат процессора лежит в интервале от 23+9+12 = 44 тактов до 26+9+29+15 = 79. Нам необходимо ответить на вопрос стоит ли заниматься аппаратной акселерацией и при каких условиях это становится по настоящему выгодно. STM32 я заранее отмел потому что суммирование для 8+2 BCD числа на этой архитектуре вчистую проигрывает msp430.

Для аппаратной акселерации я по началу высчитал расход в 24 такта максимум, но возникли проблемы я не учел округления при сложении наименьшего числа к порядку наибольшего. Учел совершенно недавно и выяснил что аппаратная реализация сложения с округлением меньшего слагаемого займет не 24 такта, а 22 такта (ну вот так нашел более эффективную схему последовательного сложения). Но 22 такта при условии что мы органично вписываем наш ускоритель в DMA окружения msp430. А это очень не просто. В противном случае при решении вопроса в лоб - выгружая и загружая данные побайтно самим микроконтроллером мы теряем 9*3+8*3=51 такт.

Далее аппаратный ускоритель может не только суммировать, но и вычитать, "компилментом" (дополнения) слагаемого до 9 и 10. За те же такты. Для msp430 к сложению добавляется 8 тактов для "комплимента" одного из слагаемых.

Вот теперь мы вроде бы знаем все и могли бы рассуждать надо такое решение или не надо. Повторюсь по прежнему целью для меня остается быстрая BCD арифметика. Хотя бы уровень сложение/вычитание, умножение/деление. Но я не вижу на этом пути желающих помочь, поэтому естественно я бы хотел переложить сложную программную задачу на плечи аппаратуры.

Ну и самое главное - как бы не выглядело маниловщиной решение перенести в ПЛИС процессор могущий за 4-5 тактов сложить/вычесть 8+2 BCD число, он в принципе своей возможностью существовать и потреблять до 50 мА на частоте 40-50МГц задает верхнюю планку возможного для решения этой задачи.

Повторюсь Сергей я бы и сам с удовольствием ушел только в плоскость программного обеспечения для msp430 - но умножение видится самой неподъемной и не решаемой задачей. Помните мы уже обсуждали что умножение как я его понимаю занимает "тысячи тактов". Плюс его не удерживаемая в голове сложность реализации и нежелание впрячься в эту упряжку (алгоритмизации и формализации) кого бы то еще. Все это заставляет снова и снова смотреть в сторону аппаратной реализации.

Лучшее - враг хорошего, мне кажется, что нужно искать не платформу с минимальным числом тактов на операцию с BCD-числами или IPC, а выбирать платформу исходя из нижней планки по FLOPS (с фиксированной и плавающей точкой). Нижнюю планку можно определять прогоном имеющихся тестов и сравнением результатов с другими изделиями, тем же МК161, HP Prime, Casio или TI. Если результат сравнимый или даже выше, не стоит копать дальше, иначе можно всю жизнь искать философский камень или "камень" :).

Предлагаете похоронить вычисления на основе двочно-десятичной записи? Тогда надо будет смириться с тем что вводимое круглое число скажем что нибудь вроде 90.253 превратится в результате в 90.252999999. Что с этим делать?
Что делать с тем что натуральный логарифм e^X при некоторых дробных X не будет давать X? Да и корни тоже будут давать что то с ...99(9).

Во-первых, есть формат с фиксированной точкой.

Во-вторых, ты (мы давно на "ты" ) не принимаешь в расчет принцип разделения данных и представления. Конкретный пример: во многих калькуляторах используются т.н. скрытые разряды. Поэтому при +2 разрядах на индикатор всегда попадет 90.253, т.к. 90.252999999 округляется до числа выводимых цифр.

В-третьих, математические операции за пределами умножения все равно приводят к рациональным и действительным числам, хранение которых при любом подходе будет урезано до разрядной сетки устройства. Пример, достаточно 1 поделить на 3. С этим борются не на уровне BCD, а символьным представлением промежуточного результата в виде дроби 1/3.

По этой причине натуральный логарифм e^x и не должен давать исходного числа без разбора выражения в системе символьной математики или без скрытых разрядов. Вычислительных систем с бесконечной точностью не существует.

Поэтому считаю проблему надуманной, мешающей двигаться вперед, к созданию аппаратной платформы, проблемы точности которой будут решаться на уровне ПО.

в HP и TI не было бы такого жёсткого разделения на режим аналитического представления и вещественного. Решением произвольной точности возможно являются алгоритмы класса "цифра за цифрой", там то уж всегда можно выбить больше разрядов, чем хранится (хотя в прочих алгоритмах тоже) :-)
Какие ваши конкретные предложения ? А то пахнет маниловщиной, так можно всю жизнь искать подход и не добиться нужного представления :-)

Думал уже об этом, наверное ты прав с округлением в ограниченной разрядной сетке можно избежать периодических десятичных дробей. Только вот уже один раз я это проделал на AVR - в проекте mk61avr. И возникает вопрос - чем новая разработка кардинально отличается от mk61avr? В чем будет изюмина?

Сергей, все таки хочу сказать что ты меня не убедил по поводу потери точности. Для бинарки точность будет теряться всегда, потому что она имеет "квант" десятичного разряда. И к проблеме округления прибавляется проблема выражения - точности представления числа IEEE754 в десятичной форме. Ну ты же понимаешь что при преобразовании при переходе из разряда в разряд будет деление на 10, а бинарка ну ни как не кратна 2. Таким образом получим две дельты в точности - точность разрядной сетки бинарки при переходе к десятичке и само округление. Я ничего не хочу сказать против твоей идеи использовать обыкновенную бинарку, но BCD таки значительно точнее и диапазон не искажается. Я прав?

Точность еще и проблемно-зависима, приведу простой пример из ERP. В заказах обычно сразу выделяют НДС по позициям и по сумме. Этот вопрос (пример обсуждения), по-моему, хит прикладных программистов на все времена. Суть проста, сумма выделенного НДС по позициям не совпадает с выделенным по сумме (уровень документа). Здесь не поможет никакая точность, даже астрономическая, проблема чисто методологическая.

Или вот статья на тему под названием "Ошибочная точность" в НиЖ №3 за 2002 год.
ошибочная точность

Я понимаю твою мотивацию работы над своей реализацией вещественной арифметики, в т.ч. аппаратной -- превзойти имеющиеся. Вопрос, надо ли? Назначение калькулятора: школьные и студенческие задачи, быстрые расчеты "на ходу" или "в поле" т.е. по пути к компьютеру, управление периферией, игры. Для всего этого double precision должно хватать с избытком, как мне кажется.

Я ведь согласен с тобой Сергей, по всем пунктам, да как бы и трудно тут не согласится. Но что мы противопоставляем уже имеющимся калькуляторам, в том числе и любительским. Скажем что мы противопоставим МК-161? МК-161 будет всегда точнее чем калькулятор на IEEE754. Все твои слова безусловно в кассу, но если нет чего то определяющего в разработке? Скажем точность как у МК-61/161 и скорость как у DM42, вполне себе характерные особенности. А что предложить тут? Просто клон МК-61 на IEEE754? Да безусловно быстрый калькулятор получится, спорить не буду, быстрее чем МК-161. Быстрый но менее точный и без ЕГОГГ-ологии. Ну допустим с современным ЖК экраном, двух строчным или даже с графическим. Допустим довольно экономичный и превосходящий по времени автономной работы МК-161. А что еще? Вот именно технические фишки?

Ну вот к примеру скажем калькулятор с Фортом как входным языком и добавочным словарем МК-61, с моей точки зрения - интересен и содержит технические уникальные особенности.
На фоне вышеприведенного примера - скажем калькулятор с аппаратным BCD и стековым процессором, выглядит тоже не плохо. Оба этих примера выглядят приметными на фоне DM42. Вот что меня заботит прежде всего.

P.S. Сергей поскольку в активе у меня уже есть когда то давным давно поднятый mk61avr, конечно совсем не точная копия МК-61, но копия на которой идут многие программы МК-61. Пусть с примитивным, но графическим экраном. И копия которая расширяется во вне посредством I2C. И ты просто предлагаешь вернуться на семь лет и повторить только на другой базе?

Я предлагаю возвращаться на новом уровне, как нас учит диалектика. Устройство должно обладать несколькими вариантами прошивок, эмуляция МК61 - одна из них. Это позволит заливать симулятор МК61, Форт, Рапиру и вообще все что пожелается. Модульность нужна прежде всего на программном уровне: если понадобится библиотека повышенной точности, будучи один раз написана, она должна стыковаться с прошивками как минимум на этапе её сборки, в идеале -- подгружаться динамически будучи частью ядра вместе со слоем ввода-вывода и сопряжения с периферией.

Я бы предложил всё таки создать нечто вроде микро виртуальной машины на основе Форта, на которой и крутилось бы всё остальное, а другие реализации языков и их среды выполнения могли бы использовать Форт уровень для взаимных вызовов. Делать ради МК61 отдельную прошивку как то грустно. Естественно обязаловки нет, при открытой архитектуре каждый может вообще писать совсем под голое железо, если ему(ей) захочется. Реализовать десятичную арифметику и всякие драйверы железа на самом низком уровне, и чтобы любой язык над этим HAL/BIOS мог использовать её и остальные низкоуровневые примитивы (рисование на экране, получение кода клавиатуры) для наискорейшего достижения целей.

У меня в графике:

1) ощупывание библиотеки десятичной плавучки под STM32 и перетаскивание её в проект STM32L4, проба на платках NUCLEO (3 варианта).
2) построение примитивного калькулятора аля МК-61 на основе этой функциональности
3) определение с Форт ядром (брать готовое или создать фортообразное на C++)
4) запуска Форт микроядра и реализация связи с периферией
5) изготовление клавиатуры, подключение экранчика - увязка вместе, примитивный калькулятор аля МК-61, где однако будут реализованы все элементарные математические функции.
...
тут можно думать про RPL, Рапиру, Прямой Оберон и т.п.

Дайте ссылку что ли посмотреть на библу с десятичной арифметикой?

Хотите портировать библиотеку оттуда на STM32? А библиотека то там точно без ассемблерных вставок?

Где то она у меня в чистом виде ещё валялась.

Сергей насчет "заливать" - если это прошивки, и мы их "заливаем", то это не практично - нужен хост, время на смену прошивки. Ну и это еще не технологично - так как требует дополнительного ПО вне платформы калькулятора.

Если под "заливать" ты имеешь в виду - систему оверлеев, а как вижу дальше ты развиваешь именно эту мысль - до динамически загружаемых библиотек. Ну и вот тут мне в голову приходит только один продукт имеющий в данный момент необходимые для этого свойства - это Форт. Как сделать это на базе обычного Си, я вижу с трудом, в первую очередь потому что средства разработки не позволят из поставки сделать такое API. Т.е. придется это делать руками. С нуля. И что же это будет за ядро? Как в Smalltalk с запросами к объекту? Это конечно здорово, красиво - но это серьезный проект, которому требуется архитектор. Уже есть какой то минимальный план куда и как двигаться? Кто и что будет делать?

Но народ пишет, что это работает:
https://stackoverflow.com/questions/5024387/trying-to-load-position-inde...

https://developer.arm.com/docs/dui0773/e/compiling-c-and-c-code/bare-met...

Очень хотелось бы не терять возможность загружать Сишные функции.

Если я понимаю то линковка то должна быть по имени функции, а не просто по адресу указатель поменять на код, компиленный как PIC.

Надо курить эту тему, раньше не приходилось делать

В случае с МК-61 с его стеком, DLL получается весьма просто. Это же просто вызов функции, аргументы уже находятся в стеке. Обеспечить надо позднее связывание, это когда мы грузим средствами ОС модуль BCD_ADD, а он содержит и код и символическое имя, скажем "ADD". Сам код как уже и говорилось - PIC, таким образом он грузится в любое свободное адресное пространство. Конечно это свободное адресное пространство - предоставляет какой либо менеджер "кучи". Есть таблица связей, где функции с символьным именем соответствует указатель на код. Такая таблица должна находится в ОЗУ. Вместо литерального значения вероятней всего нужно использовать хеш (скажем CRC16). Поучая новый модуль размещаем его в флеш и меняем ссылку на него в таблице связей. Но это для МК-61. А для других вариантов когда функция может иметь и произвольное кол-во аргументов, и разные их типы, все гораздо хуже.

"Заливать" т.е. прошивать должен разработчик. Архитектура, минимально, из монитора, загружающего нужную подсистему (МК61, Форт, Рапира,...) при старте. У пользователя, соответственно, есть возможность эту подсистему выбрать. Подсистемы используют код более низкого уровня ядра (можно обозвать его микро-HAL + системные библиотеки ввода-вывода и другие, вместо BCD-библиотеки можно просто поставить пока "заглушку", использующую double precision). Компоновать это все можно статически непосредственно перед заливкой.

И где её выбирать, эту платформу. На том свете с фонарями ? Вокруг прям такой богатый выбор платформ, аж голова кружится. Либо древние, либо ARM, либо особнячком малопотребляющие типа MSP430 (тоже довольно древние).

А чем вам STM32 с библиотекой decNumber не нравится ? Почему тактов на операцию, а не десятичных операций на микроватт ? :-) Кого так уж волнует абсолютная производительность карманных ПМК ??? Имхо автономность чуть важнее (хотя медленный девайс тоже никому не нужен).

Или вы имеете в виду ПЛИС и софт процессоры ?

Выборы-перевыборы уже не раз обсуждались на сайте. Вроде бы остановились на энергосбережении, как основном факторе, все согласились. Названия моделей и поставщик мне неважны, я не профессионал в аппаратных платформах. Главное - компилятор Си/Си++, среда разработки и возможность легкой перепрошивки. Я не хотел бы втягиваться в очередной цикл "на колу мочало" и прошу не воспринимать это как неуважение к вашему энтузиазму.

Сергей прав. Поскольку разработка на ЯВУ то можно вести хоть две, хоть три ветки проекта для разных аппаратных платформ - будет ли это STM32 или MSP432 как платформа на ARM Cortex, либо будет ли это msp430fr. Часть кода будет аппаратно зависима и вынесена в разные ветки сборки, основа же вполне себе - кроссплафторменна. Я тут с Сергеем согласен, если заложить double в основу арифметики, то скорее всего можно будет приблизиться к точности МК-61 на BCD.

И все равно Сергей повторюсь, чем такая разработка может похвастаться? Или скажем чем сравниться с другими более прогрессивными например Free42 (DM42) на основе RPL? Как ты то это видишь?

Люди делают BCD 64 и 128 бит и не используют двоичную арифметику для десятичных расчётов. Никакая разрядность двоичной арифметики не компенсирует "хвостов".
Зачем этот цирк с воспроизведением точности МК-61 в новых девайсах ?

И библиотека десятичной плавучки в коробке, и компилятор Си/Си++, и возможность перепрошивки через что угодно, и низкое потребление. Это уже всё сошлось. Обсуждать нечего. А вот всякие дурные мысли насчёт ПЛИС и сопроцессоров, я бы ещё обсудил :-)

Скорее всего это просто форматы decimal64 в которой может храниться число при конверсии его из бинарки, а вот операции все наверняка в бинарке идут. Это как DM42 котороый тоже на STM32 расчет ведет в бинарке, а хранит в decimal.

Вот пример кода оттуда.

void sincosTaylor(const decNumber *a, decNumber *sout, decNumber *cout) {
	sincosNumber a2, t, j, z, s, c;
	int i, fins = sout == NULL, finc = cout == NULL;
	const int digits = Ctx.digits;
	Ctx.digits = SINCOS_DIGITS;

	dn_multiply(&a2.n, a, a);
	dn_1(&j.n);
	dn_1(&t.n);
	dn_1(&s.n);
	dn_1(&c.n);

	for (i=1; !(fins && finc) && i < 1000; i++) {
		const int odd = i & 1;

		dn_inc(&j.n);
		dn_divide(&z.n, &a2.n, &j.n);
		dn_multiply(&t.n, &t.n, &z.n);
		if (!finc) {
			decNumberCopy(&z.n, &c.n);
			if (odd)
				dn_subtract(&c.n, &c.n, &t.n);
			else
				dn_add(&c.n, &c.n, &t.n);
			if (dn_eq(&c.n, &z.n))
				finc = 1;
		}

		dn_inc(&j.n);
		dn_divide(&t.n, &t.n, &j.n);
		if (!fins) {
			decNumberCopy(&z.n, &s.n);
			if (odd)
				dn_subtract(&s.n, &s.n, &t.n);
			else
				dn_add(&s.n, &s.n, &t.n);
			if (dn_eq(&s.n, &z.n))
				fins = 1;
		}
	}
	Ctx.digits = digits;
	if (sout != NULL)
		dn_multiply(sout, &s.n, a);
	if (cout != NULL)
		dn_plus(cout, &c.n);
}

в процедуры dn_****, что там, там банально может быть конверсия в "бин".

Какой смысл производить отдельные операции, умножения и т.д. над десятичными числами, при этом "уродуя" их и теряя в точности ???

Ну вот например в DM42, Vitasam, не даст соврать - сделали именно так. Vitasam задавал вопрос в лоб на этот счет. Ну а хранение в decimal понятно почему удобней - выводить то надо как раз в нем.

которые не представимы в двоичной форме ???

Не знаю есть ли они там

их конечно нет смысла делать на десятичной арифметике, только всегда твердят что конвертация дороже, чем так посчитать. Вообще, есть ли смысл хранить число в BCD пока она не стало плавучим ? Вроде как нет, в двоичной форме вроде как больше влазит???

Но хранение в BCD дает возможность по быстрому выводить эти числа на устройство отображения.
А BCD при наличии порядка автоматически с плавающей запятой.

:)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Десятичная арифметика и STM32 - это единственные вещи, которые дают сходство с DM42 и WP34S,
остальное - должно быть реализовано иначе, хотя бы в виду опасности нарушения авторского права.
Кроме того хотелось бв там реализовать языки высокого уровня, т.е. идти в сторону RPL,
и ещё была куча оригинальных идей (часть связана с периферией).
Можно эпопею с ПЛИС остановить на перспективе реализации плат расширения для ПМК на ультранизко потребляющем микроконтроллере. Плата с ПЛИС подключается в слот с 16-битной шиной данных и ускоряет или чтото делает для периферийных вещей - захват сигналов или генерация видеосигнала.

«Эпопея на ПЛИС» полезна. Проекты без финансирования развиваются медленно. За те годы, что эксперименты с ПЛИС дадут результат, технологии продвинутся. Появится возможность реализовать достижения на платформе, эффективной по потреблению — или же аккумуляторы продвинутся.

Например, в габаритах МК-161 можно разместить целый слой «артиллерии» из аккумуляторов формата ААА или даже АА — тех, что в электромобилях используются.

Вытянутый, как рукоятка узкий, экран небольшой квадратный, по длине кажется короче и тоньше раза в два. Клавиатура оптимизирована под набор большим пальцем. Я прямо во сне ещё подумал "Нафига такое надо ?" На телефон похоже, может быть это для игры в покемонов, специализированный ультранизкопотребляющий вариант ??? Не думаю что там было место для AAA.

Возвращаясь к теме. Всё таки вариант с ПЛИС привлекателен. Сейчас ПЛИСы всё лучше и лучше, всё дешевле и дешевле, соответственно проникают во все области. Специализированных микросхем не найти, а свою производить денег не хватит, ПЛИС может во многих местах выручить, в том числе за счёт того, что сразу возьмёт на себя кучу разной периферии, можно и USB туда впихнуть,и Ethernet и всякие DMA художества, чтобы можно было в фоне тянуть данные туда/сюда по шлангу или по воздуху.

Стоимость достаточно развитых FPGA вроде Spartan-6 и Cyclone-IV(а для топовых вещей и Cyclone V с двуядерным ARM) уже сегодня вполне демократична. Обычно ПМК ассоциируется с расчётами и школой/универами, но присоедини к нему достаточно гибкую и быструю часть на FPGA - получается швейцарский многофункциональный набор инструментов :-) Можно и осцилл забацать и всякие другие штуки. Под такое наверное можно и финансирование рано или поздно поднять. Может быть и армия заинтересуется, там такие штуки должны быть нужны.

Тут не поиграешь в энергопотребление, даже обесточить - потом придется ждать конфигурирования с внешнего ЗУ. Кроме того они жрут очень прилично - сотни мА! Куда такое годиться?

Говорить приходится о CPLDб потому как их хотя бы выключить можно и попытаться экономить до нажатия кнопки. И кроме того и потребление хотя бы десятки мА, ну смотря каких конечно объемов ПЛИСы. Это CoolRunner-ы, MAX-ы, xc95xxx.

Есть у меня осциллограф карманный DSO-203, он построен на аккумуляторе, внутри вроде Spartan-6, микроконтроллер и здоровенный ЖК экран с подсветкой. Автономность на уровне сотового телефона, но ведь в нашем случае всё кроме матрицы гораздо более скромное.

Вот например на телефоне WiFi поднимается СЕКУНДЫ и никого не волнует. Так же и тут, если матрица будет конфигурироваться секунду, много жрать, потом полностью выключится для энергосбережения, не думаю - что это плохой сценарий. Например GPS, если тебе надо сберечь аккумулятор, где нибудь в похоже в лесу, в горах, пускай матрица поднимается ненадолго (если она вообще будет нужна для общения с GPS модулем), зачем там непрерывный трекинг. В очень большом числе сценариев отключаемая матрица будет полезна.

Кстати как там незабвенный MAX10, она то на флэше построена ?

Время подъема ПЛИС из расчета что можете поспать между нажатиями. Период между нажатиями - 0.2 ... 0.3 секунд. Подъем с задержкой в десятые секунды - может быть сильно заметен оператору. Мы же вроде обсуждаем вариант когда ПЛИС - это полностью вычислительное ядро, а не сопроцессор.
MAX-10 это CPLD и да он на флеше, но крайне дорог и я думаю что и избыточен тоже.

"MAX 10 FPGA Device Architecture" так называется документ Intel, описывающий архитектуру.
Архитектурно его устройство скорее характерно для FPGA, кроме Flash памяти.

Я даже подозреваю что конфигурационный флеш размещен на кристалле. То есть это FPGA с конф.ЗУ внутри.

Нарыл с форума https://electronix.ru/forum/lofiversion/index.php/t121950.html:

Nov 6 2014, 11:10
Итак, статическое энергопотребление MAX10:
девайс 10M08SAE144C8GES - 8 тыс. LE, EQFP144, аналоговый блок, встроенный LDO для питания ядра.

Флэш стерт, вотчдог выключен.
VCCINT = 3,3В - потребление 36 мА;
VCCIO = 3,3В - потребление 32,6 мА.

Судя по другим данным, статическое потребление Spartan-6 находится от 11 до 40 миллиампер.

Не батареечное потребление (уж точно не от таблетки), но позволяет на аккумуляторе ожидать сутками.

Ну если уж так хочется то почему нет - можно и Spartan-6. :) Но я бы все таки попытал бы счастья с CPLD-хами по меньше. В применении Spartan-6 есть только одно рациональное зерно на мой взгляд - не городить огород с внешним ОЗУ. Вот это действительно - жирный плюс!

Механически DM42, наверное, самый близкий к идеалу. Хотя для самодельщиков больше подходит Numworks, с его простой механикой, которая вся печатается на 3Д принтере.

P.S. Если бы не глупый экран в Numworks, я бы купил его

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Оно вроде дешевле DM42, но всё ещё дороже 300-400 рублей, в которые как предполагается будет возможно впихнуть микроядро, с отлаженной программой. И не годится как пустая железяка для своей прошивки.

Эту тему собственно ни кто не закрывал. Но на этом пути нужно очень многое сделать. Для меня например пока не ясна архитектура, либо это РОН с 16-битными регистрами (4 р-р BCD) с возможностью быстро двигать пару регистров (barrel shift) на произвольное кол-во десятичных разрядов. Либо это 32 битные регистры. Одно скажу точно - при таком подходе с CoolRunner придется съехать, она этого не вынесет. Либо это будет стек 32 битных чисел с очень примитивной системой команд, тогда может в c256 полезет.

P.S. Но Сергей прав что кратчайший путь к МК-61м это путь через бинарку, вот только вопрос что это будет за калькулятор, Сергей не делится своим видением. Интересуют ключевые моменты, т.е. ради чего стоит терпеть бинарку в нем. Так как точность отпадает, остается только скорость вычисления и экономичность платформы. Я не вижу чем тут можно похвастать против DM42 (Free42). Хотелось бы видеть список ключевых особенностей - возможностей платформы.

Современных скоростей хватает для всех бытовых вычислений прошлого века. Библиотека BCD несколько замедляет скорость вычислений, но этот эффект компенсируется ежегодным ростом производительности процессоров.

Десятичная арифметика хороша, т.к. использует привычную для человека систему счисления, в которых ½ и 1/5 выражаются конечными десятичными дробями. Её можно имитировать

Смысла нет терять быстродействие, эмулируя уровень машинного языка. Это делается в учебных целях или если ресурсов ну очень много — а программы переписывать дорого. Например HP 49g+, p-код Паскаля или MMIX Дональда Кнута.

Сейчас у нас нет кода на какой-либо микропроцессор, который нельзя было бы переписать. Самое близкое это прошивка МК-161, но эта прошивка закрыта. Микрокод советских ПМК разве что достоин эмуляции, чтобы закрыть гештальт errorологов. Но на нём ничего более интересного не напишешь.

Любая система команд, даже предельно упрощённая, легко поднимается до высокого уровня с помощью Форта. Адресный интерпретатор и примитивы пишутся на ассемблере, а остальное уже — высокий уровень, компилирующийся в шитый код. Если делать процессор самим, он может быть заточен под ПМК и ему не обязательно быть совместимым с иностранными разработками.

Другое дело, что даже богатая фирма HP не смогла поддерживать собственный специализированный процессор, а TI даже не пыталась. Я бы советовал разыскать отечественных разработчиков процессоров, выбрать наиболее подходящих для нашего ПМК и посмотреть, что получится от их поддержки.

Точно вот его то и поставим :)

Если речь об Эльбрусах — там разве есть что-то малопотребляющее? А вообще я намекал, например, на форт-процессоры. Есть как минимум две отечественные реализации в FPGA: Dophin (документация) и Equinox.

Трёхвольтовый К1894ВГ2Т, например, в режиме энергосбережения потребляет не более 2 мкА.

Думаю они вообще махнули в сторону попсы. А попса работает отлично на новых ARMах. Иначе бы они улучшали точность и скорость арифметики и никакие ARMы за их процессорами бы не угнались. Это банальная денежная тема, в последнее время многое превратилось в тыкву из-за того, что люди банально хотят много денег, но не хотят вкладывать душу в продукт. Почему DOS игры 30-летней давности признаны более душевными даже новыми молодыми игроками ? Всё потому что штампование новых блестящих продуктов лишь бы пипл хавал - приводит к выхолащиванию темы. Например HP Prime - это же просто галимый смартфон без звонилки, с очень странным интерфейсом (смартфонным), про поддержку нормального RPN и удобство уже даже никто не заикается. Базару нет, новые процессоры мощнее, смартфоны рвут одну планку за другой, но становится не радостней, а грустней, если раньше я хоть когда то играл, сейчас вообще нет тянет в ЭТО играть. :-(

Оказывается MAX II выпускался в модификациях Z и G с низким статическим потреблением, вроде бы не хуже CoolRunner II. Для CoolRunner в идеале бы приобрести платку отечественной фирмы LDM Systems, естественно за конскую цену, если передрать позаимствовать дизайн и добавить остальные элементы сразу на плату (там площадка для макетирования), то получится довольно недорогая CPLD платформа для калькуляторства. К сожалению самая дешёвая стоит у них 5 тыр, пытаюсь найти платку на MAX II (правда не низкопотребляющую версию). Возможно страхи по поводу статического потребления этих куцых микросхем сильно преувеличены. По крайней мере я нашёл для них 2 микро процессора: Tiny CPU (похож на MOS 6502) и Pico Blaze. Возможно из этих процессоров надо выбросить кое что, чтобы влезла какая нибудь поддержка BCD арифметики, иначе от CPLD не будет выхлопа. Вообще эти MAX II бывают довольно жирные до 512 ячеек, у нас где то на фирме валялись для обучения студентов, но человек ведающий ими уехал в отпуск.
Кстати старшие модели стоят неоправданно дорого, почему бы на плату просто не поместить 2 CPLD ? Одна будет чистым процессором, другая его АЛУ с функциями BCD. На время работы АЛУ процессор можно гасить почти полностью и наоборот.