Честно говоря, я не уверен, что это можно вообще написать на rtl за приемлемое время (скажем полгода). Говорю как RTL программист со стажем. Что до сравнения HLS и ручного кодирования, то уже давно вышла куча статей, где эти подходы сравниваются, и утрверждается, что HLS даже лучше делает. Потому что позволяет вам из одного C кода с помощью прагм получать разные архитектуры, в итоге вы можете выбрать в зависимости от ваших задач. Один из примеров
Не я в курсе, что MAX_PAYLOAD_SIZE может быть до 4096 байт, но на практике никогда не видел, чтобы было больше 256. По спецификации ведь этот параметр должен быть одинаковым для всех устройств в дереве и равен минимальному из поддерживаемых. Вы используете передачи с payload 2048 получается между окончеными устройствами, а не с хостом?
Тоже, кстати, не совсем понятно зачем такой большой payload. Аргументы против
1) Сильно страдает latency. Ведь пакет надо сначала принять, а затем передать дальше. Или у вас cut through pcie switch?
2) Пропускная способность сильно не увеличиться. Ведь уже с payload 256 байт она около 90% от этих 16 ГБ.
PCIe Slave устройство отсылает PCIe Completion Response не на каждую полученную транзакцию, а только на Non-Posted transactions (транзакции чтения). Для Posted транзакции (записи) на уровне TLP траффик идет в одну сторону.
Эти преусловутые 16 ГБ в одну- конечно, даже теоретически недостижимая скорость даже для posted transactions. В первую очередь это связано с тем, что пакет помимо полезных данных для передачи (payload, размером до 256 байт) имеет еще служебный заголовок около 20 байт. Плюс надо учесть DLLP транзакции.
Спустя 5 лет все-таки задам вопрос, вы говорите, что алгоритм однопроходный и может работать, когда изображение поступает последовательно пиксель за пикселем (надо две строчки). А как в этом случае реализовавать операцию слияния двух объектов, если B != 0, С != 0 и B != C.
Image(Image == C) = B?
Мне приходит в голову только опять обойти изображени только теперь снизу вверх, но также справа налево.
Истинные генераторы случайных чисел всегда будут очень медленными. В этой задача требовались 9 чисел каждые 5 нс. Какой генератор белого шума сможет столько давать? Подскажите конкретную микросхему, и в следующей ревизии платы у нас она будет стоять)
Память на феритовых сердечниках я видел своими глазами (и работал на этом компьютере) на военной кафедре в МГУ. Было у нас в учебном прямо классе чудо (работающее!), которое занимало два нормальных шкафа, работало при ЛЮБЫХ уровнях электромагнитных помех и наводило ПВО ракеты цель. Называлось гордо — ЦВК — цифровая вычислительная машина. В учебных целях программировалось с помощью тумблеров в машинных кодах. Требовалось 4 солдата, чтобы вытащить один блок ОЗУ в несколько КБ. У преподавателей была любимая шутка, что если успеем навестись, то летать ничего не будет!
Есть ли в алгоритме обратная связь, т.е. надо ли результат шифрования первого 128 битного блока открытого текста так или иначе подавать на вход шифрования следующего 128 битного блока?
Посмотрел хабы, оставшиеся на Хабре. ОК GPGPU остался, но, господа, прошу не воспринимайте FPGA, только как цифровой конструктор для хобби. На FPGA еще и цифровые сигналы (LTE связь, например) обрабатывают, видео кодируют. Также используют как ускорители вычислений в суперкомпьютерной области.
У меня на подходе статья о реализации алгоритма молекулярной динамики на FPGA с ускорением в 15 раз сравнению с параллельной OpenMP реализацией на 8 ядрах CPU Xeon. Я не хочу публиковать его на гиктаймс! Верните FPGA на Хабр!!!
Господа, а где писать про высокопроизводительные вычисления (HPC), CUDA, OpenCL, FPGA, про параллельное программирование OpenMP и тд? Это не игры и веб разработка, но точно также потрогать нельзя.
Хотелось бы подробней узнать как вы используете Питон. Из статьи это абсолютно не ясно. Создается впечатление, что Питон вы используете для такого же ручного процесса генерации текста Verilog, только при этом исходный код расширяется файлом с template, который тоже надо писать и поддерживать. Пока не ясно, где тут преимущество перед тем, чтобы просто тупо ручками своими написать несколько доп портов сразу на Verilog.
Да, ясно, что сначала надо реализовать алгоритм программно. ПЛИС тут может использоваться для повышения быстродействия, например, чтобы быстро обрабатывать входную картинку (выделять контуры и тд).
Видео воодушевляет!
Очень правильная деятельность, реальное и очень нужное применение электроники. Я сейчас столкнулся с похожей проблемой. Мой будущий студент по программированию хочет реализовать на ПЛИС устройство преобразования двумерной картинки в звуковой сигнал. Из картинки выделяется контур, далее идет обход контура, координата y которого преобразуется в высоту (частоту) звука, а координата х — в соотношение амплитуд правого и левого каналов выходного звука.
Нет у коллег готовых источников информации по этой теме, может примеры уже реализованных устройств? В гугле я еще не смотрел по этой теме, но плиз туда не отправлять)
Рано или поздно я разрожусь серией статей по использованию FPGA. Будут вам и примеры из финансов, high frequency trading (было тут на хабре) — как раз FPGA была на спец сетевой карте, обеспечивающей предобработку данных и уменьшение latency попадания данных в базу данных. И примеры из научной сферы — молекулярное моделирование, биоинформатика, нейросети…
Один из примеров
Тоже, кстати, не совсем понятно зачем такой большой payload. Аргументы против
1) Сильно страдает latency. Ведь пакет надо сначала принять, а затем передать дальше. Или у вас cut through pcie switch?
2) Пропускная способность сильно не увеличиться. Ведь уже с payload 256 байт она около 90% от этих 16 ГБ.
Эти преусловутые 16 ГБ в одну- конечно, даже теоретически недостижимая скорость даже для posted transactions. В первую очередь это связано с тем, что пакет помимо полезных данных для передачи (payload, размером до 256 байт) имеет еще служебный заголовок около 20 байт. Плюс надо учесть DLLP транзакции.
Image(Image == C) = B?
Мне приходит в голову только опять обойти изображени только теперь снизу вверх, но также справа налево.
Там есть книги, лекции, дз. Базовый курс будет серьезно доработан за лето.
У меня на подходе статья о реализации алгоритма молекулярной динамики на FPGA с ускорением в 15 раз сравнению с параллельной OpenMP реализацией на 8 ядрах CPU Xeon. Я не хочу публиковать его на гиктаймс! Верните FPGA на Хабр!!!
На ресурсе про поливалки огурцов?
Видео воодушевляет!
Нет у коллег готовых источников информации по этой теме, может примеры уже реализованных устройств? В гугле я еще не смотрел по этой теме, но плиз туда не отправлять)