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

 

[yes]

сомневаюсь в эффективности - входные мультиплексоры в ПЛИС достаточно маленькие и их структура скрыта от пользователя (в старых тулзах ксайлинса была доступна визуализация switch matrix-ов, но вот отреверсить их не получалась, даже какие-то предположения у меня не получилось сделать - там не мультиплексоры N->1, а какие-то хитрые наборы ключей, которые перемыкали между собой линии трассировки неким псевдослучайным, с точки зрения стороннего наблюдателя, образом. наверно, чтобы экономить конфигурационную память)

ну и в АЗИКе мультиплексор достаточно маленькая логика (кажется, что для большинства библиотек, ячеек нужно log4 от числа входов, что фигня)

кажется, помогло бы размазывание входных переменных по большой площади - но это и для ПЛИС вредит, но меньше

[jojo]

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

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

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

[one_eight_seven]

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

Кому труба и почему?
И вообще, что плохого в том, что появляется специализированное железо именно для вычисления хэш-функций?

[jojo]

Кому труба и почему?
И вообще, что плохого в том, что появляется специализированное железо именно для вычисления хэш-функций?

Труба, главным образом, наступает для GPU. Ну, и что говорить, FPGA.

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

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

[one_eight_seven]

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

Сообщение отредактировал one_eight_seven - May 6 2018, 06:53

[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.

[yes]

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

про мультиплексоры - сорри за повтор, но не нагрузите этим АЗИК - подумайте про готовое IP : PCIE - то есть обмен с ПК, MIG - то есть внешняя память - эти два для больших объемов данных, внутренняя память - какие-то сверхширокие слова - этим и GPU можно уделать, наверно, DSP блоки - используйте умножение, по-моему вполне возможно для "перемешивания битов" - не вырождается множество, и т.д
то есть нужно сделать такую функцию, которая не параллелится легко, ну то есть 1 ПЛИСину не получится заменить 10 АЗИКами

это может дать некотурую фору - так то АЗИК всегда выиграет, но из-за большого (большЕго) в случае использования HARD IP порога стоимости, можно порезвиться пока кто-то рискнет вложиться в АЗИК

[Shivers]

Библиотеки бывают разные, даже для одной технологии. Если вы покупаете библиотеку за деньги, то имеете право затребовать нужный элемент. Может, С-элемент вам и не сделают, но три-буф с бас-холдом обязаны, т.к. это совершенно обычные элементы. Сделать три-буф очень просто - надо просто разломить надвое защелку. Один инвертор для управления и один ключ на 4-х транзисторах, итого 6 транзисторов. Всего лишь.
Синтезаторы действительно очень не любят, когда на шине больше одного драйвера. Но мультиплексоры, о которых я говорю, можно писать сразу на гейт-левеле, минуя синтез. Потом делается топология этого мультиплексора в P&R туле, выписывается либ и леф .. собственно и всё, его можно использовать в дизайне. STA отлично такие мультиплексоры видит. Не нужен ни аналоговый бэк-энд, ни характеризация, только обычные цифровые бэкэнд тулы.

[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 для него при условии нормальной окупаемости (а обыватель майнит на всём что шевелится).
Проблема в том, что я ещё не идентифицировал такое решение, а те кто знает, делиться информацией не спешат.

[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 сейчас куча решений выпускается для вставки в слот, не?..

[jojo]

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

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


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

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

На большинстве отладочных плат стоит 1 FPGA.
Хост лучше задействовать, чтобы снизить масштабируемость.
ML/NN я еще не щупал. Что-нибудь для примера есть стоящее?