Сообщество

10) Ethernet 10/100 MAC+PHY, иначе грош цена Ethernet-у для спец. применений. Ну и опять же, с PHY из процессора выходит всего 4 порта, а не 17...
11) USB PHY (Device + Host)- пусть 12ти мегабитное, как у Миландра, но зато всего два вывода и для спец. применений никакого импорта.
12) UART-загрузчик на масочном ПЗУ
13) Одно напряжение питания, а не несколько
14) Температурный датчик
15) Сторожевой таймер без внешней обвязки или сторонних м/сх, т.е нормальный сторожевой таймер
16) Аппаратный делитель
17) Из серии "хотелось бы..." блок конфигурируемой логики, т.е своего рода небольшая CPLD внутри

И соответственно, если например выполнить все эти пункты, то тогда и корпус можно сразу делать LQFP-144

1) GPIO с несколькими альтернативными функциями

Для микроконтроллеров эта опция "must have"

3) Присваивание процессору индивидуального номера прямо в кристалле

Когда Intel добавила в Pentium III подобную инструкцию, то тут же прокатилась волна протестов. Соображени тут два: любое коммерческое ПО выигрывает при наличиии такого номера, поскольку можно привязать ПО к конкретному чипу, выигрывают тут и пользователи (не срубает ПО, при замене малозначимых частей, например - HDD заменили, а прога работает, посмотрите сколько геммора с софтовыми лицензиями 1С). Отрицательная сторона в том, что чип можно отслеживать, но это паранойя, сам чип пользователям пофиг, им достаточно отслеживания устройства и MAC адрес их не смущает, не говоря уже про то, что даже без всяких специальных штук, даже сам браузер обладает уникальными параметрами позволяющими отслеживать пользователя без всяких cookie. Так что инструкция однозначно полезная и доводов против существенных - нет.

8) Аппаратный блок CRC

CRC это классика и, конечно, не помешает, но приемущество-то где? Думаю надо в пару сразу реализовывать новые стандарты:
Blake2 (на данный момент используется в WinRar вместо CRC) http://www.opennet.ru/opennews/art.shtml?num=35676

10) Ethernet 10/100 MAC+PHY, иначе грош цена Ethernet-у для спец. применений. Ну и опять же, с PHY из процессора выходит всего 4 порта, а не 17...

Не согласен, должен быть Ethernet 10/100/1000, 1000 это уже давно фактический стандарт. При желании сейчас 10Гбит оборудование выбрать не проблема, причём по витой паре, уже даже беспроводные технологии за гигабит перешли, а невозможность работать по гигабиту это огромный минус.

12) UART-загрузчик на масочном ПЗУ

Кстати, помимо Flash, давно уже есть перезаписываемая память, зачем масочное ПЗУ, технология типа Dual Flash вполне себе надёжна и позволяет обновлять FlashBIOS без всяких рисков. А вместо флеш давно уже есть ReRAM (вроде как отечественные производители грозились выпустить тоже) и STT-MRAM
http://www.ixbt.com/news/hard/index.shtml?18/58/83
http://www.ixbt.com/news/hard/index.shtml?17/39/96

13) Одно напряжение питания, а не несколько

А их несколько у мултиклета?! Ну прямо как в КР1818ВГ93 которые горели пачками из-за задержек по подаче питания, жесть. Напряжение питания должно быть одно, это современный стандрат подтверждённый практикой - с нескольими напряжениями никто не будет возиться, просто возьмут другую микруху.

14) Температурный датчик

Рекомендую ознакомиться, например, с этим:
http://www.ixbt.com/news/ht/188078
Моё мнение, отсутствие температурного датчика в современных чипах - это каменный век. И если бы в своё время производители не ввели такие датчики в свои процессоры, то они горели бы пачками. У вас есть опыт других разработчиков, контроль температуры очень важная тема и надо бы озаботиться заранее.

15) Сторожевой таймер без внешней обвязки или сторонних м/сх, т.е нормальный сторожевой таймер

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

И соответственно, если например выполнить все эти пункты, то тогда и корпус можно сразу делать LQFP-144

Мне всё-таки кажется, что BGA предпочтительней.

HEMAH wrote:

10) Ethernet 10/100 MAC+PHY, иначе грош цена Ethernet-у для спец. применений. Ну и опять же, с PHY из процессора выходит всего 4 порта, а не 17..

С этим согласен, по поводу Ethernet на 1000, там на текущем техпроцессе 180 нм PHY может вообще не поместиться.
Ну и несколько каналов Ethernet я думаю.

11) USB PHY (Device + Host)- пусть 12ти мегабитное, как у Миландра, но зато всего два вывода и для спец. применений никакого импорта.

Мне для Key_P1 нужен USB 480 Мбит/c, сейчас у нас в R1 USB 2.0 device. Но думаю да, нужен PHY и USB 2.0 host.

12) UART-загрузчик на масочном ПЗУ

UART загрузчик сделать можно

13) Одно напряжение питания, а не несколько

Да, сойдемся на 3,3 Вольта

14) Температурный датчик

Это может иметь место

15) Сторожевой таймер без внешней обвязки или сторонних м/сх, т.е нормальный сторожевой таймер

Он сейчас без внешней обвязки нормальный

16) Аппаратный делитель

Это да, сейчас только c float

17) Из серии "хотелось бы..." блок конфигурируемой логики, т.е своего рода небольшая CPLD внутри

