Мы рассматривали такой вариант, но пока что отказались от него по нескольким причинам: 1) Мы по-большей части системные программисты, поэтому нам бы понадобилась помощь соседнего отдела в создании такого решения. Хотелось иметь собственную небольшую среду, в которой можно проводить не полную формальную верификацию блоков (потому что блоки инструментальные, а не продуктовые), а скорее просто модульное тестирование и отладку изолированного функционала. 2) Разработка универсального тестбенча в нашем случае не была бы бесплатной, т.к. конфигурации блоков очень разняться по набору интерфейсов, названиям и т.д. Со стороны UVM также понадобилось бы делать специальные секвенсеры и драйверы. Поэтому в конечном итоге, по трудозатратам, то на то и вышло бы примерно. Зато мы теперь имеем кучу описанных тестов, которые очень легко разрабатываются любым членом команды и которым не нужна DPI обвязка для использования программных или системных функций.
Здесь, наверное, в статье стоило четче провести границу - мы не считаем наше решение универсальной или более практичной заменой существующим стекам. Попробую на все 3 вопроса ответить одновременно) Для нас C++ это не просто язык описания тестбенча, а скорее общая среда для выполнения всей ко-симуляции. У нас существуют и UVM-решения, и DPI-альтернативы, но задача была не в написании своего фреймворка для верификации, а в создании моста между существующей инфраструктурой и модульными тестами под некоторые блоки. Именно поэтому мы стараемся держать эту обвязку из Verilator максимально тонкой, а все сложные сценарии утаскиваем в другие среды выполнения. Сложность разработки такого окружения окупается из-за того, что она может переварить сотни различных конфигураций наших блоков, при этом не требует особой адаптации от других компонентов.
Согласен, в процессе выполнения возникало множество побочных нюансов, про которые можно было бы дополнительно рассказать. Особым камнем преткновения стала скорость передачи данных в ускоритель, которая оказалась значительно ниже, чем пропускная способность самого ускорителя. Все подобные моменты я решил не указывать в статье, потому что хотелось, чтобы она поверхностно передавала полученный опыт и носила чисто ознакомительный характер.
Если вам показалась интересной данная статья и хотелось бы увидеть более подробный материал - велком в подписки моего блога и блога компании YADRO! :) Планируются ещё статьи, как за моим авторством, так и за авторством моих коллег.
Спасибо за замечания, обязательно приму к сведению при дальнейшей доработке кода.
Можете пояснить в чем заключается UB в строке с циклами?
transform же сознательно не использовал для более наглядного потактового контроля за каждой итерацией вычислений. В будущем данная модель будет переносится на аппаратуру и будет неудобно выполнять отладку, если слишком инкапсулировать логику подсчета в недра стандартных библиотек.
Не подумал, что это может оказаться интересным в рамках такой довольно игрушечной задачи, поэтому решил не вставлять.
Вообще, обучение и валидацию проводил на двух наборах по 60 картинок, поэтому временные задержки больше вызваны созданием объектов и всякими такими довольно техническими вещами, поэтому относиться к ним надо с долей скептицизма.
Время обучения на 50 эпохах 0.1 секунда Время валидации 0.01 секунда
Ошибка у меня возникла только в случае, когда картинка валидации вида: круг с двумя зашумленными углами (или он же квадрат с двумя отсутствующими углами), все остальные картинки корректно определяются, то есть процент ошибок где-то 0-2%
Не смотрел, была необходимость написать модель на чистых плюсах, так как в будущем будут дополнительные задания по проектированию аппаратного ускорителя. В любом случае, спасибо за наводку, ознакомлюсь)
Information
Rating
366-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Мы рассматривали такой вариант, но пока что отказались от него по нескольким причинам:
1) Мы по-большей части системные программисты, поэтому нам бы понадобилась помощь соседнего отдела в создании такого решения. Хотелось иметь собственную небольшую среду, в которой можно проводить не полную формальную верификацию блоков (потому что блоки инструментальные, а не продуктовые), а скорее просто модульное тестирование и отладку изолированного функционала.
2) Разработка универсального тестбенча в нашем случае не была бы бесплатной, т.к. конфигурации блоков очень разняться по набору интерфейсов, названиям и т.д. Со стороны UVM также понадобилось бы делать специальные секвенсеры и драйверы.
Поэтому в конечном итоге, по трудозатратам, то на то и вышло бы примерно. Зато мы теперь имеем кучу описанных тестов, которые очень легко разрабатываются любым членом команды и которым не нужна DPI обвязка для использования программных или системных функций.
Здесь, наверное, в статье стоило четче провести границу - мы не считаем наше решение универсальной или более практичной заменой существующим стекам.
Попробую на все 3 вопроса ответить одновременно)
Для нас C++ это не просто язык описания тестбенча, а скорее общая среда для выполнения всей ко-симуляции. У нас существуют и UVM-решения, и DPI-альтернативы, но задача была не в написании своего фреймворка для верификации, а в создании моста между существующей инфраструктурой и модульными тестами под некоторые блоки. Именно поэтому мы стараемся держать эту обвязку из Verilator максимально тонкой, а все сложные сценарии утаскиваем в другие среды выполнения. Сложность разработки такого окружения окупается из-за того, что она может переварить сотни различных конфигураций наших блоков, при этом не требует особой адаптации от других компонентов.
Согласен, в процессе выполнения возникало множество побочных нюансов, про которые можно было бы дополнительно рассказать. Особым камнем преткновения стала скорость передачи данных в ускоритель, которая оказалась значительно ниже, чем пропускная способность самого ускорителя. Все подобные моменты я решил не указывать в статье, потому что хотелось, чтобы она поверхностно передавала полученный опыт и носила чисто ознакомительный характер.
Если вам показалась интересной данная статья и хотелось бы увидеть более подробный материал - велком в подписки моего блога и блога компании YADRO! :) Планируются ещё статьи, как за моим авторством, так и за авторством моих коллег.
ИТМО, Компьютерные Системы и Технологии, эта задача - часть большой задачи по реализации аппаратного ускорителя нейронных сетей.
Спасибо за замечания, обязательно приму к сведению при дальнейшей доработке кода.
Можете пояснить в чем заключается UB в строке с циклами?
transform же сознательно не использовал для более наглядного потактового контроля за каждой итерацией вычислений. В будущем данная модель будет переносится на аппаратуру и будет неудобно выполнять отладку, если слишком инкапсулировать логику подсчета в недра стандартных библиотек.
Не подумал, что это может оказаться интересным в рамках такой довольно игрушечной задачи, поэтому решил не вставлять.
Вообще, обучение и валидацию проводил на двух наборах по 60 картинок, поэтому временные задержки больше вызваны созданием объектов и всякими такими довольно техническими вещами, поэтому относиться к ним надо с долей скептицизма.
Время обучения на 50 эпохах 0.1 секунда
Время валидации 0.01 секунда
Ошибка у меня возникла только в случае, когда картинка валидации вида: круг с двумя зашумленными углами (или он же квадрат с двумя отсутствующими углами), все остальные картинки корректно определяются, то есть процент ошибок где-то 0-2%
Не смотрел, была необходимость написать модель на чистых плюсах, так как в будущем будут дополнительные задания по проектированию аппаратного ускорителя. В любом случае, спасибо за наводку, ознакомлюсь)