Мегагерцы не зависят от числа клеток, и может оказаться, что, повышая частоту, потеряем производительность, особенно на определенных задачах. Для достижения на 180 нм частоты Интела, нужно отказаться от ASIC и вручную делать топологию, что крайне ресурсоемко и далеко не всегда оправданно. Кроме того, на современных техпроцессах (порядка 20 нм) результаты ASIC сопоставимы с ручной разработкой.

Допустимая тактовая частота процессора, при заданной топонорме, определяется количеством блоков логических элементов на линии. Число блоков может быть уменьшено:
1) Конвееризацией вычислений.
2) Оптимизациями на этапе синтеза.
3) Применением специальных «быстрых» библиотек при синтезе.

Поскольку первые два пункта требуют больших трудозатрат, при разработке процессора R1 вопросы оптимизаций на этапе синтеза не поднимались (все было синтезировано стандартным САПРовским синтезатором, что не очень эффективно), а оптимизировались и конвееризировались только те линии, длинна которых не позволяла выйти на частоту 100 МГц.

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

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

Вот сейчас пришёл коллега, и говорит, что скомпилировал и запустил на отладочной плате Rust-пример, мигающий лампочками.
Так что не всё так плохо.

Наш опыт краудфандинга на kickstarter с проектом устройства криптозащиты Key_P1 на процессоре Multiclet P1 (которое не есть теория, а реально продается) показал, что технически сложные устройства массово средств не собирают, а ресурсы уходят в раскрутку сайта kickstarter. Тем более, такие комплектующие, как новый микропроцессор:). Шансы собрать тысячу энтузиастов по 20 тр для его выпуска равны нулю. Более реальным сегодня мы видим путь IPO (initial public offer) под проект настольного суперкомпьютера.

Сам разработчик заявляет что порядка 2000 тактов нужно

Да, вы правы: в исходную таблицу вкралась опечатка, и тысячу тактов потеряли. Должно быть 1928.

Так же хотелось бы поподробней причины провала.

Поясните, пожалуйста, о чём речь в вопросе?

Где именно простои, как планируете их исправлять (в железе, в компиляторе)?

По нашим очень грубым оценкам, в задачах типа CoreMark ожидать от компилятора улучшения в 1,5...2 раза не стоит, речь, скорее, может идти о 20...30%. Пример с popcnt в этом смысле, скорее, исключение, показывающее, что всякие «низкоуровневые» критичные к производительности вещи, типа FFT и FIR/IIR, на Си писать не стоит; поэтому основной прирост производительности мы планируем получить доработкой аппаратной части. Тем более, сейчас отчётливо видны недостатки данной конкретной аппаратной реализации, устранив которые, мы рассчитываем в следующей ревизии процессора ускориться в 4,5...5 раз.

Приведенные в сравнении конкуренты это одно-алушные (в большинстве) процессоры, а у вас как минимум 4 клетки.

Здесь нас подстерегает один очень коварный момент: да, у конкурентов АЛУ одно, но оно содержит несколько исполнительных устройств, каждое из которых может за такт исполнять несколько инструкций. Более того, умножитель у них не входит а АЛУ, а стоит рядышком, и в «количество АЛУ» вклад не вносит. У нас же каждая клетка устроена более примитивно, а необходимый параллелизм достигается числом клеток.
Поэтому более корректно сравнивать не число АЛУ, а количество операций, которое процессор может выполнить за такт.

Какая производительность на одной клетке?

Если наш FFT задумает исполняться на одной клетке, у него на это уйдёт 6008 тактов. При этом он освободит три другие клетки, которые, используя свойство динамической реконфигурации, мы прямо «на ходу» сможем параллельно направить на решение ещё трёх разных задач. Более того, так же, «на ходу» можем, при необходимости, решать задачу и на двух, и на трёх клетках.

Речь идёт о конкретной аппаратной реализации совершенно новой архитектуры, причём о второй реализации, и тот факт, что мы уже сравниваемся с монстрами, имеющими 30+ лет опыта в разработке DSP и десятки (сотни?) реализаций в кремнии, вселяет оптимизм. Более того, уже сейчас видны пути повышения производительности следующего процессора в разы.

По таблице — не видно, поскольку там нет упоминаний про исполнителные устройства.

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

C66х для решения той же задачи потребовалось в полтора раза больше операций (читай: «электричества»); при этом, имея в два раза больше исполнительный устройств, справился с задачей он всего на 30% быстрее.
А, поскольку это — VLIW, то получается, что «параллелит лучше» не процессор, а компилятор, с его неограниченными ресурсами и вИдением всей программы.

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

Ага. И кучу другого, уже написанного, софта.
Всё-таки Rust и прочие Haskell — пока больше экзотика «для ценителей». Да, и как у него с эффективностью использования ресурсов? А с низкоуровневым доступом к аппаратуре? Как бы не получилось так, что, чтобы общаться с железом, нужна спец.библиотека, написанная на… Си.
Ну, и, кроме того, имея нормально работающий бэкенд, мы (почти) автоматически получаем поддержку всего зоопарка языков, знакомых LLVM.

Проблема в том, что порт контроллера с питанием 3,3В
подтягивают на 5В. Совсем защёлкнуться ему не даёт сопротивление
подтяжки, но жизнь портит изрядно.