Это уже из категории люкс климат контроля под требования заказчика)

И соответственно, если например выполнить все эти пункты, то тогда и корпус можно сразу делать LQFP-144

Корпус LQFP на первое время более просто отлаживать, в дальнейшем мы этот же кристалл можем запихнуть в корпус BGA.

VaalKIA wrote:

1) GPIO с несколькими альтернативными функциями

Для микроконтроллеров эта опция "must have"

3) Присваивание процессору индивидуального номера прямо в кристалле

Когда Intel добавила в Pentium III подобную инструкцию, то тут же прокатилась волна протестов. Соображени тут два: любое коммерческое ПО выигрывает при наличиии такого номера, поскольку можно привязать ПО к конкретному чипу, выигрывают тут и пользователи (не срубает ПО, при замене малозначимых частей, например - HDD заменили, а прога работает, посмотрите сколько геммора с софтовыми лицензиями 1С). Отрицательная сторона в том, что чип можно отслеживать, но это паранойя, сам чип пользователям пофиг, им достаточно отслеживания устройства и MAC адрес их не смущает, не говоря уже про то, что даже без всяких специальных штук, даже сам браузер обладает уникальными параметрами позволяющими отслеживать пользователя без всяких cookie. Так что инструкция однозначно полезная и доводов против существенных - нет.

8) Аппаратный блок CRC

CRC это классика и, конечно, не помешает, но приемущество-то где? Думаю надо в пару сразу реализовывать новые стандарты:
Blake2 (на данный момент используется в WinRar вместо CRC) http://www.opennet.ru/opennews/art.shtml?num=35676

Тут еще надо подумать

10) Ethernet 10/100 MAC+PHY, иначе грош цена Ethernet-у для спец. применений. Ну и опять же, с PHY из процессора выходит всего 4 порта, а не 17...

Не согласен, должен быть Ethernet 10/100/1000, 1000 это уже давно фактический стандарт. При желании сейчас 10Гбит оборудование выбрать не проблема, причём по витой паре, уже даже беспроводные технологии за гигабит перешли, а невозможность работать по гигабиту это огромный минус.

Ответил чуть выше

12) UART-загрузчик на масочном ПЗУ

Кстати, помимо Flash, давно уже есть перезаписываемая память, зачем масочное ПЗУ, технология типа Dual Flash вполне себе надёжна и позволяет обновлять FlashBIOS без всяких рисков. А вместо флеш давно уже есть ReRAM (вроде как отечественные производители грозились выпустить тоже) и STT-MRAM
http://www.ixbt.com/news/hard/index.shtml?18/58/83
http://www.ixbt.com/news/hard/index.shtml?17/39/96

Мы думали и над FRAM внутри.

13) Одно напряжение питания, а не несколько

А их несколько у мултиклета?! Ну прямо как в КР1818ВГ93 которые горели пачками из-за задержек по подаче питания, жесть. Напряжение питания должно быть одно, это современный стандрат подтверждённый практикой - с нескольими напряжениями никто не будет возиться, просто возьмут другую микруху.

С КР1818ВГ93 были проблемы связанные ещё и с тех процессом производства.
У нас я ещё ни одного процессора не сжег. И статикой его били и напряжения не те подавали, но он достаточно устойчив к этому, при этом другие микросхемы на плате выходили из строя.

14) Температурный датчик

Рекомендую ознакомиться, например, с этим:
http://www.ixbt.com/news/ht/188078
Моё мнение, отсутствие температурного датчика в современных чипах - это каменный век. И если бы в своё время производители не ввели такие датчики в свои процессоры, то они горели бы пачками. У вас есть опыт других разработчиков, контроль температуры очень важная тема и надо бы озаботиться заранее.

Это может быть, но у нас процессор слабо греется и не потребляет много энергии и гореть не планирует).

15) Сторожевой таймер без внешней обвязки или сторонних м/сх, т.е нормальный сторожевой таймер

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

А чем отличается атомарный счетчик от обычного системного таймера, который считает по тактам процессора?

И соответственно, если например выполнить все эти пункты, то тогда и корпус можно сразу делать LQFP-144

Мне всё-таки кажется, что BGA предпочтительней.

В дальнейшем после LQFP можем во все другие корпуса.

12) Аппаратный загрузчик должен быть "железобетонным", это должен быть неубиваемый загрузчик, как у Миландра. А все остальные виды загрузки можно сделать и программно, благо их и делают. Можете в дополнение к масочному ПЗУ сделать отдельную область флеши, ф-рам или ещё что, но загрузчик на масочном ПЗУ это своего рода гарант надёжности. И причём у того же Миландра это работает, это ещё и очень хорошо при производстве, и всегда есть гарантия, что никто и ничего не прошьёт, не испортит, не перезапишет. В любом случае у Миландра, даже если Вы JTAG сожгёте, то через UART всегда сможете зашиться.

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

К микропроцессорному же варианту нужен КПИ, что-то вроде этого

http://www.mcst.ru/kpi

но и клеток побольше или частота выше. Тут упор на производительность и в меньшей степени на потребление.

А если делать смесь МК с МП, как сейчас, то по идее нужно наверное идти по пути НТЦ"Модуль" с ихней К1879ХБ1Я, т.е узкоспециализированное применение под какую-то категорию задач. Если управление двигателями, то на борту должна быть соответствующая периферия, если видео обрабатывать, то тут уже другой набор, если аудиообработка, то тоже определённая комплектность.

