И ещё вопрос, по ссылке на ваш проект в описании сказано следующее:
Additional features like encryption can be added with zero impact on the system’s performance.
. Подскажите, как это измерялось или на чем базируется предположение? Учитывая, что время на зашифрование пакетов существенно разнится в зависимости от размеров пакета, не говоря уже об особенностях алгоритма шифрования, интересно, как вы это планируете реализовать, не ухудшив производительность?
По поводу tcp и саморегулируемости, он не только сбрасывает газ, но может и добавлять его, когда видит такую возможность, в результате могут появляться ощутимые скачки. Суммируя ваш ответ, правильно ли понимаю, что в девайсе никакого управления потоком не реализовывали, даже на ethernet уровне, и такие вещи не планируете?
Вы пишете, что теряются пакеты когда переполняется fifo, это будет вызывать повторные пересылки у tcp (хоть инкапсулятор не знает о типе нагрузки, о потерях пакетов узнают клиент и сервер tcp и начнут реагировать), будет уменьшаться congestion window у отправителя да и просто больше подтверждений будет сыпаться вместо полезного трафика, т.е. пойдет деградация. Спору нет, если нагрузка слабая или не tcp, никто и не заметит, а вот на полную если загрузить с одного клиента tcp, тогда, по-моему, пойдут чудеса.
Знаете, с синтезом и проектированием под FPGA хорошо знаком) Вопросы задавал не спроста, а с целью обогащения опытом, есть серьезные подозрения (но, конечно, могу и ошибаться) что в вашей реализации будут существенные просадки для tcp и прозрачной ваша реализация не будет. Думал, что вы это уже решили, похоже ещё не добрались.
Это интересно, а не пробовали замерять деградацию производительности для таких случаев (переполнения fifo)? Особенно интересно как поведёт себя девайс в случае нагрузки tcp, какие просадки будут. На уровне ethernet никакого flow control не используете? И если не используете, то по каким соображениям?
Вот всё-таки не понял, почему вы FPGA ограничили 10Гб/с или это ограничения вашей реализации? Вон у xilinx есть корки для 40 и 100Гб для представителей 7 серии. Насколько понимаю реализовано это через GTX/GTH трансиверы. А по поводу частот, у них там просто широкие шины внутри, судя по рисункам, 128 или 256 бит.
С ассимптотическими оценками я определенно спорить не буду. У меня решения нет, однако наблюдаю коммерческие IP-ядра для FPGA, которые по данным их спецификации поддерживают пропускную способность до 100Гбит/с, и раз уж в этой статье речь о кодах Хаффмана, то не вижу причин не спросить об эффективной реализации. Что касается try-catch: обычная проверка if-ом чем вас не устраивает?
И бонусный вопрос, если есть желание присмотреться пристальнее: как можно реализовать построение дерева за константное и малое количество шагов? Вопрос актуален для аппаратных реализаций (например fpga), когда за каждый такт выдаётся очередной символ и нужно динамически построить таблицу для блока в десяток КБ, а возможности буферизации на кристалле очень ограничены.
PS: я бы не использовал try catch для выхода из цикла.
Знаете, в универе когда-то писал такой курсач/лабу. И первым вопросом попросили замерить производительность (скорость, степень сжатия и т.д.) моей реализации на стандартных бенчмарках, например Calgary Corpus. А какие скорости и коэффициенты сжатия у вас? Второй вопрос: не пробовали ли сделать ещё и статическую реализацию? То, что у вас, насколько понимаю терминологию, называется динамической реализацией, когда таблица частот не фиксирована. Есть и статическая, когда таблица постоянна и задаётся пользователем самостоятельно. Деревья Хаффмана со статической/динамической таблицей есть в алгоритме сжатия Deflate, который используется в архиваторах, поддерживающих формат Zip.
worldmind, в случае крипты обычно делается защита периметра и в теории, если вы добрались до чипа (хотя бы вскрыли корпус), то там уже ничего не должно было остаться, т.е. ключ уничтожен и защищать больше нечего. Уничтожение ключа это тонкость, но в стандартах тоже упоминается, обычно процедура состоит в нескольких перезаписях ячеек памяти ключа различными значениями, чтобы не только стереть ключ, но и всякие наводки, по которым косвенно можно установить биты ключа.
В теории (по требованию законодательств многих стран, в т.ч. стран СНГ) криптографические девайсы должны пройти процедуру сертификации, где в частности экспертами исследуются исходники и сам девайс на подобные уязвимости и где проверяется соответствие девайса криптографическим и прочим стандартам (а они как раз определяют требования по секьюрности, см. например американский FIPS, он очень лаконичен и там вроде было и про ваш пример с ключом и затиранием при вскрытии).
Статья супер. Понимаю, что вопрос не совсем по теме, но всё же где-то рядом: можно пару слов про защиту от атак по сторонним каналам? В свете примеров взлома rsa по акустическим каналам и потребляемой мощности интересно, что можно противопоставить на железном уровне, с софтом и hdl в этом случае более-менее понятно.
Не в курсе по Альтере, но у Xilinx точно ещё такого не было. В Zynq пару армов и плисина на кристалле, насчет пары DSP вы утрируете, их там скорее несколько сотен. А в версале на борту кроме армов и собственно плис с тысячами DSP-слайсов ещё и сотни процессорных VLIW-ядер.
Присоединяюсь к предыдущему вопросу. С HLS, что называется, только игрался, реализовывал несколько алгоритмов и сравнивал по ресурсам/скоростям со своими эталонами на vhdl. Поразило то, что существенно различных результатов можно добиться используя комбинации разных опций, но при этом было совсем не очевидно, когда остановиться, а когда попытаться попробовать ещё какие-то опции. Возможно, у вас есть какие-то критерии или метрики для этого?
HLS же, High Level Synthesis. Генерит rtl из C\C++ кода, разворачивает циклы или создаёт логику для итераций, делает конвейера, планирует регистры и их загрузку, реализует арифметику на dsp tile-ах и т.д. и т.п. По сути реализует логику алгоритма в железе. Правда пока считается, что делает это чуть хуже матёрого специалиста-человека.
Очень любопытный девайс этот Versal, правда информации пока не очень много. Здесь уже пытаются считать его производительность в связке с DeePhi.
Было бы интересно узнать, как Xilinx реализует планирование вычислительных ресурсов в рамках этого девайса или какие возможности планирования предоставит пользователям. В частности, что и как будет загружать данными набор из VLIW ядер и выгружать обработанные данные на нужных скоростях. Там какой-то суперкрутой компилятор-синтезатор или может что-то динамическое в железе реализовано или гибрид и того и другого?
PS: я бы не использовал try catch для выхода из цикла.
Было бы интересно узнать, как Xilinx реализует планирование вычислительных ресурсов в рамках этого девайса или какие возможности планирования предоставит пользователям. В частности, что и как будет загружать данными набор из VLIW ядер и выгружать обработанные данные на нужных скоростях. Там какой-то суперкрутой компилятор-синтезатор или может что-то динамическое в железе реализовано или гибрид и того и другого?