Forwarded from позитивслэк (Bogdan)
1800-2023 - IEEE Standard for SystemVerilog
SV-2023 in da house! На этой неделе на DVCon 2024 презентовали новый стандарт.
Дейв отписался в блоге Siemens, что он свободно доступен через IEEE Get Program. Однако, нужна регистрация чтобы его скачать. Товарищи, может кто-то сможет помочь?
#system_verilog
@positiveslack
SV-2023 in da house! На этой неделе на DVCon 2024 презентовали новый стандарт.
Дейв отписался в блоге Siemens, что он свободно доступен через IEEE Get Program. Однако, нужна регистрация чтобы его скачать. Товарищи, может кто-то сможет помочь?
#system_verilog
@positiveslack
IEEE-1800-2023.pdf
9 MB
Условно-бесплатная копия стандарта SystemVerilog 2023. Без палева вотермарков.
TANG_MEGA-138K-Pro_4072_Schematics.pdf
1.9 MB
Пост для опенсорс-скептиков. В приложении пример использования опенсорса (KiCAD) в коммерческой разработке. Конечно, устройство несложное, но тем не менеее.
mandelbrot.gif
1.8 MB
Ещё одна интересная реализация RISC-V. На этот раз разработчик задался целью сделать среднее между небезызвестным SERV и ядром обычной параллельной природы. Степень сериализации выбирается параметром, что даёт возможность гибко настраивать отношение площади к производительности.
На гифке нагладное сравнение скорости работы ядра при разных значениях параметра.
Разница в ресурсах между самым быстрым и самым медленным вариантом примерно два раза.
На гифке нагладное сравнение скорости работы ядра при разных значениях параметра.
Разница в ресурсах между самым быстрым и самым медленным вариантом примерно два раза.
Forwarded from Записки CPU designer'a (Николай)
ESP the open-source SoC platform
ESP - это открытая платформа для проектирования и создания гетерогенных System on a chip c возможностью прототипирования системы на FPGA. В будущем планируется также поддержка ASIC design flow.
ESP предоставляет гибкую tile-based архитектуру, построенную на multi-plane network-on-chip
Обзор проекта представлен авторами в статье Agile SoC Development with Open ESP.
В проекте вы найдете знакомые многим RISC-V энтузиастам названия открытых процессорных IP: Ariane (CVA6), ibex, LEON3 (на базе SPARC V8 32-bits ISA). Но самые внимательные увидят на изображении floorplan'а чипа в заголовке поста NVDLA —opensource Deep Learning Accelerator от Nvidia.
Как мы видим, ESP может служить платформой для интеграции сторонних IP-блоков, который может быть размещен на любом из тайлов ESP платформы.
Судя по домашней странице проекта, вся система спроектирована при помощи языка конструирования аппаратуры Chisel и High-Level Synthesis инструментов.
Исходники на HDL, доступные в репозитории проекта, либо относятся к сторонним IP-ядрам/ускорителям, либо созданы с использованием инструментов SoCGen и SocketGen.
Ссылки на проект ESP:
1) github репозиторий
2) сайт проекта
3) документация и туториалы
4) коллекция научных публикаций по тематике проекта ESP
p.s. если кто-то поймет что за Night Vision в правом нижнем углу флурплана чипа - отпишите в комментарии🤔
ESP - это открытая платформа для проектирования и создания гетерогенных System on a chip c возможностью прототипирования системы на FPGA. В будущем планируется также поддержка ASIC design flow.
ESP предоставляет гибкую tile-based архитектуру, построенную на multi-plane network-on-chip
Обзор проекта представлен авторами в статье Agile SoC Development with Open ESP.
В проекте вы найдете знакомые многим RISC-V энтузиастам названия открытых процессорных IP: Ariane (CVA6), ibex, LEON3 (на базе SPARC V8 32-bits ISA). Но самые внимательные увидят на изображении floorplan'а чипа в заголовке поста NVDLA —opensource Deep Learning Accelerator от Nvidia.
Как мы видим, ESP может служить платформой для интеграции сторонних IP-блоков, который может быть размещен на любом из тайлов ESP платформы.
Судя по домашней странице проекта, вся система спроектирована при помощи языка конструирования аппаратуры Chisel и High-Level Synthesis инструментов.
Исходники на HDL, доступные в репозитории проекта, либо относятся к сторонним IP-ядрам/ускорителям, либо созданы с использованием инструментов SoCGen и SocketGen.
Ссылки на проект ESP:
1) github репозиторий
2) сайт проекта
3) документация и туториалы
4) коллекция научных публикаций по тематике проекта ESP
p.s. если кто-то поймет что за Night Vision в правом нижнем углу флурплана чипа - отпишите в комментарии
Please open Telegram to view this post
VIEW IN TELEGRAM
Не стесняемся, заказываем 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from позитивслэк (Bogdan)
Цифровой синтез: RISC-V
Неожиданно затесался в приложение книги "Цифровой синтез: RISC-V".
Штош, теперь, хочешь не хочешь, надо брать. Спасибо Вождю!
P.s. кстати топовые каналы, рекомендую подписаться =)
#book
@postivelsack
Неожиданно затесался в приложение книги "Цифровой синтез: RISC-V".
Штош, теперь, хочешь не хочешь, надо брать. Спасибо Вождю!
P.s. кстати топовые каналы, рекомендую подписаться =)
#book
@postivelsack
Возможно это глупый вопрос, но я рискну. Представьте, что у вас есть слейв, принимающий 32 бита по AXIS-подобной шине (хендшейк valid/ready) и выполняющий обработку данных побайтно. Возможны два варианта действий:
1. В режиме ожидания вы держите ready в единице. Как только приходит valid, защелкиваете все 32 бита в регистр, снимаете ready и начитаете побайтную обработку. По окончании поднимаете ready.
2. В режиме ожидания держите ready в нуле. По приходу valid начитаете побайтную обработку, снимая байты непоследственно с шины. По окончании дергаете ready.
В общем, оба варианта приемлемы, т.к. в спеке на AXI не требуется, чтобы ready был активен до прихода valid, а однажды выставленный valid не может быть снят до прихода ready. С другой стороны, второй вариант может порушить времянки, если данные от мастера формируются через комбинационные цепи. И возможны проблемы с арбитражем, если арбитр полагается на ready.
Что вы думаете по этому поводу? В комментах создам опрос, заходите.
1. В режиме ожидания вы держите ready в единице. Как только приходит valid, защелкиваете все 32 бита в регистр, снимаете ready и начитаете побайтную обработку. По окончании поднимаете ready.
2. В режиме ожидания держите ready в нуле. По приходу valid начитаете побайтную обработку, снимая байты непоследственно с шины. По окончании дергаете ready.
В общем, оба варианта приемлемы, т.к. в спеке на AXI не требуется, чтобы ready был активен до прихода valid, а однажды выставленный valid не может быть снят до прихода ready. С другой стороны, второй вариант может порушить времянки, если данные от мастера формируются через комбинационные цепи. И возможны проблемы с арбитражем, если арбитр полагается на ready.
Что вы думаете по этому поводу? В комментах создам опрос, заходите.
Столкнулся с очередным багом Верилятора: функция
Запостил issue.
PS: Ни слова про опенсорс. Уверен, что ошибку быстро исправят ;)
Дополнение. Такое поведение наблюдается только при seed == 0. Посмотрел исходники, там есть тест на равенство
$random
(и $urandom
тоже) с одинаковым начальным сидом генерит разные последовательности. Этого конечно не должно быть, и другие симы это подтверждают - проверил на Икарусе и Квесте. Однако, семейство функций $dist_*
работает правильно. Так что если вам понадобится в одной программе генерить одинаковые случайные последовательности, пользуйтесь $dist_uniform
вместо $random
/$urandom
.Запостил issue.
PS: Ни слова про опенсорс. Уверен, что ошибку быстро исправят ;)
Дополнение. Такое поведение наблюдается только при seed == 0. Посмотрел исходники, там есть тест на равенство
$random
с одинаковым seed, но seed устанавливается в 10.GitHub
$random sequences with the same seed do not equal · Issue #5074 · verilator/verilator
Generating random numbers using $random and $urandom with the same seed produces different sequences. At the same time, $dist_* functions with the same seed produces identical numbers. Test code: `...
Мне сказали, чтобы я шел в жопу со своими issue 🙂
> Verilator follows C's seeding conventions where seed 0 means "pick a new seed". For compatibility reasons we are unlikely to change this. Don't use zero.
> Verilator follows C's seeding conventions where seed 0 means "pick a new seed". For compatibility reasons we are unlikely to change this. Don't use zero.
Please open Telegram to view this post
VIEW IN TELEGRAM
Вышел релиз 0.0.12 тула для конвертации системверилога в верилог - sv2v. В новой версии исправили множество ошибок и добавили некоторые полезные улучшения. Например,
Напомню, что проект sv2v изначально разрабатывался с целью обеспечить поддержку SV в синтезаторе Yosys. В связи с этим, преобразование несинтезируемого SV в нём на зачаточном уровне.
always_comb
и always_latch
, которые преобразуются в обычный always, теперь выполняются в нулевом времени, как этого требует стандарт. Список наиболее значимых изменений найдёте по ссылке и в списке закрытых issue.Напомню, что проект sv2v изначально разрабатывался с целью обеспечить поддержку SV в синтезаторе Yosys. В связи с этим, преобразование несинтезируемого SV в нём на зачаточном уровне.
GitHub
Release v0.0.12 · zachjs/sv2v
Breaking Changes
Removed deprecated CLI flags -d/-e/-i, which have been aliased to -D/-E/-I with a warning since late 2019
New Features
unique, unique0, and priority case statements now produce ...
Removed deprecated CLI flags -d/-e/-i, which have been aliased to -D/-E/-I with a warning since late 2019
New Features
unique, unique0, and priority case statements now produce ...
Doka запостил ссылку на список проектов на гитхабе, отсортированных по популярности. Список давно не обновлялся и не включал в себя SystemVerilog, по этому я сделал форк и обновил данные. Оставил только Verilog и VHDL, и добавил SystemVerilog и Bluespec. К сожалению, в списке поиска гитхаба больше нет HDL языков 🤷♀️
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - punzik/arl-hdl: lists of most popular repositories for most favoured programming languages (according to StackOverflow)
lists of most popular repositories for most favoured programming languages (according to StackOverflow) - punzik/arl-hdl
Вышел второй номер журнала FPGA-Systems Magazine :: FSM :: № BETA (state_1)! Много интересного. От меня тоже есть небольшая заметка про быстрое вычисление медианы. Качайте, читайте. Вопросы и комменты можно оставлять в специальной группе.
FPGA-Systems.ru - Сообщество FPGA разработчиков
FPGA-Systems Magazine - первый журнал о программируемой логике
First magazine about programmable logic
Внезапно узнал, что вот уже четыре месяца товарищ Martin Povišer пилит фронтенд для yosys на базе парсера slang. Если затея выгорит, то это будет самая полная поддержка SV в yosys. И не только в yosys, наверное.
Товарищ добавил тесты своего фронтенда в CHIPS Alliance sv-tests dashboard, и хотя ещё много нужно сделать, уже есть на что посмотреть. Будем следить.
Товарищ добавил тесты своего фронтенда в CHIPS Alliance sv-tests dashboard, и хотя ещё много нужно сделать, уже есть на что посмотреть. Будем следить.
GitHub
GitHub - povik/yosys-slang: SystemVerilog frontend for Yosys
SystemVerilog frontend for Yosys. Contribute to povik/yosys-slang development by creating an account on GitHub.
Коллеги, вы не сталкивались с торможением GTKWave? Версия, которая на GTK3, отжирает целое ядро процессора просто показывая временную диаграмму. Если поставить курсор, то видно как он нервно моргает, как будто вся диаграмма постоянно перерисовывается. На версии GTK2 такого поведения не наблюдал, там всё летает.
Форенчич два года назад завёл issue на похожую тему, но обсуждение пошло куда-то не туда. А проблема осталась. И судя по тому, что больше таких репортов нет, проблема не сильно распространенная. Возможно даже дело не в программе, а в видеодровах, как однажды было с KiCAD-ом.
В общем, подожду выхода GTKWave4 (а там обещают полностью переработанный рендер) на версии с GTK2.
Форенчич два года назад завёл issue на похожую тему, но обсуждение пошло куда-то не туда. А проблема осталась. И судя по тому, что больше таких репортов нет, проблема не сильно распространенная. Возможно даже дело не в программе, а в видеодровах, как однажды было с KiCAD-ом.
В общем, подожду выхода GTKWave4 (а там обещают полностью переработанный рендер) на версии с GTK2.
GitHub
Performance problems in 3.3.113/gtk3 · Issue #173 · gtkwave/gtkwave
I recently upgraded from 3.3.111 to 3.3.113 on Arch Linux and I am running in to some seriously bad performance problems in gtkwave. It almost seems to be effectively hanging when fully zoomed out ...
Вы наверное знаете, что в стандарте верилога есть ключевое слово
Я нашел документ, в котором сказано, что в
macromodule
, которое ничем не отличается от module
, за исключением того, что "An implementation may choose to treat module definitions beginning with the macromodule keyword differently". Интересно, откуда растут ноги у этого macromodule
и используется ли где нибудь возможность интерпретировать его отлично от module
?Я нашел документ, в котором сказано, что в
macromodule
можно описывать только wire
и операции с ними. Никаких переменных/регистров и процедурных присваиваний, только assign
. Интересно, откуда эта информация, если в стандарте об этом ни слова?По мотивам вот этого: https://www.group-telegram.com/vlsihub/598
Нашел в юникоде несколько подходящих символов для подобного документирования вейвформ. Там есть ещё варианты, но эти два мне как-то понравились больше всех. Первый более красивый и наглядный, но надо "рисовать" через строку, т.к. иначе соседние вейвы сливаются. Второй - можно в каждой строке. Несомненный плюс обоих - для одного сигнала нужна одна строка, а не так, как в ASCII: ноль - нижнее подчеркивание, единица - нижнее подчеркивание строкой выше. Ну и несомненный минус - передать через телетайп такое будет затруднительно🤪
Вот эти символы:
Возможно в вашем любимом шрифте они будут смотреться криво. Увы. В Йосевке смотрится прекрасно😍
Нашел в юникоде несколько подходящих символов для подобного документирования вейвформ. Там есть ещё варианты, но эти два мне как-то понравились больше всех. Первый более красивый и наглядный, но надо "рисовать" через строку, т.к. иначе соседние вейвы сливаются. Второй - можно в каждой строке. Несомненный плюс обоих - для одного сигнала нужна одна строка, а не так, как в ASCII: ноль - нижнее подчеркивание, единица - нижнее подчеркивание строкой выше. Ну и несомненный минус - передать через телетайп такое будет затруднительно
Вот эти символы:
🭼 🭽 🭾 🭿 🮀 ▔ ▁ ╳
⎽ ▄
Возможно в вашем любимом шрифте они будут смотреться криво. Увы. В Йосевке смотрится прекрасно
Please open Telegram to view this post
VIEW IN TELEGRAM