Такое ощущение, что фактически ничего не поменяется, если описание регистров с SystemRDL перенести на другой какой-то формат, типа того же V, SV или даже TCL или Python.
В любом случае, описание пошло бы в генератор, который сделал бы уже норм SV блок. И в любом случае само описание регистров как таковое в проект вставить не получится, т.е. это отдельные файлы.
Единственно, если писать тоже самое на SV, должны появиться новые атрибуты и кодовые слова в языке, которых нет для синтеза/верификации, но которые нужны для генерации. Возможно, поэтому так и не сделали)
Немного не понял: есть какая-то уже готовая библиотека/пакет на SV чтоб регистры описывать? Или же вы просто привели пример, как можно описать регистр для регпространства?
Если второй вариант, то помимо прочего вам нужно этот регистр записать и прочитать, декодировав соответствующие команды с системной шины, например AXI4Lite. Чтоб это сделать, вам надо почитать стандарт на шину (если вы работаете с ней впервые), сделать декодер команд, соответствующий документации, сделать выходной мультиплексор и управление им и т.д.
Если же регистры описать на SystemRDL и сгенерировать SV через PeakRDL, то вся логика общения с системной шиной будет реализована автоматически, что очень удобно)
В первую очередь я рассматривал именно схемы распараллеливания. Их отдельно можно применять для любых задач: для БПФ, для фильтрации изображений, для решения задач матфизики и т.д. Сами методы распараллеливания от области применения не меняются.
В данной статье я иллюстрирую использование методов на примере распараллеливания МАС операции, на которой решаем задачу КИХ-фильтрации. Вы правы, все особенности, связанные именно с КИХ-фильтрами сознательно остались за рамками статьи. Наверное даже можно было писать не сколько про КИХ-фильтрацию, сколько про задачу умножения матрицы на вектор (чем КИХ-фильтрация по сути и является с точки зрения последовательности вычислений).
Краткую теоретическую вводную про КИХ-фильтрацию я давал в предыдущей статье, здесь же ограничился только ссылками на нее: https://habr.com/ru/companies/yadro/articles/1078296/. Возможно, следовало бы продублировать этот материал, чтоб текст был более связным.
С терминологией похожая история: "макроконвейер", "мультиконвейер", "вложенный конвейер" , а как это связано с транспонированной и систолической реализациями КИХ-фильтра читателям предлагается установить самостоятельно
Эти понятия как мы видим никак не связаны с транспонированной и систолической реализациями КИХ-фильтра :) Поэтому я и написал дисклеймер. Но, в следующей статье я рассмотрю метод распараллеливания по зависимым операциям и вот там уже будет все знакомое.
Тоже пользуюсь SystemRDL и PeakRDL. Когда только начинал осваивать инструмент было непонятно, как делать демультиплексоры системной шины, чтоб каскадировать мелкие регистровые пространства. Оказалось, что можно addrmap оборачивать в addrmap, и если из этого описания отдельно сгенерировать .sv файлики, как раз и получится демультиплексор.
Пока осталась еще некоторая сложность. Сейчас чтоб подключить сгенерированные .sv файлы в проект, нужно из *_pkg.sv, я вручную собираю путь до регистра и присваиваю его/ему что-то уже в своем модуле. И когда регистровое пространство большое, так делать прям неудобно. Мб есть какой-то способ сгенерировать еще и какой-то шаблон подключения регпространства в мой модуль? Нейронки худо-бедно справляются с этой задачей, но допускает ошибки, все равно приходится лезть в код и все перепроверять.
Пока что у ИИ есть проблемы с генерацией Верилога. Тем более, когда мы готовим про блок сопряжения системной шины с регистрами. Чтоб ИИшка сгенерировала такой же код, какой генерирует PeakRDL, нужно потратить в разы больше времени как по мне. Хотя, может и это уже не за горами)
Как по мне, писать на SystemRDL достаточно просто. А из условных 100 строк регистрового файла генерируются 2 .sv файла размером под 1000+ строк.
Ну и документация сразу готова. И если требования меняются, мы вносим изменения в regfile, генерируем новые .sv файлы и новую доку. Удобно)
В статье я рассматриваю понятие "конвейерная микроархитектура" и это не метод, а именно цифровая схема. На жаргоне мы говорим "построить конвейер" или "конвейер зимовать вычисления", что означает, что нужно использовать соответствующий подход к вычислительному процессу.
Есть ещё одно значение термина "конвейеризация", суть которого вы как раз и раскрывает в комментарии. В иностранной литературе - pipelining. Но тут уже речь о другом: не как реализовать микроархитектура вычислителя в общем, а как реализовать имеющуюся микроархитектуру на низком уровне абстракции, в виде триггеров и дискретной логики.
Например, много разрядный сумматор с цепью переноса можно конвейеризировать, разбив на 2 сумматора поменьше, и выход CO первого сумматора завести через триггер на вход CI второго.
Но в статье речь именно про более высокоуровневую конвейеризацию.
По поводу матриц пикселей тут как раз все норм: если это RGB, то нужно обрабатывать 3 матрицы параллельно. Именно это имел ввиду под трехмерностью: x:y:z, где x и y - ширина и высота, а z - число каналов.
Да, @ren_hoek прав: я имел ввиду, что написанный код представляет именно описание схемы, а не последовательность команд или какой-либо алгоритм. Я не пытаюсь сравнивать, что с кодом происходит далее, так как в этом плане всё сильно отличается)
Такое ощущение, что фактически ничего не поменяется, если описание регистров с SystemRDL перенести на другой какой-то формат, типа того же V, SV или даже TCL или Python.
В любом случае, описание пошло бы в генератор, который сделал бы уже норм SV блок. И в любом случае само описание регистров как таковое в проект вставить не получится, т.е. это отдельные файлы.
Единственно, если писать тоже самое на SV, должны появиться новые атрибуты и кодовые слова в языке, которых нет для синтеза/верификации, но которые нужны для генерации. Возможно, поэтому так и не сделали)
Немного не понял: есть какая-то уже готовая библиотека/пакет на SV чтоб регистры описывать? Или же вы просто привели пример, как можно описать регистр для регпространства?
Если второй вариант, то помимо прочего вам нужно этот регистр записать и прочитать, декодировав соответствующие команды с системной шины, например AXI4Lite. Чтоб это сделать, вам надо почитать стандарт на шину (если вы работаете с ней впервые), сделать декодер команд, соответствующий документации, сделать выходной мультиплексор и управление им и т.д.
Если же регистры описать на SystemRDL и сгенерировать SV через PeakRDL, то вся логика общения с системной шиной будет реализована автоматически, что очень удобно)
Спасибо за интересный комментарий!
В первую очередь я рассматривал именно схемы распараллеливания. Их отдельно можно применять для любых задач: для БПФ, для фильтрации изображений, для решения задач матфизики и т.д. Сами методы распараллеливания от области применения не меняются.
В данной статье я иллюстрирую использование методов на примере распараллеливания МАС операции, на которой решаем задачу КИХ-фильтрации. Вы правы, все особенности, связанные именно с КИХ-фильтрами сознательно остались за рамками статьи. Наверное даже можно было писать не сколько про КИХ-фильтрацию, сколько про задачу умножения матрицы на вектор (чем КИХ-фильтрация по сути и является с точки зрения последовательности вычислений).
Краткую теоретическую вводную про КИХ-фильтрацию я давал в предыдущей статье, здесь же ограничился только ссылками на нее: https://habr.com/ru/companies/yadro/articles/1078296/. Возможно, следовало бы продублировать этот материал, чтоб текст был более связным.
Эти понятия как мы видим никак не связаны с транспонированной и систолической реализациями КИХ-фильтра :) Поэтому я и написал дисклеймер. Но, в следующей статье я рассмотрю метод распараллеливания по зависимым операциям и вот там уже будет все знакомое.
За ссылку на AMD-Xilinx спасибо, сохранил)
Тоже пользуюсь SystemRDL и PeakRDL. Когда только начинал осваивать инструмент было непонятно, как делать демультиплексоры системной шины, чтоб каскадировать мелкие регистровые пространства. Оказалось, что можно addrmap оборачивать в addrmap, и если из этого описания отдельно сгенерировать .sv файлики, как раз и получится демультиплексор.
Пока осталась еще некоторая сложность.
Сейчас чтоб подключить сгенерированные .sv файлы в проект, нужно из *_pkg.sv, я вручную собираю путь до регистра и присваиваю его/ему что-то уже в своем модуле. И когда регистровое пространство большое, так делать прям неудобно. Мб есть какой-то способ сгенерировать еще и какой-то шаблон подключения регпространства в мой модуль? Нейронки худо-бедно справляются с этой задачей, но допускает ошибки, все равно приходится лезть в код и все перепроверять.
Пока что у ИИ есть проблемы с генерацией Верилога. Тем более, когда мы готовим про блок сопряжения системной шины с регистрами. Чтоб ИИшка сгенерировала такой же код, какой генерирует PeakRDL, нужно потратить в разы больше времени как по мне. Хотя, может и это уже не за горами)
Как по мне, писать на SystemRDL достаточно просто. А из условных 100 строк регистрового файла генерируются 2 .sv файла размером под 1000+ строк.
Ну и документация сразу готова. И если требования меняются, мы вносим изменения в regfile, генерируем новые .sv файлы и новую доку. Удобно)
Доброго утра! В этом деле попрошу помощи коллег, они напишут вам в личные сообщения.
В статье я рассматриваю понятие "конвейерная микроархитектура" и это не метод, а именно цифровая схема. На жаргоне мы говорим "построить конвейер" или "конвейер зимовать вычисления", что означает, что нужно использовать соответствующий подход к вычислительному процессу.
Есть ещё одно значение термина "конвейеризация", суть которого вы как раз и раскрывает в комментарии. В иностранной литературе - pipelining. Но тут уже речь о другом: не как реализовать микроархитектура вычислителя в общем, а как реализовать имеющуюся микроархитектуру на низком уровне абстракции, в виде триггеров и дискретной логики.
Например, много разрядный сумматор с цепью переноса можно конвейеризировать, разбив на 2 сумматора поменьше, и выход CO первого сумматора завести через триггер на вход CI второго.
Но в статье речь именно про более высокоуровневую конвейеризацию.
По поводу матриц пикселей тут как раз все норм: если это RGB, то нужно обрабатывать 3 матрицы параллельно. Именно это имел ввиду под трехмерностью: x:y:z, где x и y - ширина и высота, а z - число каналов.
По поводу GPU: претензия понятна, тут я очень сильно упрощаю. Однако все же MAC операций в GPU насыпано в разы больше, чем любых других арифметико-логических. Да и тензорные блоки - это все те же сумматоры с умножителями, используемые для умножения матриц: https://images.nvidia.com/aem-dam/en-zz/Solutions/data-center/nvidia-ampere-architecture-whitepaper.pdf
Спасибо за высокую оценку)
Да, @ren_hoek прав: я имел ввиду, что написанный код представляет именно описание схемы, а не последовательность команд или какой-либо алгоритм. Я не пытаюсь сравнивать, что с кодом происходит далее, так как в этом плане всё сильно отличается)