Здравствуйте.

Многое зависит от того, куда вы хотите позиционировать ваш будущий процессор.

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

Например, советую посмотреть на то, как у вас устроена работа с памятью (узкое место?) и что предлагается сейчас:

• Компания Samsung первой представила модули флэш-памяти eMMC 5.1
• Микросхемы флэш-памяти типа NOR Microchip SST26WF080B и SST26WF040B плотностью 4 и 8 Мбит оснащены интерфейсом SQI
  • Он обеспечивает возможность выполнения программ прямо во флэш-памяти (execute-in-place, XIP), без копирования в оперативную память.
  • Сектор или блок стирается за 18 мс, вся микросхема — за 35 мс. Для сравнения: микросхемам других производителей для полного стирания необходимо 5-15 с.
  • Гарантированное число циклов стирания-записи — 100 000, срок хранения информации — 100 лет
  • Кроме того, интерфейс SQI на уровне набора команд полностью обратно совместим с популярным интерфейсом SPI.
• Samsung Electronics начинает серийный выпуск модулей памяти ePoP для смартфонов
  • В общем корпусе ePoP находится 3 ГБ мобильной памяти LPDDR3 DRAM, 32 ГБ флэш-памяти eMMC (embedded multi-media card) и контроллер.
  • Оперативная память, интегрированная в ePoP, обеспечивает передачу данных со скоростью 1866 Мбит/с в расчете на линию и поддерживает подключение по 64-разрядной шине.
  • На плате ePoP занимает участок размерами 15 x 15 мм — как и обычный модуль памяти PoP, но во втором случае необходимо использовать отдельный модуль eMMC размерами 11,5 x 13 мм. Таким образом, переход на ePoP уменьшает площадь примерно на 40%. Толщина корпуса ePoP — 1,4 мм.

• Память типа SRAM, изготовленная SST по технологии Hardsil, проработала без единой ошибки 1400 часов при температуре 250°C

По поводу CRC.

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

А если реализовывать что-то новое, то тут надо посмотреть по типу: "А оно надо?" или "Что в ближайшем будущем будет использовано ПО?" (см. Mozilla FireFox и Google Chrome про отказ от использования старых и скомпрометированных хеш-функций).
Если SHA-3 будет актуален в течении 5 лет, то можно реализовать его или Blake2, а может лучше реализовать "ГОСТ Р 34.11-2012"?

Тут надо всё хорошенько взвесить и проанализировать.

По ядру.

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

 т.е. в ядро добавляем новую структуру типа "массив" по аналогии с коммутатором, только не сдвигаем его циклически.
Доступ к данным для этого "нового массива" по индексу.
Естественно придётся поменять текущую реализацию команд:
 - чтобы можно было указать, что нам надо сохранить результат текущей команды в наш "новый массив" (помимо коммутатора). И реализовать это параллельной рассылкой и в коммутатор и в массив сразу. Например: "addl_5 @1, @2" (в массив в ячейку под номером 5)
 - использовать в командах данные не только из коммутатора ('@x'), но и из нового массива (пусть '@@x'). Например: как сейчас из коммутатора "addl @1, @2" , так и из массива "addl @@1, @@2" или коммутатора и массива "addl @1, @@2" 

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

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

Вот ещё статья, может быть пригодится: Микросхемы с подпороговыми рабочими напряжениями питания – революционный подход к снижению тока потребления

Кстати, на текущем R1 uClinux запустится?

18) Для микроконтроллерного варианта, хотелось бы, чтобы на борту была флешка, хотя бы на 128кБ.

Уже из серии сугубо личного мнения, своего рода "мысли вслух":

Мне кажется, что две ветки, МК и МП, были бы оптимальным решением. МК обеспечивали бы серийность, а для спец. аппаратуры минимизацию импорта в обвязке, выигрыш в потреблении и производительности. МП вариант был бы предназначен для вычислительных комплексов. Он обладал бы меньшей серийностью, но если Вы сделаете настольный ПК на МП-варианте, то это будет большим достижением. Причём производительность такого ПК должна быть весьма существенной, иначе если Вы представите аналог 4ого пня, то выигрыша не будет, никто не заметит особо. Но для МП варианта нужен КПИ(Я не говорю о том, что у МП в обвязке не будет импорта, например та же DDR3-память, её в России ещё долго не будет, у нас даже флешек больше, чем на 2-4МБ нету), и вот тут быть может, либо разговаривать с МЦСТ, либо делать самим.
Правда получается, что в направлении МК Вашими конкурентами были бы Миландр и НИИЭТ, а в направлении МП - МЦСТ и Элвис. И вот тут, если Вы будете производить только программно-ориентированные элементы(МК и МП), то Вам придётся очень тяжело, вернее даже не тяжело, спрос-то будет, но в десятки раз ниже, чем если бы Вы развивали направление активных радиоэлементов, о которых я уже писал.

HEMAH wrote:

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

МП так же может относится и к мобильным процессорам, например для смартфонов и планшетов, тогда ему не обязательно быть сверхпроизводительным, но тут Мультиклет может показать хорошее соотношение производительность/энергопотребление.

Вообщем МП сами могут быть тоже разделены -- для мобильной техники, для десктопов и для ускорителей.
Я думаю, что при доработке Мультиклет смог бы отлично конкурировать с ARM и может быть его вставили бы в один из следующих Ётафонов...

