Комментарии 11
На мой взгляд, главный плюс ухода от вендорских IP - это появление у разработчика компетенций другого, значительно более глубокого уровня.
Сам практикую изобретение велосипедов - FFT, CORDIC, фильтры... А часто эти велосипеды работают на бОльших частотах и с меньшими ресурсами.
Концепция FIFO, которое умеет манипулировать целыми пакетами довольно интересная (для своих задач). Но если бы оно было совместимо с AXI-Stream, толку было бы намного больше. Всякие дополнительные признаки можно пихать в tuser.
Добрый день!
Интересные эксперименты. Насчёт универсальности есть вопросы.
Работа FIFO должна быть пакетной. Причем пакеты могут быть произвольной длины, даже некратной ширине обеих шин.
Этот пункт крайне важен. В большинстве инженерных задач базовой единицей информации является не байт и не слово данных, а именно пакет. Например, видео‑ или IP‑пакеты.
Вроде это слишком строгое требование. Есть например всякие wormhole-routing алгоритмы, где пакеты дробятся на флиты, а флиты например в одно слово размером. Не всегда инфа пакетная.
Как будет работать предложенное fifo, если данные приходят back-to-back? Если правильно понимаю, в этой реализации фифо есть оверхед по тактам и back-to-back не получится.
Какой оверхед всех управляющих структур? Иногда бывает брамок не хватает, не слишком ли много съест управляющая инфа?
Какова latency? Правильно ли понимаю, что 3-4 такта? А если требуется меньше?
Вроде это слишком строгое требование. Есть например всякие wormhole-routing алгоритмы, где пакеты дробятся на флиты, а флиты например в одно слово размером. Не всегда инфа пакетная.
Здесь я поставил требование пакетности именно исходя из своих задач. Изначально FIFO проектировал для 10gig ethernet. Там пакеты - естественная вещь. Потом под видео-обработку это отлично легло, ведь строки - это по сути пакеты. Для работы с памятью тоже удобно оказалось.
Но понятно, что у кого-то могут быть иные задачи, где пакеты неудобны. Я не претендую на полную универсальность для всех задач. Да и вряд ли это возможно сделать один модуль для всего.
Как будет работать предложенное fifo, если данные приходят back-to-back? Если правильно понимаю, в этой реализации фифо есть оверхед по тактам и back-to-back не получится.
"back-to-back" - не очень понял что это за режим. Вообще в FIFO можно записывать хоть по-байтно (а точнее по-тактно). То есть записал слово данных, затем любая пауза, еще слово, и снова любая пауза. Заголовок добавляется только при записи последнего слова пакета.
Какой оверхед всех управляющих структур? Иногда бывает брамок не хватает, не слишком ли много съест управляющая инфа?
Оверхед, ну то есть заголовок, фиксирован. Это 32 байта. Например для пакетов в 1024 байта - это лишних 3% адресов памяти, для пакетов 4096 байт - менее 1%. А для меленького пакета в 32 байта это уже 50% - чудес не бывает.
Какова latency? Правильно ли понимаю, что 3-4 такта? А если требуется меньше?
для записи - 1 такт паузы между пакетами должен быть.
для чтения чуть сложнее - задержка выдачи данных после запроса - это 4 такта. Но там еще пара тактов будет после выдачи пакета. То есть если держать REQ = 1 всё время, то пакеты будут выдаваться с интервалами 6 тактов между ними.
В принципе, для широких выходных шин можно сократить задержку с 4 тактов до 3 без ущерба для fmax. А если убрать удержание значения при паузе - то до 2 тактов
Спасибо за ответы. skip -- интересный функционал.
"back-to-back" - не очень понял что это за режим
Когда первое слово следующего пакета приходит (или уходит) в такте, следующем за последним словом предыдущего пакета, т.е. без пустых тактов между пакетами.
В целом, как fifo отреагирует на ситуацию, когда приходит например 10 пакетов и нет пустых тактов ни между пакетами, ни внутри пакета между словами.
для чтения чуть сложнее - задержка выдачи данных после запроса - это 4 такта. Но там еще пара тактов будет после выдачи пакета. То есть если держать REQ = 1 всё время, то пакеты будут выдаваться с интервалами 6 тактов между ними.
Может чего-то не понимаю, даже для скоростей 10G достичь line-rate скоростей обработки не получится? А если выше 10G?
Оверхед, ну то есть заголовок, фиксирован. Это 32 байта. Например для пакетов в 1024 байта - это лишних 3% адресов памяти, для пакетов 4096 байт - менее 1%. А для меленького пакета в 32 байта это уже 50% - чудес не бывает.
Высокая гранулярность FPGA создана для чудес). Не считаете ли избыточным накладывать на пользователя fifo overhead до 37.5%, если он не факт что будет пользоваться всеми байтами метаданных?
Спасибо за интерес к статье.
В целом, как fifo отреагирует на ситуацию, когда приходит например 10 пакетов и нет пустых тактов ни между пакетами, ни внутри пакета между словами.
Один такт между пакетами при записи должен быть обеспечен писателем. Но если он будет гнать непрерывно, то FIFO не сломается, просто проигнорирует первое входное слово.
Но записать можно и поток который идет без перерывов. Просто нужно первое слово записать как метаинформацию на вход EXTRA_IN. И тогда оно не пропадет, и будет доступно на выходе. Такой трюк гарантированно будет работать для всех вариантов разрядностей входной шины, кроме 32-х байтного варианта.
Может чего-то не понимаю, даже для скоростей 10G достичь line-rate скоростей обработки не получится? А если выше 10G?
10 Гигабит это ведь несколько маркетинговая цифра :) Просто взяли и умножили частоту шины xgmii (156,25) на ее разрядность (64). На самом деле там часть байт - служебные. Это преамбула -8 байт, terminate - 1 байт, и как минимум должен быть один байт idle.
А если говорить про IP-уровень (v4), так перед ним 12 байт MAC адреса и 2 байта для протокола. Еще и сам заголовок IP - это 20 байт. И для реальных данных там пропускная способность ниже формальной битовой скорости.
А на практике, я работал с этим так: Пока давал запрос на FIFO для пакета - я передавал на выходную шину все mac-адреса и IP-заголовок, а когда от FIFO начинали идти данные, то я переключал уже их на выходную шину. Тоже самое я делаю и с SDRAM. Запрашиваю данные из FIFO, а сам в это время строку памяти активирую. В итоге холостых тактов нет
Высокая гранулярность FPGA создана для чудес). Не считаете ли избыточным накладывать на пользователя fifo overhead до 37.5%, если он не факт что будет пользоваться всеми байтами метаданных?
не очень понял откуда 37 взялось
вот для примера, сейчас FIFO используется для видеообработки. Длина строки - 1280 байт, накладные расходы получаются 32/1280 = 2,5%. есть накладные расходы - да. Но насколько это большая плата за универсальность?
А ну и сами метаданные появились несколько случайно)
изначально был вариант с шириной bram - 8 байт. То есть только для служебной внутренней инфы. Затем я подумал - пусть будет запас, и сделал 16 байт. И на одном проекте так получилось, что этот запас понадобился срочно. А у меня он был, и менять ничего не нужно было - ускорило разработку. Ну а раз так, то я подумал - надо увеличить резерв еще. И теперь 32 байта ширина. Вот отсюда и взялись 24 байта метаинфы: 32-8 = 24
10 Гигабит это ведь несколько маркетинговая цифра :) Просто взяли и умножили частоту шины xgmii (156,25) на ее разрядность (64). На самом деле там часть байт - служебные. Это преамбула -8 байт, terminate - 1 байт, и как минимум должен быть один байт idle.
Это верно, но это снаружи ПЛИС. Всё же производители и потребители данных внутри ПЛИС не связаны этими ограничениями. Одна из важных функций FIFO состоит в сглаживании различий скоростей производителей и потребителей, всплесков. FIFO, в котором есть место, не должно требовать производителей данных подождать. Хак с EXTRA_IN -- это прикольно, но это хак).
Пока давал запрос на FIFO для пакета - я передавал на выходную шину все mac-адреса и IP-заголовок, а когда от FIFO начинали идти данные, то я переключал уже их на выходную шину.
Смысл понятен, оптимизировались под свою задачу. Но правильно ли в случае универсального FIFO полагаться на конкретику конкретных протоколов и делать такие предположения о пользователях?
не очень понял откуда 37 взялось
Как гипотетический пользователь фифо, прикидываю издержки. По Вашим данным при малых пакетах издержки будут до 50% (32 байта). Из этих 50% 12.5% (8 байт) инфраструктура фифо, 37.5% (24 байта) метаданные пользователя. Издержки на инфраструктуру фифо можно принять (обязательные), метаданные -- это уже зависит от задачи, где-то их много, где-то нет совсем (необязательные). Не могут ли метаданные (а может и инфра) храниться в отдельной структуре?
В целом, интересные эксперименты, но всё ли выжали, что можно, из конструкции? Будет ли Ваше решение масштабироваться на более высокие скорости? В 40G 32 байта шина, в 100G -- 64 байта, что-то порядка 312 МГц и данные могут идти примерно каждый такт.
Мне кажется мы о разных вещах говорим. Если у вас шина xgmii на входе, то разрядность входа записи FIFO будет выбрана равной ширине этой шины - 8 байт. Это очевидно уже не вопрос FIFO. Разрядность выхода чтения для своей внутренней логики - выбираете из доступных, которые поддерживает FIFO, хоть 32 байта.
по быстродействию - я подробно расписал в главе 7. Там я для двух разных микросхем указал достигнутые частоты для ВСЕХ комбинаций разрядностей шин. Пересмотрите еще раз - там конкретные цифры для обоих доменов.
то что при малых пакетах накладные расходы растут - это очевидная вещь. Это справедливо для того же ethernet и для любого другого протокола. Когда вы гоняете маленькие пакеты - то отношение заголовок/данные растет и средняя скорость падает. Странно даже обсуждать и удивляться этому...
А пользовательские метаданные - это просто бонус. Это не про проценты. Если вам не нужны они - считайте что их нет. Плотность заполнения блочной памяти полезными данными определяется не метаданными пользователя, а отношением длины пакета к внутренней ширине слова памяти FIFO.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Именно таким должно быть универсальное FIFO для FPGA: уходим от вендорских IP