Если не затруднит, не могли бы Вы написать более читаемый вариант этого блока.
Я понимаю, как это можно описать при помощи assign, но тот вариант, который приходит на ум мне, не кажется более читаемым.
Может быть, Вы имеете в виду что-то другое.
В каком-то конкретном случае — да.
В общем случае — зависит от количества вычислительных блоков, которые удастся реализовать в ПЛИС; частоте, на которой это всё заработает; емкости ПЛИС; частоте процессора; количеству ядер; стоимости компонентов и т.д.
Не уверен, что можно реализовать эту задачу на FPGA так, чтобы по соотношению производительность/стоимость вышло выгоднее, чем на CPU. Но допускаю это.
Почти уверен, что на FPGA можно сделать реализацию с большей производительностью, чем на CPU.
Точно уверен в том, что реализация на FPGA будет интересней :)
По поводу описанного проекта — совсем очевидное замечание, но всё же напишу.
Если есть задача увеличить количество клеток, то не обязательно использовать ПЛИС большей емкости.
Можно просто уменьшить количество параллельных вычислений.
В крайнем случае можно хранить всё значения в блочной памяти и использовать только один вычислительный блок, который будет последовательно вычислять все новые значения для всех клеток.
Естественно, делать все вычисления за такт станет не реально, но я не думаю, что для Вашего проекта цель — это 100 млн. обновлений в секунду.
Дальнейшее развитие мысли — обратное увеличение параллельности, с использованием N вычислительных блоков, где 1 < N << количества клеток.
Хочу пояснить, что доступ к памяти через отображение /dev/mem выбран для простоты примера.
В реальной жизни такая практика достаточно опасна и чревата ошибками.
Правильнее использовать техники типа Userspace I/O:
Что разработчики вкладывали в название платы, точно сказать не могу — тут я только пользователь :)
Думаю, что это обозначает возможность оценить все плюсы/минусы работы с SoC такого формата.
По поводу отладки — nerudo ниже указал список того, что есть на плате.
Хочу добавить, что в таких SoC достаточно развитая система дебага и трасировки.
Кроме обычно «защелкивания» внутренностей FPGA при помощи SignalTap, в SoC одна из фич — Cross-trigger,
когда события/breakpoint'ы одного компонента могут использоваться для трассировки другого.
Сам я с этим на практике пока не работал. Но думаю, что поработаю, когда буду «разгонять» интерфейс.
Соответственно, в следующей статье упомяну.
Я понимаю, как это можно описать при помощи assign, но тот вариант, который приходит на ум мне, не кажется более читаемым.
Может быть, Вы имеете в виду что-то другое.
Не поделитесь своей? :)
В общем случае — зависит от количества вычислительных блоков, которые удастся реализовать в ПЛИС; частоте, на которой это всё заработает; емкости ПЛИС; частоте процессора; количеству ядер; стоимости компонентов и т.д.
Не уверен, что можно реализовать эту задачу на FPGA так, чтобы по соотношению производительность/стоимость вышло выгоднее, чем на CPU. Но допускаю это.
Почти уверен, что на FPGA можно сделать реализацию с большей производительностью, чем на CPU.
Точно уверен в том, что реализация на FPGA будет интересней :)
P.S. Пора заводить хаб, посвященный FPGA :)
Если есть задача увеличить количество клеток, то не обязательно использовать ПЛИС большей емкости.
Можно просто уменьшить количество параллельных вычислений.
В крайнем случае можно хранить всё значения в блочной памяти и использовать только один вычислительный блок, который будет последовательно вычислять все новые значения для всех клеток.
Естественно, делать все вычисления за такт станет не реально, но я не думаю, что для Вашего проекта цель — это 100 млн. обновлений в секунду.
Дальнейшее развитие мысли — обратное увеличение параллельности, с использованием N вычислительных блоков, где 1 < N << количества клеток.
Просто так исторически сложилось, что мы «сидим» на Altera, поэтому мне в руки попала эта платка.
В реальной жизни такая практика достаточно опасна и чревата ошибками.
Правильнее использовать техники типа Userspace I/O:
Спасибо nymitr за замечание.
Борода периодически отрастает, я её периодически сбриваю ))
Думаю, что это обозначает возможность оценить все плюсы/минусы работы с SoC такого формата.
По поводу отладки — nerudo ниже указал список того, что есть на плате.
Хочу добавить, что в таких SoC достаточно развитая система дебага и трасировки.
Кроме обычно «защелкивания» внутренностей FPGA при помощи SignalTap, в SoC одна из фич — Cross-trigger,
когда события/breakpoint'ы одного компонента могут использоваться для трассировки другого.
Сам я с этим на практике пока не работал. Но думаю, что поработаю, когда буду «разгонять» интерфейс.
Соответственно, в следующей статье упомяну.