Только для этого разделения ещё рано, т.к. архитектура пока находится на уровне микроконтролеров.

HEMAH wrote:

12) Аппаратный загрузчик должен быть "железобетонным", это должен быть неубиваемый загрузчик, как у Миландра. А все остальные виды загрузки можно сделать и программно, благо их и делают. Можете в дополнение к масочному ПЗУ сделать отдельную область флеши, ф-рам или ещё что, но загрузчик на масочном ПЗУ это своего рода гарант надёжности. И причём у того же Миландра это работает, это ещё и очень хорошо при производстве, и всегда есть гарантия, что никто и ничего не прошьёт, не испортит, не перезапишет. В любом случае у Миландра, даже если Вы JTAG сожгёте, то через UART всегда сможете зашиться.

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

sprin wrote:

Здравствуйте.

Многое зависит от того, куда вы хотите позиционировать ваш будущий процессор.

Это да.

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

Например, советую посмотреть на то, как у вас устроена работа с памятью (узкое место?) и что предлагается сейчас:

• Компания Samsung первой представила модули флэш-памяти eMMC 5.1
• Микросхемы флэш-памяти типа NOR Microchip SST26WF080B и SST26WF040B плотностью 4 и 8 Мбит оснащены интерфейсом SQI
  • Он обеспечивает возможность выполнения программ прямо во флэш-памяти (execute-in-place, XIP), без копирования в оперативную память.
  • Сектор или блок стирается за 18 мс, вся микросхема — за 35 мс. Для сравнения: микросхемам других производителей для полного стирания необходимо 5-15 с.
  • Гарантированное число циклов стирания-записи — 100 000, срок хранения информации — 100 лет
  • Кроме того, интерфейс SQI на уровне набора команд полностью обратно совместим с популярным интерфейсом SPI.
• Samsung Electronics начинает серийный выпуск модулей памяти ePoP для смартфонов
  • В общем корпусе ePoP находится 3 ГБ мобильной памяти LPDDR3 DRAM, 32 ГБ флэш-памяти eMMC (embedded multi-media card) и контроллер.
  • Оперативная память, интегрированная в ePoP, обеспечивает передачу данных со скоростью 1866 Мбит/с в расчете на линию и поддерживает подключение по 64-разрядной шине.
  • На плате ePoP занимает участок размерами 15 x 15 мм — как и обычный модуль памяти PoP, но во втором случае необходимо использовать отдельный модуль eMMC размерами 11,5 x 13 мм. Таким образом, переход на ePoP уменьшает площадь примерно на 40%. Толщина корпуса ePoP — 1,4 мм.

Вроде с этой памятью у вас и текущий R1 работать может:

• Память типа SRAM, изготовленная SST по технологии Hardsil, проработала без единой ошибки 1400 часов при температуре 250°C

С SRAM да R1 работает, проверяли, сейчас на плате CY7C1041DV33-10ZSXI. Обратим внимание на новые микросхемы памяти, спасибо за интересную информацию. Мы когда Key_P1 делали отказались от памяти Microchip по SPI в пользу Winbond. Там что-то не очень удобно было с разбиением на страницы. Но Winbond 25Q16BV1G вся стиралась секунд за 7-8.

---

По поводу CRC.

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

А если реализовывать что-то новое, то тут надо посмотреть по типу: "А оно надо?" или "Что в ближайшем будущем будет использовано ПО?" (см. Mozilla FireFox и Google Chrome про отказ от использования старых и скомпрометированных хеш-функций).
Если SHA-3 будет актуален в течении 5 лет, то можно реализовать его или Blake2, а может лучше реализовать "ГОСТ Р 34.11-2012"?

Тут надо всё хорошенько взвесить и проанализировать.

Хэш по ГОСТ полезно было бы сделать и шифрование аппаратное по ГОСТ89.

---

По ядру.

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

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

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

---

Вот ещё статья, может быть пригодится: Микросхемы с подпороговыми рабочими напряжениями питания – революционный подход к снижению тока потребления

---

По ядру подумаем над обменом результатами между параграфами без памяти.

Кстати, на текущем R1 uClinux запустится?

Да, думаю сами портируем его в ближайшем будущем. Если кто-то плотно работал с uClinux, то будем рады помощи в портировании для ускорения процесса.

HEMAH wrote:

18) Для микроконтроллерного варианта, хотелось бы, чтобы на борту была флешка, хотя бы на 128кБ.

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

18) Вот, если есть флешка, то это уже огромнейший плюс. Это фактически значит, что MCp042R1*много цифр* можно будет использовать в спец. аппаратуре, как МК общего применения, если кому-то не потребуются Ethernet и USB.
В принципе, это можно сделать и сейчас; SRAM и FLASH с "5" приёмкой есть у того же Миландра, но в металлокерамике MCp042R1*много цифр*, весьма немалогабаритен, а добавив туда ещё металлокерамические: две 16-ти разрядных ОЗУ, FLASH и обвязку, уже получается не слабый такой "вертолёт". А так, с флешкой на борту можете даже сделать тот же HELPER в минимальной обвязке(без ОЗУ, РПЗУ, USB и Ethernet), станет по-моему сильно дешевле.

HEMAH wrote:

