Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Абсолютно во всех IP ядрах используется IEEE 754 (16/32/64/128 бит). Вы выиграли в скорости, уменьшив диапазон чисел, браво!
Так может, стоило бы сразу взять IEEE754 16 бит (половинная точность)? Получится и еще быстрее, чем Ваши 23 бита, и все в рамках стандарта.
Если честно, в инженерных вопросах я всегда против изобретения велосипеда. Есть стандарт, и ему надо следовать.
Так может, стоило бы сразу взять IEEE754 16 бит (половинная точность)? Получится и еще быстрее, чем Ваши 23 бита, и все в рамках стандарта.
Если честно, в инженерных вопросах я всегда против изобретения велосипеда. Есть стандарт, и ему надо следовать.
Во-первых, быстрее не получится. При таких затратах ресурсов скорость для fp16 и "велосипеда" практически одинакова. Но точность fp16 гораздо хуже. Также, например, при реализации БПФ на 64К-128К точек, в связи с интегральной природой алгоритма БПФ, у fp16 наступит переполнение. Итог — неверный результат на выходе.
Во-вторых, в идеале нужно смотреть на реальные проекты с забитой ПЛИС на 70-80%, тогда есть смысл сравнить в боевом режиме. Я делал "велосипед #2" — формат fp18 и сравнивал с fp23. Поверьте — разницы по скорости практически нет, а по достижимой точности — солидно. По ресурсам отличие на 15%. Но даже fp18 пригодился в свое время на Virtex-4 для реализации схемы все того же БПФ.
В-третьих, "велосипеды" конкретно на FPGA успешно справляются в прикладных задачах, где не требуется универсальности. Зачастую разработчикам приходится заниматься изобретением велосипедов, поскольку действительно крутые IP-ядра бесплатно вам никто не отдаст. Я знаю реальные примеры, когда так называемый "велосипед" намного круче стандартный протоколов.
Дабы не быть голословным, приведу пример. Открытое ядро PROTEQ моего коллеги. Обеспечивает высокую скорость передачи данных по MGT линиям с требуемой надежностью. Занимает мало ресурсов ПЛИС и самое главное — быстро восстанавливается после возникновения ошибки. Протокол Aurora курит в сторонке, а PROTEQ в различных его вариациях успешно внедряется во многих наших разработках на ПЛИС.
Во-вторых, в идеале нужно смотреть на реальные проекты с забитой ПЛИС на 70-80%, тогда есть смысл сравнить в боевом режиме. Я делал "велосипед #2" — формат fp18 и сравнивал с fp23. Поверьте — разницы по скорости практически нет, а по достижимой точности — солидно. По ресурсам отличие на 15%. Но даже fp18 пригодился в свое время на Virtex-4 для реализации схемы все того же БПФ.
В-третьих, "велосипеды" конкретно на FPGA успешно справляются в прикладных задачах, где не требуется универсальности. Зачастую разработчикам приходится заниматься изобретением велосипедов, поскольку действительно крутые IP-ядра бесплатно вам никто не отдаст. Я знаю реальные примеры, когда так называемый "велосипед" намного круче стандартный протоколов.
Дабы не быть голословным, приведу пример. Открытое ядро PROTEQ моего коллеги. Обеспечивает высокую скорость передачи данных по MGT линиям с требуемой надежностью. Занимает мало ресурсов ПЛИС и самое главное — быстро восстанавливается после возникновения ошибки. Протокол Aurora курит в сторонке, а PROTEQ в различных его вариациях успешно внедряется во многих наших разработках на ПЛИС.
Ну что я могу сказать. Если это "внутренняя" жизнь Вашего IP, то Вы в праве делать что угодно. Если точно значете что разядность входных данных низкая (с АЦП, к примеру), снижение точности вполне оправдано. Да и то, насколько оправдано? Перемножение двух 12'h чисел (типовая точность АЦП) дает уже 24'h. в IEEE 754 — 32 это даже округлять не придется. А у Вас — придется, т.е. теряется точность.
Но если же этот формат будет передаваться в систему (SoC), программисты Вам точно спасибо не скажут. Потому что им придется самим следить за попаданием в диапазон чисел, ибо не стандарт.
По поводу PROTEQ — посмотрел ссылку. Автор тоже знатный велосипедист: на мой взгляд, куда лучше было бы повторить PHY от PCI-E gen1, т.к. схема пайпа шикарно описана у интела. Но для внутренних дел сгодится и это, тем более что корка открытая — единственный ее плюс. Imho
Но если же этот формат будет передаваться в систему (SoC), программисты Вам точно спасибо не скажут. Потому что им придется самим следить за попаданием в диапазон чисел, ибо не стандарт.
По поводу PROTEQ — посмотрел ссылку. Автор тоже знатный велосипедист: на мой взгляд, куда лучше было бы повторить PHY от PCI-E gen1, т.к. схема пайпа шикарно описана у интела. Но для внутренних дел сгодится и это, тем более что корка открытая — единственный ее плюс. Imho
На практике в таких вещах получается, что шумы квантования в любом случае меньше, чем даёт шум АЦП. То есть цифровой частью ну никак не улучшить аналоговую, если динамический диапазон маленький. Пролезающие в полосу шумы точно также усиливаются, как и полезный сигнал. В наших задачах точности формата FP23 было "за глаза".
К реализации специфического формата плавающей точки я, кстати, пришел не сразу. В первую очередь, мне не понравились монстрообразные IP-ядра от Xilinx, которые жрали очень много места, а на выполнение операций затрачивалось много тактов. Затем после оценки типовых задач по ЦОС стало ясно, что нет смысла копировать стандарт IEEE 754 в полной мере. Причина кроется в избыточности. Например, реализация сумматора «по стандарту» не обеспечит высоких скоростей без использования DSP48-узлов, которых в ПЛИС постоянно не хватает. Кастомный FP23 сумматор не требует DSP48-узла. Умножитель по стандарту требует 3 DSP48 блока, кастомный – всего один. Можно прикинуть, во сколько вырастет «бабочка» для проекта БПФ. А если учесть, что для реализации БПФ бабочек нужно log2(NFFT), то разница по ресурсам колоссальна. Сюда можно добавить RAMB память для хранения поворачивающих коэффициентов и линий задержки. FP32 и FP23 отличаются в 1.5 раза.
PHY PCI-e не формирует пакеты данных. Он не обеспечивает надежную передачу с исправлением ошибок. До кучи у него значительно ниже скорость передачи, чем у PROTEQ. Закономерный вопрос: почему Xilinx в свое время сделали Aurora, а не пользовались стандартными решениями? Это тоже велосипед со своими фичами и особенностями. В защиту PROTEQ приведу ещё один аргумент. Он позволяет передавать данные как по оптике, так и по печатной плате от ПЛИС к ПЛИС. Ограничений нет никаких. Посмотрите публикацию о PROTEQ моего коллеги по этому вопросу. В ней приведено реальное сравнение с Aurora / PCIe.
Вы можете и дальше утверждать, что велосипеды — зло, и нужно оставаться в рамках стандартов. Но лично моя практика и опыт моих товарищей-разработчиков говорит об обратном.
К реализации специфического формата плавающей точки я, кстати, пришел не сразу. В первую очередь, мне не понравились монстрообразные IP-ядра от Xilinx, которые жрали очень много места, а на выполнение операций затрачивалось много тактов. Затем после оценки типовых задач по ЦОС стало ясно, что нет смысла копировать стандарт IEEE 754 в полной мере. Причина кроется в избыточности. Например, реализация сумматора «по стандарту» не обеспечит высоких скоростей без использования DSP48-узлов, которых в ПЛИС постоянно не хватает. Кастомный FP23 сумматор не требует DSP48-узла. Умножитель по стандарту требует 3 DSP48 блока, кастомный – всего один. Можно прикинуть, во сколько вырастет «бабочка» для проекта БПФ. А если учесть, что для реализации БПФ бабочек нужно log2(NFFT), то разница по ресурсам колоссальна. Сюда можно добавить RAMB память для хранения поворачивающих коэффициентов и линий задержки. FP32 и FP23 отличаются в 1.5 раза.
PHY PCI-e не формирует пакеты данных. Он не обеспечивает надежную передачу с исправлением ошибок. До кучи у него значительно ниже скорость передачи, чем у PROTEQ. Закономерный вопрос: почему Xilinx в свое время сделали Aurora, а не пользовались стандартными решениями? Это тоже велосипед со своими фичами и особенностями. В защиту PROTEQ приведу ещё один аргумент. Он позволяет передавать данные как по оптике, так и по печатной плате от ПЛИС к ПЛИС. Ограничений нет никаких. Посмотрите публикацию о PROTEQ моего коллеги по этому вопросу. В ней приведено реальное сравнение с Aurora / PCIe.
Вы можете и дальше утверждать, что велосипеды — зло, и нужно оставаться в рамках стандартов. Но лично моя практика и опыт моих товарищей-разработчиков говорит об обратном.
Действительно, для оптики PCI-E не годится (слабые возможности clock recovery), но зато есть индустриальный PHY Serial RapidIO, поддерживающий даже Hot Swap. Служебные пакеты формировать — это вообще не аргумент. Если они нужны, есть куча стандартов (тот же PCI-E или SRIO), где все уже давно придумано — берите, да пользуйтесь, благо документации — море
Касательно аргумента об использовании DSP блоков. Удалось задействовать 1 DSP вместо трех? Замечательно! А если мигрировать проект на альтеру, или актель? Получается, Ваше решение не универсально, а привязано к конкретной ПЛИС. А значит, оно требует отдельного пунктика в ТЗ: использовать только 7й кинтекс :-) Но, не хочу умалять Ваших достижений — если потеря точности, и привязка к ПЛИС Вас устраивают, то результат действительно впечатляющий.
По поводу велосипеда. Ваша практика опирается на опыт проектов, где ПЛИС — конечный продукт. Как только ПЛИС станет позиционироваться как прототип ASIC (рано или поздно все коммерчески успешные проекты переводят в кремний), вот тут то все PROTEC и прочие велосипеды, торчащие наружу, пойдут лесом.
Поэтому повторюсь: пока велосипед является внутренней жизнью Вашего IP, нет проблем. Проблемы возникнут, если велосипед будет торчать наружу из Вашего IP.
Если и это для Вас не аргумент, задумайтесь — а зачем вообще придумывают стандарты??
Касательно аргумента об использовании DSP блоков. Удалось задействовать 1 DSP вместо трех? Замечательно! А если мигрировать проект на альтеру, или актель? Получается, Ваше решение не универсально, а привязано к конкретной ПЛИС. А значит, оно требует отдельного пунктика в ТЗ: использовать только 7й кинтекс :-) Но, не хочу умалять Ваших достижений — если потеря точности, и привязка к ПЛИС Вас устраивают, то результат действительно впечатляющий.
По поводу велосипеда. Ваша практика опирается на опыт проектов, где ПЛИС — конечный продукт. Как только ПЛИС станет позиционироваться как прототип ASIC (рано или поздно все коммерчески успешные проекты переводят в кремний), вот тут то все PROTEC и прочие велосипеды, торчащие наружу, пойдут лесом.
Поэтому повторюсь: пока велосипед является внутренней жизнью Вашего IP, нет проблем. Проблемы возникнут, если велосипед будет торчать наружу из Вашего IP.
Если и это для Вас не аргумент, задумайтесь — а зачем вообще придумывают стандарты??
По поводу PHY Serial RapidIO — интересное решение. Мы его тоже делали и даже используем для связи нескольких FPGA и DSP через RIO SWITCH. Но для SRIO намного сложнее реализация и ресурсов жрет, к сожалению, тоже много.
Полноценный PCIE для Xilinx требует HARD блока и предварительной инициализации. В ПЛИС количество таких HARD-блоков ограничено и как правило задействовано для связи FPGA с компьютером.
Да, мое решение применительно только к Xilinx, начиная с Virtex-4 и выше, хотя переделать под Altera несложно. Базовые ячейки у всех почти одинаковы. И IP-core от Xilinx тоже применимы только к Xilinx. :)
Мы пока не встречались с такими проблемами, где наш велосипед не справляется. Повторюсь, PROTEQ успешно используется практически в каждом нашем проекте и решает определенный класс задач, который в своё время не смогла обеспечить Aurora. И да, мы используем стандартные решения. В своих проектах мы применяем полностью стандартизированные решения (PCIe, DDR, SRIO, и т.д.), несмотря на то, что для каждого из этих решений у нас есть свой велосипед. Где-то подойдет велосипед, где-то стандарт. Все зависит от задачи.
Полноценный PCIE для Xilinx требует HARD блока и предварительной инициализации. В ПЛИС количество таких HARD-блоков ограничено и как правило задействовано для связи FPGA с компьютером.
Да, мое решение применительно только к Xilinx, начиная с Virtex-4 и выше, хотя переделать под Altera несложно. Базовые ячейки у всех почти одинаковы. И IP-core от Xilinx тоже применимы только к Xilinx. :)
Мы пока не встречались с такими проблемами, где наш велосипед не справляется. Повторюсь, PROTEQ успешно используется практически в каждом нашем проекте и решает определенный класс задач, который в своё время не смогла обеспечить Aurora. И да, мы используем стандартные решения. В своих проектах мы применяем полностью стандартизированные решения (PCIe, DDR, SRIO, и т.д.), несмотря на то, что для каждого из этих решений у нас есть свой велосипед. Где-то подойдет велосипед, где-то стандарт. Все зависит от задачи.
Понятно, что собственный велосипед люб и мил сердцу любого нормального инженера ;-)
Проблемы начинаются, когда внезапно оказывается, что решение нужно постоянно поддерживать, адаптировать под новые платформы и т.д. В итоге конечная стоимость собственного решения окажется выше покупного. С нашими нищенскими зарплатами инженеров (и оплатой за IP в валюте) до этого, конечно, не всегда добираешься, а вот в нормальной ситуации — легко...
Проблемы начинаются, когда внезапно оказывается, что решение нужно постоянно поддерживать, адаптировать под новые платформы и т.д. В итоге конечная стоимость собственного решения окажется выше покупного. С нашими нищенскими зарплатами инженеров (и оплатой за IP в валюте) до этого, конечно, не всегда добираешься, а вот в нормальной ситуации — легко...
Во-первых, быстрее не получится. При таких затратах ресурсов скорость для fp16 и «велосипеда» практически одинакова. Но точность fp16 гораздо хуже. Также, например, при реализации БПФ на 64К-128К точек, в связи с интегральной природой алгоритма БПФ, у fp16 наступит переполнение. Итог — неверный результат на выходе.
Можно положить те же 6 битов на экспоненту и переполнения не будет. Если относительная погрешность данных с АЦП больше 0.1% мантиссы в 10 битов должно хватить.
А подскажите… может я упустил при чтении… Ваша реализация поддерживает Subnormal numbers? Или Вам не требуется точность при очень малых значениях?
Субнормальные числа не используются, т.к. в процессе выполнения любых операций на выходе результат приводится к нормализованному виду, т.е старший бит мантиссы, который я называю "скрытым" равен 1 для ненулевого числа. Например, число "0х1" в формате fp23 запишется как {0x10, 0, 0x0000}, где битовые поля — {exp, sign, mant}. Причем, числа с меньшей экспонентой успешно поддерживаются.
Пример: число 0.5, представленное как {0xF, 0, 0x0000} правильно обработается, и все математические операции с таким числом дадут корректный результат. Проверить можно просто по следующей формуле: 2(EXP-32)*(2^16+MAN).
Также следует учитывать, что на входе преобразователя FIX2FLOAT данные строго целочисленные, но путём совсем небольшого шаманства в VHDL-коде можно фиксированную точку сместить в любое место. В реальном проекте числа меньше 0х1 в формате FP23 я использовал для хранения поворачивающих коэффициентов при реализации БПФ.
Пример: число 0.5, представленное как {0xF, 0, 0x0000} правильно обработается, и все математические операции с таким числом дадут корректный результат. Проверить можно просто по следующей формуле: 2(EXP-32)*(2^16+MAN).
Также следует учитывать, что на входе преобразователя FIX2FLOAT данные строго целочисленные, но путём совсем небольшого шаманства в VHDL-коде можно фиксированную точку сместить в любое место. В реальном проекте числа меньше 0х1 в формате FP23 я использовал для хранения поворачивающих коэффициентов при реализации БПФ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Custom floating point format on FPGA