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

[Shivers]

Если честно, я вообще не понял о чем топик стартер написал - для меня первый пост как на китайском. Но если нужен очень быстрый многовходовой мультиплексор, то раньше часто использовали буферы с третьим состоянием (tribuf) и подтяжкой (bushold). Можно было делать мультиплексоры и 16 в 1 и 32 в 1 - работало очень быстро. Я не уверен, что это хорошее решение на финфетах или даже суб-100нм (из-за паразитов), но если очень надо то имеет смысл проверить.

[jojo]

Если честно, я вообще не понял о чем топик стартер написал - для меня первый пост как на китайском. Но если нужен очень быстрый многовходовой мультиплексор, то раньше часто использовали буферы с третьим состоянием (tribuf) и подтяжкой (bushold). Можно было делать мультиплексоры и 16 в 1 и 32 в 1 - работало очень быстро. Я не уверен, что это хорошее решение на финфетах или даже суб-100нм (из-за паразитов), но если очень надо то имеет смысл проверить.

Смысл в том, что я вынуждаю разработчиков микросхемы ставить мультиплексор туда, где у меня его не будет. У меня 1000 немного отличающихся прошивок FPGA, а в ASIC мультиплексоры на 1000 входов перед каждым триггером.

Пример.
В большом Kintex-7, допустим, получится 10 конвейеров * 500 МГц = 5 гигахэшей/сек.
Специализированный вычислительный блок (т.н. АСИК) даст сопоставимую производительность по порядку величины. Но их, блоков, продают 100500 шт, они дешевые, и net hashrate улетает в небеса.

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

[Doka]

Смысл в том, что я вынуждаю разработчиков микросхемы ставить мультиплексор туда, где у меня его не будет. У меня 1000 немного отличающихся прошивок FPGA, а в ASIC мультиплексоры на 1000 входов перед каждым триггером.

вот еще идейка в порядке мозгового штурма:
ставить ПЛИСы на плате в кортеж: FPGA1 -> FPGA2 -> FPGA3 -> FPGA4 (направление датастрима, но нужно кастомное железо или вариант объединять платы с ПЛИС через встроенные MGT/GTX)
и заливать туда разные прошивки, которые будут являться частью одного алгоритма, т.о. начиная от определенной ёмкости ПЛИС, понадобится 4 асика, выполняющих эти 4 разные функции...
но это только концепция - чувствую чего-то я в ней явно не доглядел...

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

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

ну, DDR легко и просто обходися упаковкой в SiP, хоть сколько кристаллов DDR клади рядом (притом на фото не кристаллы, а закорпусированные, можно сделать еще компактнее):


А с PCI-E надо решить что и ради чего там будет гоняться,
т.е. подразумевается что должен задействоваться хост-процессор для части функций, которые нереализуемы/дорогореализуемы на FPGA/ASIC ???

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

так для ML/NN сейчас куча решений выпускается для вставки в слот, не?..