18) Вот, если есть флешка, то это уже огромнейший плюс. Это фактически значит, что MCp042R1*много цифр* можно будет использовать в спец. аппаратуре, как МК общего применения, если кому-то не потребуются Ethernet и USB.
В принципе, это можно сделать и сейчас; SRAM и FLASH с "5" приёмкой есть у того же Миландра, но в металлокерамике MCp042R1*много цифр*, весьма немалогабаритен, а добавив туда ещё металлокерамические: две 16-ти разрядных ОЗУ, FLASH и обвязку, уже получается не слабый такой "вертолёт". А так, с флешкой на борту можете даже сделать тот же HELPER в минимальной обвязке(без ОЗУ, РПЗУ, USB и Ethernet), станет по-моему сильно дешевле.

В металлокерамике итак уже сейчас будут делать в Воронеже наш кристалл. Но закорпусировать кристалл с флешкой мы можем и в пластике.
У LDM сейчас helper без базовой стоит 6500 на их сайте, но я думаю возможно будет сделать удешевленный вариант в будущем.

krufter_multiclet wrote:

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

По мне так, нафик встроенную флеш, лучше всё-таки сразу FeRAM, ReRAM или SST-MRAM, ну в самом деле, у FLASH очень много недостатков: даже если отбросить всякие многоуровневые, которые через полмесяца читаются только за счёт коррекции ошибок и на порядок с меньшей скоростью, то просто организация памяти: блоками объединнёнными в суперблоки из-за чего перезапись ячеек это целые пляски с бубном и достичь заявленной скорости обращения к FLASH можно только зная размеры и карту этих блоков, а это уже аппаратнозависимая реализация, которая на следущей версии чипа (где тупо увеличат размер флешки) вдруг начнёт так тупить, что не будет вообще работоспособна и надо будет переделывать прогу. А все эти новые стандарты, это фактически энергонезависимая RAM, что очень круто. Недостаток у них - недостаточные объёмы, который с успехом нивелируется тем, что вашему контроллеру как раз-таки объёмы пока что и не нужны, так что - в самый раз. Но 128Кб, это маловато, надо ориентироваться хотя бы на объёмы биоса компьютеров, где 1Мб был очень долго стандартом, потом они разжирели, но при гармотной организации 1Мб хватит много на что.

VaalKIA wrote:

krufter_multiclet wrote:

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

По мне так, нафик встроенную флеш, лучше всё-таки сразу FeRAM, ReRAM или SST-MRAM, ну в самом деле, у FLASH очень много недостатков: даже если отбросить всякие многоуровневые, которые через полмесяца читаются только за счёт коррекции ошибок и на порядок с меньшей скоростью, то просто организация памяти: блоками объединнёнными в суперблоки из-за чего перезапись ячеек это целые пляски с бубном и достичь заявленной скорости обращения к FLASH можно только зная размеры и карту этих блоков, а это уже аппаратнозависимая реализация, которая на следущей версии чипа (где тупо увеличат размер флешки) вдруг начнёт так тупить, что не будет вообще работоспособна и надо будет переделывать прогу. А все эти новые стандарты, это фактически энергонезависимая RAM, что очень круто. Недостаток у них - недостаточные объёмы, который с успехом нивелируется тем, что вашему контроллеру как раз-таки объёмы пока что и не нужны, так что - в самый раз. Но 128Кб, это маловато, надо ориентироваться хотя бы на объёмы биоса компьютеров, где 1Мб был очень долго стандартом, потом они разжирели, но при гармотной организации 1Мб хватит много на что.

• По поводу флеша согласен с VaalKIA, для случая "... закорпусировать кристалл с флешкой ..." надо что-то гораздо более долговечное нежели флеш (особенно когда 3 бита на ячейку. Пример: Новый патч скорости чтения Samsung 840 Evo выйдет в этом месяце ). Тогда лучше поставить отдельно микросхему ePoP (если сломается просто заменить на плате и всё)

• По поводу USB. Сейчас уже появляются продукты с USB 3.1. К тому времени, как выйдет ваша новая версия multiclet он уже будет хорошо распространён, так может сразу посмотреть в сторону реализации USB 3.1 '10 Гбит/сек' ?

• Ещё 1 вопрос. Аппаратные тригонометрические функции сейчас актуальны в современных процессорах? Или там стоят заглушки и просто считается программно через вызов "кода" в процессоре? Что насчёт констант типа "пи", "е" и пр. ?

