1. Пошли бы вы на лекции?

[Sefo 0]

Но uvm почти не применим для верификации блоков цос. Зачем он в вашем курсе?

 

Вообще, UVM полезная штука и много где приминим. Если рассматривать мелкие модули БПФ, то там может и нет смысла применять UVM, но если брать модуль БПФ целиком, то UVM вполне пригоден.

Я считаю, что современный инженер, все же, должен иметь представление о UVM и хотя бы раз его опробовать. Я не предполагаю углубляться в UVM, но просто продемонстрировать его, чтобы слушатели получили о UVM представление.

 

А может быть в онлайн формате? У Питерцев и так курсы Эфо есть, че все им одним то? :)

 

Я с удовольствием, но я не представляю как это организовать технически. Мне нужно видеть аудиторию и иметь обратную связь непосредственно во время лекции.

Если кто-то сможет взять на себя решение этого вопроса я буду ему очень благодарен.

 

 

Как мне думается начинать надо не с теоретических основ преобразования Фурье, а с необходимого математического аппарата, без которого этого Фурье не освоить. А так получается курс предназначен для подготовленного слушателя.

 

Математический аппарат входит в то, что я назвал теоретические основы преобразования Фурье. :)

 

 

Где планируете проводить лекции ?

 

Можно ли будет делать видеозапись лекции для личного пользования ?

 

Я планирую поговорить с ЛЭТИ и Политехом. Может там выделят аудиторию. Видеозапись делать можно.

 

А планируется делать запись лекции?

 

Да.

[des00 25]

Вообще, UVM полезная штука и много где приминим. Если рассматривать мелкие модули БПФ, то там может и нет смысла применять UVM, но если брать модуль БПФ целиком, то UVM вполне пригоден.

Я считаю, что современный инженер, все же, должен иметь представление о UVM и хотя бы раз его опробовать. Я не предполагаю углубляться в UVM, но просто продемонстрировать его, чтобы слушатели получили о UVM представление.

В контексте БПФ, можете в двух словах пояснить куда там UVM прикладывать? Т.е. вы сделаете драйвера, агенты, добавите рандомизированные транзакции, все это завернете в ферму, добавите поддержку фабрики и т.д. И все для того что бы открыть файл, загрузить данные в движок и сравнить их на выходе? ИМХО вся эта кухня только отвадит от использования UVM. Отладка банального свича будет более наглядна.

[Sefo 0]

В контексте БПФ, можете в двух словах пояснить куда там UVM прикладывать? Т.е. вы сделаете драйвера, агенты, добавите рандомизированные транзакции, все это завернете в ферму, добавите поддержку фабрики и т.д. И все для того что бы открыть файл, загрузить данные в движок и сравнить их на выходе? ИМХО вся эта кухня только отвадит от использования UVM. Отладка банального свича будет более наглядна.

 

Вокруг модуля БПФ. Данные в модуль надо через какой-то интерфейс загрузить, а результаты выгрузить. Для БПФ данные не обязательно читать из файла - их легко сгенирировать на лету. Даже нет необходимости выполнять проверочное БПФ - можно сгенерировать вход с заранее известным спектром.

 

UVM всегда имеет одинаковую инфраструктуру вокруг тестируемого модуля и в этом смысле нет разницы что именно будет тестируемым модулем: БПФ, коммутатор или что-то еще. UVM как пиво - первый раз всегда не нравится :) Сначала кажется, что все очень сложно и перегружено, но потом мнение меняется. Что именно берется в качестве тестируемого модуля, на мой взгляд, ситуацию не меняет и первичное "отторжение" UVM неизбежно.

 

Впрочем, я не настаиваю. Если знакомство с UVM никому не интересно - вычеркну.

[des00 25]

Вокруг модуля БПФ. Данные в модуль надо через какой-то интерфейс загрузить, а результаты выгрузить.

Т.е. вместо двух тасков set_data/get_data, вы предлагаете родить систему :

transaction -> in_driver(+monitor)  -> in_agent  (+ analysis_port)  -> in_sequencer  -> vsequencer -> enviroment -> test 
                                                                    -> scoreboard 
               out_driver(+monitor) -> out_agent (+ analysis_port)  -> out_sequencer ->

