Выравнивание производительности 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

 

[jojo]

Да, надо ещё подумать. Трудящиеся страдают от наплыва АСИКов.
У них появился интерес к ПЛИС, но нынешние алгоритмы все АСИК-незащищённые. Труба им всем, если ничего не сделать.

А 1600 шт. мультиплексоров 1600 в 1 много места займут? Я понимаю, что вопрос странный, но много или мало по сравнению с чем-нибудь известным - SHA1, например?

Моя идея сделать что-то вроде старого crypt, в котором соль влияла не на данные, а на связи внутри ядра.

[yes]

А 1600 шт. мультиплексоров 1600 в 1 много места займут?

ну в АЗИКе тоже никто не будет набирать из 2-1 мультиплексоров. синтезирует логическую функцию с ~1600 входами, у ячейки в стандартной библиотеки 4 входа (но если надо, то многовходовые ячейки-мультиплексоры можно специально разработать, чуть дороже дизайн выдет) - если не ошибаюсь, то что-то типа (1600/4)*log(1600,4) приблизительно 2К ячеек, что ничто

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

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

я не знаю размеров вложений в коин-азики, но может переход от 100К к 10М по стоимости разработки, охладит пыл