1)Извините, но вот что совершенно мне не понятно, для чего 100Мгц процессору Ethernet 10/100/*1000* ?
2)Температурный датчик очень нужен, может у него самого не большая температура рассеивания, но ведь есть и внешние источники тепла.
3)Внутренняя ППЗУ нужно, опять же если делать упор на отказоустойчивость и аварийность, то должна быть возможность закладывать некоторые функции непосредственно в сам микроконтроллер
4)Это уже больше подходит к ветке пожелания, но вот набор ацп:
8 независимых модулей это конечно хорошо, но для некоторых задач этого мало, по-этому хотелось бы хоть один (а лучше два) ацп сделать по быстрее с подключением через мультиплексор.

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

sprin wrote:

• Ещё 1 вопрос. Аппаратные тригонометрические функции сейчас актуальны в современных процессорах? Или там стоят заглушки и просто считается программно через вызов "кода" в процессоре? Что насчёт констант типа "пи", "е" и пр. ?

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

EviLOne wrote:

1)Извините, но вот что совершенно мне не понятно, для чего 100Мгц процессору Ethernet 10/100/*1000* ?

Чтобы общаться с различными устройствами по каналу Ethernet, в дальнейшем планируем увеличить частоту и тогда можно думать о Гигабитном Ethernet.

2)Температурный датчик очень нужен, может у него самого не большая температура рассеивания, но ведь есть и внешние источники тепла.

Мы согласны его поставить.

3)Внутренняя ППЗУ нужно, опять же если делать упор на отказоустойчивость и аварийность, то должна быть возможность закладывать некоторые функции непосредственно в сам микроконтроллер

Если уходить в отказоустойчивость, то это будет Мультиклет L1 (Liveness).

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

Только надо учитывать, что у нас АЦП сейчас заточен больше на звук, он дельта-сигма с независимыми каналами, 16 бит, 48 киловыборок, но постоянку им не измерить.

krufter_multiclet wrote:

sprin wrote:

• Ещё 1 вопрос. Аппаратные тригонометрические функции сейчас актуальны в современных процессорах? Или там стоят заглушки и просто считается программно через вызов "кода" в процессоре? Что насчёт констант типа "пи", "е" и пр. ?

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

Я почему спросил, лет 15 назад интересовался ASSEMBLER`ом x86. В книге "Assembler для DOS, WINDOWS и UNIX" автор Зубков С.В. (издание второе) есть главы "Трансцендентные операции FPU" и "Константы FPU".

Константы FPU (от проц. 8087):

• FLD1 - 1.0
• FLDZ - +0.0
• FLDPI - число пи
• FLDL2E - log ₂(e)
• FLDL2T - log ₂(10)
• FLDLN2 - ln(2)
• FLDLG2 - lg(2)

Трансцендентные операции FPU

• FSIN - синус (80387)
• FCOS - косинус (80387)
• FSINCOS - синус и косинус (80387)
• FPTAN - тангенс (8087)
• FPATAN - арктангенс (8087)
• F2XM1 - вычисление "2х - 1" (8087)
• FYL2X - вычисление "y * log ₂ (x)" (8087)
• FYL2XP1 - вычисление "y * log ₂ (x + 1)" (8087)

Вот и возник вопрос, а надо оно или нет в вашем новом multiclet`е?

sprin wrote:

Вот и возник вопрос, а надо оно или нет в вашем новом multiclet`е?

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

sprin wrote:

krufter_multiclet wrote:
Вот и возник вопрос, а надо оно или нет в вашем новом multiclet`е?

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

krufter_multiclet wrote:

14) Температурный датчик

Рекомендую ознакомиться, например, с этим:
http://www.ixbt.com/news/ht/188078
Моё мнение, отсутствие температурного датчика в современных чипах - это каменный век. И если бы в своё время производители не ввели такие датчики в свои процессоры, то они горели бы пачками. У вас есть опыт других разработчиков, контроль температуры очень важная тема и надо бы озаботиться заранее.

Это может быть, но у нас процессор слабо греется и не потребляет много энергии и гореть не планирует).

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

15) Сторожевой таймер без внешней обвязки или сторонних м/сх, т.е нормальный сторожевой таймер

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

А чем отличается атомарный счетчик от обычного системного таймера, который считает по тактам процессора?

Честно говоря, не щупал ваш проц вживую, но поясню свою мысль: как правило, все данные часов реального времени получаются по прерыванию, потому что в один порт они не умещаются, а что бы корректно прочесть два порта (всегда есть шанс что часы, дни, годы, минуты секунды сменились, после прочтения одного из компонент, и даже один порт читать и то не всегда можно одновременно с записью туда таймером) их надо - заморозить (послать сначала комманду таймеру, что бы не писал ничего, но это лишает многопоточности) или читать в определённые промежутки времени (узнать у таймера что читать сейчас можно, это реализуется прерыванием). Прерывания это долго, муторно и очень сильно влияет на производительность, не звисимо от того, с какой точностью они могут быть, не говоря уже прото то, что само обращение к портам, зачастую гораздо медленней памяти (спец комманды для них придумывают тормозные, потому что как раз тут можно съекономить на оптимизации). В процессоре z80 была интересная фишка, там, как в современных процах решили встроить хотя бы часть контроллера памяти, которая уже тогда была динамической - на конденсаторах, которые имеют свойство - разряжаться. Так вот, в проц встроили счётчик, который должен был помочь в реегенерации зарядов памяти, фаткически это был счётчик тактов. То есть, в любое время можно было прочесть сколько тактов прошло (жалко что диапазон был небольшим и за давностью лет могу в чём-то гнать), обычным обращением к регистру. На основе этого делали защиту от эмуляторов (потактовое выполнение инструкций на том железе PC было напряжным в то время) и всяческие мультиколоры (когда есть только один цвет на бордюре, но если его дёргать очень быстро, то луч развёртки будет меняться не успевая пройти и пары пикселей, то есть получается полноценный растр из как бы ОДНОЦВЕТНОГО ПОЛЯ, а позже и преодолели ограничения 2 цвета на 64 точки, причём, упёрлись опять в тормознутость команд для портов 7-14 тактов, если не изменяет память). Плюс появились всякие тесты, показывающе корректность int`а (время когда приходит прерывание от работы графической подсистемы, оно же использовалось как замена часов), и надо учитывать, что даже если оно пришло, оно длится несколько тактов, что бы гарантированно попасть на промежуток самых тормозных инструкций + первыми инструкциями надо сохранить состояние проца на стек, в итоге, получается такая прорва тактов, что о потактовой точности говорить просто смешно (там уже речь на сотни шла и погрешность из-за немгновенного входа в прерывание в районе 10 тактов). Ну это так было, лирическое отступление, но де факто, очень часто надо быстро получить эквивалент промежутку времени и с точностью большей, чем доли секунды, при этом не прерывая программу, а реализуется это просто технически. Вообще, если привязываться к физическому миру, то надо очень хорошо отслеживать временные промежутки, будь то отрисовка физически достоверных явлений или просто мягкая синхронизация с чем-то аналоговым, это же так просто технически реализуемо, даже рандом привязывают ко времени, даже GUID для дескрипторов, даже в 1С есть понятие момент времени, ну неужели эти вещи по прерываниям только делать? Тут вспоминается Андроид, тормоза которого приписывали к технологии получения рандома через запись/чтения с HDD (сори, прогнал, там про коллизии хешей в которых участовал рандом http://habrahabr.ru/post/164881/).
И ничего, что часы реального времени переодически отсчитывают один и тот же час два раза, рассказать, как от этого рушаться энтерпрайз решения запустив дважды транзакции в банковской системе и подвешенный, словивший DeadLock сам от себя в этот же день backup? А про пропавшие секунды превратившиеся в часы и соотвественно на порядок отличающиеся показания датчиктов тоже не надо рассказывать!?

И да, расскажите, почему не получилось в R1 (дурацкое название, по русски это будет Р1, а это уже другой проц) сделать два ЦАП?

sprin wrote:

VaalKIA wrote:

krufter_multiclet wrote:

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

По мне так, нафик встроенную флеш, лучше всё-таки сразу FeRAM, ReRAM или SST-MRAM, ну в самом деле, у FLASH очень много недостатков: даже если отбросить всякие многоуровневые, которые через полмесяца читаются только за счёт коррекции ошибок и на порядок с меньшей скоростью, то просто организация памяти: блоками объединнёнными в суперблоки из-за чего перезапись ячеек это целые пляски с бубном и достичь заявленной скорости обращения к FLASH можно только зная размеры и карту этих блоков, а это уже аппаратнозависимая реализация, которая на следущей версии чипа (где тупо увеличат размер флешки) вдруг начнёт так тупить, что не будет вообще работоспособна и надо будет переделывать прогу. А все эти новые стандарты, это фактически энергонезависимая RAM, что очень круто. Недостаток у них - недостаточные объёмы, который с успехом нивелируется тем, что вашему контроллеру как раз-таки объёмы пока что и не нужны, так что - в самый раз. Но 128Кб, это маловато, надо ориентироваться хотя бы на объёмы биоса компьютеров, где 1Мб был очень долго стандартом, потом они разжирели, но при гармотной организации 1Мб хватит много на что.

• По поводу флеша согласен с VaalKIA, для случая "... закорпусировать кристалл с флешкой ..." надо что-то гораздо более долговечное нежели флеш (особенно когда 3 бита на ячейку. Пример: Новый патч скорости чтения Samsung 840 Evo выйдет в этом месяце ). Тогда лучше поставить отдельно микросхему ePoP (если сломается просто заменить на плате и всё)

Ещё один камень в огород Flash памяти: http://geektimes.ru/post/250406/

Добрый день!
Про процессор узнал совсем недавно, но идеи (сильно упрощённые) возникали ещё в 1984-85 годах, когда учился в УПИ. И вот сейчас всплыли и оформились некоторые идеи. Если не в тему или мои идеи уже реализованы, прошу не судить строго. Это часть статьи, которую я пытаюсь опубликовать в Песочнице http://habrahabr.ru/
Обратимся к мультиклеточному процессору. Рассматривалась ли авторами процессора идея "мультикоманды"? Что я имею в виду? Это обычная машинная команда или группа команд, но она имеет динамический повторитель. В коде программы она занимает несколько байт, а во время исполнения программы дублируется в буфер команд заданное количество раз в зависимости от длины обрабатываемого массива. Каждую копию этой команды может обрабатывать своя клетка совершенно независимо и параллельно. Понятно, что каждая последующая копия команды обрабатывает следующий или следующие элементы массива своей клеткой. Этот механизм почти избавлен от накладных расходов на организацию циклов, не увеличивает размер компилированной программы, позволяет распараллелить обработку элементов массива на любое число клеток процессора. Кроме того, одна из клеток будет выполнять крайнюю операцию обработки массива и отслеживать необходимость дальнейшей обработки. При достижении требуемых условий, действия с массивом можно прекратить.

SvetlyNik wrote:

Добрый день!
Рассматривалась ли авторами процессора идея "мультикоманды"? Что я имею в виду? Это обычная машинная команда или группа команд, но она имеет динамический повторитель. В коде программы она занимает несколько байт, а во время исполнения программы дублируется в буфер команд заданное количество раз в зависимости от длины обрабатываемого массива. Каждую копию этой команды может обрабатывать своя клетка совершенно независимо и параллельно.

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

А по поводу DMA я тоже высказывал такую идею: большинство прерываний которые обслуживает процессор, сводятся к очень простым действиям - взять байт из порта и положить в память, фактически прерывание нужно только потому что это надо сделать в определённый момент. Так почему бы не поручить эту функцию устройству DMA, а процессору один раз в какой-то промежуток времени обрабатывать сразу пачку данных в памяти. Получается, что мы заменяем десяток прерываний одним, причём приходящим намного реже. Соответственно это может быть что-то такое: частота опроса, адрес в памяти, количество байт под буфер (0 - неограниченно, остальные значения циклическая перезапись) и возможность от DMA полчить ссылку и соответственно ID "задания". Как вариант, можно использовать уникальное значение, если буфер планируется небольшой, а значения возможны не все, то программа сама сможет определить границу затирая своевременно буфер, к примеру - нулями (ну например, данные приходят очень редко и на цикл обработки будет где-то одно значение, но что бы наверняка можно сделать буфер в 4 и не париться). Третий вариант, когда значение из порта пересылается, если там становится отличным от нуля значение и соотвественно надо в пару писать время этого события, то есть в буфер будет по два значения писаться. Итого, не надо теребить 1000 раз в секунду какой-то порт процессором, а раз в секунду просто посмотреть что там нам датчики отсигналили и точность будет потактовая. Критикуйте, но мне кажется что это реализуемо и идея стоящая.

VaalKIA wrote:

SvetlyNik wrote:

Добрый день!
Рассматривалась ли авторами процессора идея "мультикоманды"? Что я имею в виду? Это обычная машинная команда или группа команд, но она имеет динамический повторитель. В коде программы она занимает несколько байт, а во время исполнения программы дублируется в буфер команд заданное количество раз в зависимости от длины обрабатываемого массива. Каждую копию этой команды может обрабатывать своя клетка совершенно независимо и параллельно.

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

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

Можно поразмыслить и привести примеры, как эту команду можно реализовать в мультиклете:
один из вариантов -- это совместить команду с реконфигурацией и если в процессоре например 16 клеток, а вызывается команда "run kernel, 200", т.е. надо 200 раз вызвать параграф kernel, то run может действовать, например, так:
Автоматически реконфигурирует процессор и разбивает его на 16 ядер, на каждом из ядре запускает цикл по обработке параграфа kernel с количеством итераций, примерно равным 200/16 = 12(+8 остаток), остаток выполнить на одной из клеток или лучше раскидать на несколько, т.е. 8 клеток выполняют 13 итераций, остальные 8 клеток выполняют 12, в сумме получаем 200. В каждой итерации в параграф kernel передаётся свой индекс, по которому и осуществляется ориентация в массиве или во времени.

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

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

В принципе команду run можно сделать и в виде библиотечной функции, тогда она должна быть изначально в библиотеке для разработчиков, поставляемой с мультиклетом(если такие библиотеки есть). Если делать в виде библиотечной функции, то легче наверно сделать, через реконфигурацию, т.е. если например имеется 256-клеточный процессор, который уже реконфигурирован как 200 + 56 клеток и на 200-клеточной части вызывается функция "run(kernel,305)"(в таком случае у функции можно сделать возможным передачу нескольких индексов), то эта функция внутри сначала запоминает, как реконфигурирован процессор, чтобы потом восстановить. Потом рассчитывает на сколько потоков(клеток) надо разбить 200-клеточную часть(200/305 => 1), потом на каждом потоке запускается функция по расчёту диапазона индексов, который будет использоваться в данном потоке, после чего в цикле по данному диапазону вызывается параграф kernel. По завершению обработки параграфа восстанавливается предыдущее состояние реконфигурации и продолжается дальнейшее выполнение кода.

Вот ссылка на статью пользователя SvetlyNik http://habrahabr.ru/post/258175/ . Там есть комментарии по этому поводу.
Процитирую себя:
Потенциально преимущества: уменьшение занимаемой памяти программ и ускорение загрузки команд.
Только вопрос в какую логику это выливается в ядре, получится ли это реализовать просто.
Сейчас у нас есть .rept .endr в ассемблере для простого повторения команды.
Но иногда, бывает нужно не просто повторять команду, а повторять с измененной ссылкой на аргументы.
Но, чтобы разработчики ядра это сделали аппаратно необходимо доказать ощутимую пользу от этого усложнения ядра.
Буфер у нас в каждой клетке на 64 команды.

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

krufter_multiclet wrote:

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

Думаю, что это зависит от реализации, но конечно надо обдумывать свою реализацию и думать эффективна она или нет и есть ли в ней смысл или его нет.

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

Вот давайте представим, как может работать мультикоманда:
1) Все клетки считывают по своей команде из буфера кода -- или как там у вас работает ?
2) На втором шаге они выполняют(если могут) считанные команды, но одной из клетки попалась мультикоманда и первым шагом её выполнения является разослать свою копию остальным клеткам. Возможно даже единственное действие мультикоманды -- это рассылка нужной команды клеткам, тогда "первая" клетка посылает её и себе в том числе, ну или делает вид, что посылает...
3) Все клетки получают мультикоманду(или уже просто команду) в специальном формате.
4) Каждая клетка вычисляет свой индекс и выполняет соответствующее действие -- если рассчитанный индекс за пределами диапазона, то команда не выполняется и становится известно, что это последняя итерация.
5) Клетки выполняют пункт 4 повторно многократно, пока одна(или несколько) из клеток не выйдет за диапазон обрабатываемых индексов и не установит соответствующий флаг окончания данных обработок.

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

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

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

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