это сильно.

 

UVM всегда имеет одинаковую инфраструктуру вокруг тестируемого модуля и в этом смысле нет разницы что именно будет тестируемым модулем: БПФ, коммутатор или что-то еще. UVM как пиво - первый раз всегда не нравится :) Сначала кажется, что все очень сложно и перегружено, но потом мнение меняется. Что именно берется в качестве тестируемого модуля, на мой взгляд, ситуацию не меняет и первичное "отторжение" UVM неизбежно.

ИМХО для БПФ это как микроскопом гвозди забивать. Либо под UVM вы подразумеваете UVM классы, без использования методологии UVM.

 

[Sefo 0]

ИМХО для БПФ это как микроскопом гвозди забивать. Либо под UVM вы подразумеваете UVM классы, без использования методологии UVM.

 

Давайте заменим БПФ на банальный коммутатор, на банальный UART или I2C или что-то еще. Что меняется? Объясните, пожалуйста, за счет чего происходит превращение микроскопа в молоток?

[des00 25]

Давайте заменим БПФ на банальный коммутатор, на банальный UART или I2C или что-то еще. Что меняется? Объясните, пожалуйста, за счет чего происходит превращение микроскопа в молоток?

Дело не в том что на что заменить, дело в цели. А цель заключается в разработанном плане верификации. Если план верификации подразумевает работу со сценариями моделирования, при этом эти сценарии представляют собой что-то сложнее чем "плюнуть а, дождаться результата, проверить с b", то методология UVM в помощь. Т.к. она позволяет простыми способами описывать различные сценарии, в том числе нелинейные, определяемые случайными последовательностями. Именно под это она разрабатывалась и была реализована.

 

Проверка БПФ - это проверка математики. Сценарий тут один : убедиться что "а + б" эквивалентно "а + б". Вот если вы включите это фурье, в многоканальный сопроцессор, с очередями обработки запросов, с flow control, приоритетами, плавающей частотой следования и т.д., то да, это задача хорошо решается с помощью UVM, но это не имеет никакого отношения к тому, что бы в тесте математического ядра дрыгать его портами через тучу классов, ферму и фабрику для банальной передачи и получения запроса.

 

ИМХО вместо UVM лучше просто показать цосникам-посетителям лекции как можно использовать очереди/динамические массивы/ассоциативные массивы/семафоры/мейлбоксы/т.д. для реализации верификации и заглушек модулей при разработке.

 

[Sefo 0]

ИМХО вместо UVM лучше просто показать цосникам-посетителям лекции как можно использовать очереди/динамические массивы/ассоциативные массивы/семафоры/мейлбоксы/т.д. для реализации верификации и заглушек модулей при разработке.

 

Я не даром написал "...и, в частности, UVM". Раздел верификации я начну с простых вещей. UVM на третье - кому не надо/не интересно может пропустить. Если вообще никому не надо, то не стану разбирать вовсе.

 

Дело не в том что на что заменить, дело в цели. А цель заключается в разработанном плане верификации. Если план верификации подразумевает работу со сценариями моделирования, при этом эти сценарии представляют собой что-то сложнее чем "плюнуть а, дождаться результата, проверить с b", то методология UVM в помощь.

 

Верно подмечено - дело в цели. Цель - исключительно познакомить слушателей с UVM и разобраться с основными элементами инфраструктуры. Не более того. Именно для этой цели, я считаю, самым подходящим является самый простой сценарий. Как Вы написали "плюнуть а, дождаться результата, проверить с b". Для начала (а курс для начинающих) достаточно, как в известном анекдоте, просто знать как расшифровывается аббревиатура UVM, какого цвета учебник, ну и может быть понимать чем sequence отличается от sequencer :).

Еще один важный, на мой взгляд, нюанс. К моменту верификации слушатели уже будут знать БПФ вдоль и поперек и это позволит сосредоточиться целиком на особенностях верификации. Если взять что-то другое то необходимо будет сначала разобраться с тем как это работает, а потом еще по ходу отвлекаться на то, чтобы понять (или объяснить) почему в этой точке у этого модуля вот именно такие диаграммы.

 

