Выравнивание производительности FPGA и ASIC на функциях хэширования, keccak Опции

[jojo]

Коллеги, есть вопрос.

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

block'=MUX(block, select);
hash'=Keccak(block');
hash=MUX(block', select);

Таким образом конвейер Keccak в ASIC-е обрастает мультиплексорами, на которые тратится площадь кристалла.
В FPGA мультиплексоры и так есть в коммутационных ресурсах, но нужно собрать тьму прошивок под каждое значение входа select и грузить их по Selectmap.


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

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

Прикрепленные файлы

 keccak.zip ( 3.9 килобайт ) Кол-во скачиваний: 15

 

[Doka]

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

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

там не мультиплексоры N->1, а какие-то хитрые наборы ключей, которые перемыкали между собой линии трассировки неким псевдослучайным

у xilinx на эту тему много патентов - оттуда можно часть информации взять, там действительно дикие switching matrix

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

ага.. а еще он может своё железо по предзаказу продавать... отличная модель.. время == деньги

я имею поверхностное представление об алгоритмах криптовалют, но кажется очевидное решение - брать хэш от большого объема данных, как делают в "процессоро-ориентированных" коин-алгоритмах. за счет того, что ПЛИС имеют DDR контроллеры и сразу идут в больших корпусах, где много ножек и т.п. - то за счет этого можно резко поднять вложения в разработку АЗИКа (то еcть добавить DDR PHY, разрабатывать сразу под большой корпус и т.д. - главное, невозможность сделать такой АЗИК на дешевых 130нм/90нм технологиях)

Увы, и DDR давно не останавливает, хотя имеет ограниченную применяемость для алгоритмов:
делают SiP: само ядро с DDR PHY + кристалл DDR, получается компактно, удобно, молодёжно (и с точки зрения схемотехники майнеров не меняется ничего

upd: еще ПЛИС имеют внутреннюю память и DSP блоки - то есть добавив какие-то "очень широкие слова" и операции * - можно выиграть. но это ес-сно, в предположении, что ПЛИС мы имеем на 3-4 поколения новее, чем АЗИК - например, 28нм против 130нм

это теплее.. у меня самого первой мыслью было задействование FPGA-специфичных блоков, навроде UltraRAM (Xilinx), на которую очень хорошо ложится scrypt например,
но в целом солидарен: ситуация неутешительная - при паритете технологий не переиграть, единственная вещь, на которой можно сыграть:
скорость разработки ASIC vs RTL для FPGA
Это надо принять, и этим пользоваться, дарю бизнес-модель: разрабатываем RTL для альткоина под FPGA, выбрасываем на рынок прошивку для распространённых плат с вкомпиленым devfee, одновременно с этим договариваемся с одним из асик-игроков о продаже RTL (тайм-ту-маркет, все дела) - итого в запасе будет 4...7мес, в зависимости от бизнес-процессов игрока.

[jojo]

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

В общем да, не факт, что снижение. Это нужно проверить.

Как я понял, нужно задействовать всю пропускную способность PCI Express и DDR4,
только тогда изготовители ASIC немного отстанут.

С другой стороны, тогда можно просто сделать полезное решение HPC,
а обыватель вполне может купить FPGA для него при условии нормальной окупаемости (а обыватель майнит на всём что шевелится).
Проблема в том, что я ещё не идентифицировал такое решение, а те кто знает, делиться информацией не спешат.