Проверка БПФ - это проверка математики. Сценарий тут один : убедиться что "а + б" эквивалентно "а + б".

 

Замечу, что БПФ это только на 50% математика (бабочка, да умножитель). Остальные 50% это управление - откуда данные взять, какие коэффициенты подать, куда результат сложить, куда и когда подавать управляющие сигналы чтобы все пришло в нужное место в нужном такте и т.д. На отладку управления всегда уходить больше времени т.к. если там есть ошибки, то их сложнее локализовать. Вырожденные случаи не в счет.

 

[thermit 1]

Замечу, что БПФ это только на 50% математика (бабочка, да умножитель). Остальные 50% это управление - откуда данные взять, какие коэффициенты подать, куда результат сложить, куда и когда подавать управляющие сигналы чтобы все пришло в нужное место в нужном такте и т.д. На отладку управления всегда уходить больше времени т.к. если там есть ошибки, то их сложнее локализовать. Вырожденные случаи не в счет.

 

угу. если не считать, что бпф в частности и цос вообще на 100% математика, то смысл в таких лекциях конечно есть.

 

хдл всего лишь средство реализации того или иного алгоритма. цос - здоровенный раздел вычислительной математики. на изучение хдл в объеме достаточном для реализации алгоритмов цос нужно потратить месяц. на изучение цос в объеме достаточном для грамотного решения прикладных задач нужно потратить практически всю жизнь. зачем лепить в кучу несравнимые категории? если хдл с бантиками, то пусть лекции будут про хдл с бантиками. а некоторые разрекламированные алгоритмы цос как иллюстрация возможностей хдл. иначе, шарлатанством все это отдает неимоверно.

 

 

 

[FatRobot 0]

Вы, как мне кажется, судите слишком уж строго.

Насколько я понимаю, у автора опроса есть некоторый интеллектуальный капитал в базисе бпф - hdl - uvm. Он хочет его конвертировать. Вполне законное желание.

 

Судя по тому, что объявлено 'на берегу', пытливый слушатель курса по его окончании будет иметь как минимум следующий багаж:

- понимание работы алгоритма бпф и особенностей применения fxp в нем.

- понимание того, как реализовать бпф средствами hdl

- понимание того, как эту реализацию проверить средствами uvm

 

Этот багаж полезен? Безусловно.

Подтолкнет ли он слушателя к дальнейшей мыслительной деятельности? Скорее всего да.

 

Т.е. если условный слушатель на входе умел нарисовать в схематике блок управления елочной гирляндой и проверить его работу в waveform viewer'e, то после этих курсов его жизнь засияет новыми красками.

 

Мне кажется, что всё по-честному.

 

хдл с бантиками,

шарлатанством все это отдает неимоверно.

[Krys 2]

хдл всего лишь средство реализации того или иного алгоритма. цос - здоровенный раздел вычислительной математики. на изучение хдл в объеме достаточном для реализации алгоритмов цос нужно потратить месяц. на изучение цос в объеме достаточном для грамотного решения прикладных задач нужно потратить практически всю жизнь

Мудрое высказывание, надо запомнить )

 

 

если хдл с бантиками, то пусть лекции будут про хдл с бантиками

С этим согласен. Объяснять надо на простых примерах. Я сейчас заканчиваю свою реализацию БПФ для больших последовательностей, поэтому представляю, что в БПФ по алгоритму автора вникать придётся долго и упорно... (читал когда-то в начале своей работы и его длинную тему...). Нет, сама бабочка, конечно - это "2 пальца...". Но вот дальнейшие пересылки и перестановки - та ещё головоломка.

И вот, если бы я пошёл на курсы автора, то я бы не хотел вникать в эти головоломки, т.к. это детали алгоритма конкретной задачи. Довольно объёмные детали, чтобы на них тратить кучу времени (и денег), и это мне не пригодится (успеет выветриться).

Я бы хотел пойти на тренинг и закрыть недостающие пробелы по "хдл с бантиками" как курсы повышения квалификации по инструменту, который я использую, но остальное мне не надо. Я и когда документацию с примерами реализации читаю, то просматриваю по диагонали объяснение алгоритма работы (т.е. конкретной задачи), цепляясь лишь за применяемые приёмы реализации.

Потому и примеры должны быть простыми. Без конкретной задачи научить не получится, но хотя бы снизить накладные расходы на изучение алгоритма самой задачи - можно. Так что поддерживаю, что лучше тренироваться на кошках на мультиплексорах.

 

Конкретно мои пробелы заключаются в SV и в UVM, необходимы углубленные знания в отладке и верификации (обычные есть и так). Мне нужен только по этому тренинг.

 

А так - я бы пошёл чисто гипотетически. На опрос отвечу, что пойду. Цена особо роли не играет, т.к. платить должен работодатель. И 200р за лекцию и несколько тысяч за весь тренинг - это будет сравнимо с ценой перелёта. Конкретное подтверждение участия можно получить только когда будет полностью утверждена программа (и она будет способна закрыть мои выше названные пробелы) и все оргвопросы (место, время и т.д.). Кроме того, как-то должен решаться вопрос с проживанием иногородних. И на всё должны даваться официальные полностью легальные бумажки, подтверждающие оплату. Как самого курса, так и проживания. Подозреваю, что оргвопросы могут отбить у автора желание что-то организовывать ))) Гимор ещё тот )))

------

Да, и шарлатанством я бы это в любом случае не называл, т.к. автор далеко не дилетант. Просто не сразу ясно, что хочет аудитория. Изучение спроса в данной теме - это нормально.

[des00 25]

Цель - исключительно познакомить слушателей с UVM и разобраться с основными элементами инфраструктуры. Не более того. Именно для этой цели, я считаю, самым подходящим является самый простой сценарий.

Так вот и делайте это на простом и понятном примере, раскрывающем красоту инструмента : многоканальный UART. Его знают все вдоль и поперек. На примере БПФ вы покажете цосникам что UVM это "веревка достаточной длины чтобы выстрелить себе в ногу" (с)

Замечу, что БПФ это только на 50% математика (бабочка, да умножитель). Остальные 50% это управление - откуда данные взять, какие коэффициенты подать, куда результат сложить, куда и когда подавать управляющие сигналы чтобы все пришло в нужное место в нужном такте и т.д. На отладку управления всегда уходить больше времени т.к. если там есть ошибки, то их сложнее локализовать. Вырожденные случаи не в счет.

Да, но UVM к отладке внутримодульного управления не имеет никакого отношения. Банальные assert будут для цосника много полезнее, чем вся эта кухня с sequence на sequencer-ах.

 

[Maverick_ 15]

2 Sefo

Может Вам стоит разбить курс на части?

Например:

1. Основы System Verilog для синтеза и верификации.

2. Основы UVM технологии.

3. ЦОС в ПЛИС (тут и будет Ваш пример БПФ - синтез и верификация)

4. ...

 

PS для новичка будет сложно все понять, если сразу начать с БПФ. Мое мнение.

 

Написать типа плана и где-то выложить, а люди сами решат, что им нужно...

[ViKo 1]

На лекцию не пошел бы. На курсы, с лабораторными работами - возможно. Если бы оплатило предприятие. И если бы был уверен в высоком уровне компетентности учителя. В своем городе, естественно.

Сейчас столько информации для обучения, только успевай учись. На ютубе полно роликов.

БПФ - само по себе шарлатанство. Посмотрите, что делают разные оконные функции с вашим спектром. Убицца.

[blackfin 14]

Думаю назначить цену в 200 руб за 90 минутную лекцию с одного слушателя.

 

Потом взяться за основы SystemVerilog и вообще основы описания "железа" на языках HDL. Далее займемся верификацией и, в частности, UVM.

А в качестве методических пособий будут на лекциях раздавать исходники IP cores на SATA, NAND, DDR4, USB3.0, 10G-MAC, PCIe, MIPI, CSI и на прочее "железо" на языках HDL?

[Maverick_ 15]

А в качестве методических пособий будут на лекциях раздавать исходники IP cores на SATA, NAND, DDR4, USB3.0, 10G-MAC, PCIe, MIPI, CSI и на прочее "железо" на языках HDL?

улыбнуло