Comments 58
Большое спасибо за материал, пригодится обязательно.
Добрый день, замечательная статья (хотя не уж то нашлось всего три классических ошибки? Например, хоть я и на начальном уровне, но слышал, что ошибкой является так же использование inout портов для чего-либо кроме для физических портов, т.е. для связи между модулями).
Раз тут такая статья, считаю это отличным местом, чтобы задать сопутствующий вопрос: я отношусь почти к студентам, которые хотят стать… скорее SoC designer, ASIC architector и подобное. Собственно множество вопросов возникает:
Правильно ли в этом случае сначала выбирать FPGA и изучать хотя бы его основы? Поиск по вакансиям показал, что даже на junior требования очень размазаны, от C++ и, почему-то питона (иногда лиспа) до знания всех подряд интерфейсов, шин, архитектур. Вообще усредненный список знаний пугает. В каком направлении лучше всего двигаться? Какие есть учебные материалы ближе к моему выбору? В конце концов, под это учатся отдельно или как в программировании: сначала ты программист, потом старший программист, а потом уже можешь стать архитектором (не все проходят этот путь и такие архитекторы видны сразу)? Почему решил, что тут можно идти сразу в архитекторы — по наличию inter и junior вакансий у некоторых компаний.
И стоит ли набирать опыт в виде разработки под arm, avr, x86, etc. на ассемблере (чтобы в тонкостях понимать эти архитектуры) или сконцентрироваться на verilog/vhdl?
P.S. И почему все и везде лепят матлаб? Я понимаю, что ты не инженер, если не знаешь матлаб, но ума не приложу, как он помогает в проработке архитектуры, а не каких-то конкретных алгоритмов.
Например, хоть я и на начальном уровне, но слышал, что ошибкой является так же использование inout портов для чего-либо кроме для физических портов, т.е. для связи между модулями.
Всё верно, это является ошибкой. Я про неё не написал, потому что про нее забыл. Просто давно такого не видел (исходя из того, что выкладывают на хабре, на электрониксе и того, что сдавали мне студенты). Хотя, пожалуй, стоит про это написать. Спасибо.
SoC designer, ASIC architector
Интересный выбор профессии.
Как мне кажется архитектором можно быть только пройдя весь стек от RTL-разработчика до ведущего разработчика и так далее.
Для корректного ответа на этот вопрос надо сначала написать что должен делать этот человек на работе (его обязанности). (Покажите вакансии, которые смотрели).
И почему все и везде лепят матлаб?
Чаще всего матлаб лепят те компании, которые занимаются ЦОС'ом.
Ну например intel (да, замахнулся я неплохо так, но в матушке России с этим вообще печально. Да и компаний, занимающихся разработкой микроконтроллеров и процессоров не так много в принципе).
Простейший вопрос, который я задал бы любому, желающему попробовать себя в роли SoC-дизайнера: нарисуй схему айфона и расскажи, где какая пропускная способность шин нужна. И как сделать так, чтоб он работал три дня без подзарядки. И чтоб андроед на нем видео показывал, а не слайд-шоу.
Спасибо за ответ. Т.е. получается, что нужно знать кучу всего и еще немного в присыпку? И не столь важен навык непосредственной реализации RTL, сколько понимание устройства всего, и как это еще должно между собой взаимодействовать? Опять же, не подскажите по литературе?
Заодно: для себя я пока пытаюсь реализовать какую-то совсем простую и примитивную SoC. В данный момент есть простейший CPU, который даже умеет что-то считать, а так же простой текстовый GPU, ну и самопальная шина (с подсматриванием в сторону wishbone). И я хочу довести это до этапа, что это действительно синтезируется и работает на плате, и что можно скармливать какой-то код, однако что-то перемудрил с режимами адресации, поэтому подзавис на RTL модуля загрузки данных, но отвлекся. Я двигаюсь в правильном направлении или это тупиковая ветвь и начинать стоит все же с своей реализации уже проверенных временем архитектур, например, OpenRISC? (попытка придумать все самому, в том числе ассемблер, очень хорошо вправляет мозги в плане — почему у других сделано так или иначе)
Сейчас свои процесорные ядра никто не делает — все берут ARM за редким, редким исключением.
Поэтому лучше изучать шину AXI4. И I2C.
Короче, единственный надежный способ — устроиться к кому-то, кто все это уже знает, подмастерьем.
так же хорошо подойдет портал rocketboards.org
Скажите, пожалуйста, а какую плату Вы используете? я сейчас только начал знакомиться с SoC и в качестве учебной получил на выбор Arrow SoCkit, DE1-SoC и DE0-nano-SoC, в прочем, в интернете есть хорошие примеры только на первую и немного на вторую
У самого меня алтера циклон 2 на китайской старой плате. Сейчас думаю обновлять, но не хочу брать готовую SoC, потому что вроде как я сам этим собрался заниматься (комбинировать ip-cores), а не брать готовое, поэтому посматриваю на xilinx kinex 7
Arrow SoCkit — тоже хороша но HSMC хрен достанешь если что то своё захочется подключить.
DE0-nano-SoC мало периферии но опять же IDC я бы сказал это больше не для обучения а для прототипирования.
Чаще всего я им предлагаю глянуть две ссылочки (FPGA и JAVA) и самостоятельно сделать выводы.
Что-то, не понял я какие выводы должен студент сделать из этих ссылок? Вроде по Java и вакансий в десятки раз больше и вилка, похоже, что выше, по тем вакансиям что я вижу. Что-то не совсем понял я этой фишки…
А если и лежит, то надо осознавать, что вакансий в этой сфере не так много даже в больших городах (если мы говорим про Россию, разумеется).
При меньшем знании материала и знании JAVA на текущем рынке можно проще получить ЗП в 50к и обучением, нежели знать VGA и получить 50к как специалист.
КО mode OFF
Сам имею образование по проектированию устройств и вычислительной технике, знаю тонны RFC и обработки протоколов как программно, так и аппаратно, но зарабатываю на жизнь андройд разработкой (ведущий спец), работаю как главный инженер по VOIP + 1-2 своих проекта с циклом жизни год-два.
Есть огромное желание изучить FPGA, но рынок и жизнь диктует обратное. Речь об идейности.
Замечательная статья. Сжато и в одном месте. Надеюсь будете дополнять.
Там есть книги, лекции, дз. Базовый курс будет серьезно доработан за лето.
Дополнения: Вот составленные мною зачеты для студентов, которые я тестировал на куче студентов из Индии в небольшом частном университете в Фримонт, Калифорния, где я помогал читать такие курсы по субботам:
http://silicon-russia.com/exams_and_quizes/
Пример одного из вариантов одного из зачета: http://www.silicon-russia.com/2015/03/19/intro-rtl-fpga-verilog-midterm-1-1/
я являюсь подобным студентом, правда имею определенный опыт использования fpga и пару проектов на них
тоже пользуюсь altera, но вот в качестве языка выбор пал на VHDL
и соответственно регулярный вопрос: почему Verilog/SV? для себя пока что нашел преимущества в sv:
— тип данных longint длинной в 128 бит
— конструкция a = b? c: d
в остальном vhdl пока кажется приятнее, да и в университете его преподают, однако на многих вакансиях Verilog, и не могу понять: в университете неправы или на производствах неправы или каждый прав
Мне приятнее SystemVerilog, я знаю, что благодаря ему я более производителен, чем если бы писал на VHDL.
Предлагаю сделать маленький эксперимент:
- Зайдите в директорию, где у вас хранится Quartus, а затем в директорию ip/altera.
- Посчитайте, сколько там Verilog, SystemVerilog и VHDL файлов.
У меня получилось вот так:
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.v | wc -l
17006
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.sv | wc -l
6012
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.vhd | wc -l
1321
Если оставить только с уникальными названиями файлов, то получается вот так:
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.v -printf "%f\n" | sort | uniq | wc -l
4952
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.sv -printf "%f\n" | sort | uniq | wc -l
2152
ish@xmr:~/altera/15.1/ip/altera$ find . -name *.vhd -printf "%f\n" | sort | uniq | wc -l
1013
Вот насчет этого как раз и не могу найти ни подтверждений ни опровержений, как раз хотелось бы узнать что бы подразумеваете под производительностью VHDL и Verilog (:
P.S. Рекомендую глянуть топик FEC на ПЛИС, где Денис Шехалев (des00) пиарит красоту SV :).
А можете привести примеры вопросов, которые задают уже не junior, а senior-ам на собеседованиях? Чтобы было куда стремиться дальше.
Про что еще можно спросить:
- оптимизация (по ресурсам и частоте)
- конвейеризация
- нюансы САПР'а (его дополнительные возможности, галочки для оптимизаций, например)
- внутренние интерфейсы (семейства Avalon, AXI)
- верификация: UVM SVA, coverage, constrained random tests
Плюс чисто RTL-дизайнеру скорее всего не будут задавать вопросы по advanced верификации.
Ну и разумеется, вопросы по сфере, для которой будет писаться прошивка FPGA.
Если ЦОС, то можно спросить про фильтры, если Ethernet, то про то как работает свитч или роутер.
На самом деле разница между джуниором, миддлом и синиором в опыте. Причем в том, который нужен команде, в которую идет устраиваться потенциальный кандидат. Еще есть нюанс, что команда с большей вероятностью будет спрашивать то, что она сама использует. Например, если она не использует ассершены в верификации, то она не будет спрашивать это на собеседовании (если только не стоит задача найти человека, который круто разбирается в ассершенах и заставить его внедрить это в весь проект).
Если команда разрабатывает для Ethernet'a на частоте 200 МГц на Stratix V, и приходит человек с годом опыта и он делал аналогичные задачи, то этот человек «опытнее», чем тот, который пять лет делал SPI-контроллеры на частоте 20 МГц на маленьких простеньких чипах.
Понять, насколько потенциальный кандидат успешно решал задачи, легко, если с ним поболтает час или два технический специалист (читай, другой FPGA разработчик), спрашивая простые вопросы:
- Как делали? Какая была архитектура всего проекта?
- Какие IP-ядра использовали готовые (покупные или из опенсорса)?
- Какие модули конкретно ты разработал? Сколько времени это заняло?
- Какие вылезли косяки/баги?
- Какая самая сложная проблема была?
- Как оптимизировали? Что помогло в оптимизации?
- Какой интерфейс использовали?
- Как настраивали [модули или IP-ядра]?
- Как была построена верификация?
- Как тестировали на железе?
Но, как показывает практика, работы с железом в СНГ, постсоветском пространстве очень мало — нет почти ничего.
Вот так это и остается в лучшем случае, как хобби. :)
Тем, кто работает в этой сфере — поклон!
И хотел бы задать вопрос. Возможно я что-то упустил, но в своей практике столкнулся с очень ограниченной поддержкой SV конструкций САПРом от альтеры. Если это так, то в чем вы тогда моделируете? Сам я Занимаюсь разработкой ASICов и тут таких проблем нет.
SV симулировали в Modelsim, синтезировали родным Квартусом.
Какие синтезируемые конструкции не работали у Альтеры, а работали для ASIC-синтезатора?
Добавлю, что далеко не каждый Junior (и даже Middle) может похвастаться всем тем, что требуется из списка «Необходимо». Особенно, если после нескольких лет работы у человека начинается специализация в то или иное направление (реализация высокоскоростных интерфейсов или углубление в ЦОС, например). Получается, что существенную область разработки человек попросту игнорирует из-за специфики конкретно его работы.
Меня часто спрашивают начинающие разработчики на ПЛИС (зачастую студенты старших курсов), что почитать, какие книжки нужно держать под рукой, что нужно уметь, знать, применять и куда расти. Когда я им вываливаю полный список того, что прочитал я или мои коллеги (и что ещё предстоит прочесть), то энтузиазм несколько угасает. Теперь в список для чтения ещё и вашу статью добавлю! :)
Забавно, но у тех, кто ко мне обращается, тажке зачастую возникает вопрос: "FPGA vs WEB"? И практически всегда люди делают выбор в сторону того, что проще и в конечном счете позволяет иметь бОльшую гибкость. И это правильно.
P.S. кстати, а где в требованиях умение пользоваться осциллографом? (с железками ведь работаем, как-никак) :)
Конечно, это очень спорно, потому что многие в эту «должность» вкладывают еще и умение разводить платы (т.е. схемотехника) и пр.
Я считаю, что FPGA Design Engineer должен быть в первую очередь хорошим RTL-кодером. Конечно, умение пользоваться осциллографом никому не вредит, но я лично предпочту работать с человеком, который знает что такое констрейны и метастабильность и умеет быстро писать код, но не умеет тыкать в резисторы щупом для просмотра сигналов.
Кстати, насчет схемотехники. В нашем отделе давно сложилось правило, что опытный разработчик на ПЛИС должен не только прошивки делать и исключительно с ПЛИС работать на уровне написания/верификации кода для поставленной задачи, но еще и схемы рисовать с обоснованным выбором тех или иных компонентов. К счастью, без разводки платы, для этого есть отдел конструкторов. Такие вот дела. :)
Сфера ЦОС:
— Эммануил С. Айфичер, Барри У. Джервис. Digital Signal Processing: A Practical Approach
— Рабинер и Голд. Теория и практика цифровой обработки сигналов.
Также при углублении в область ЦОС на ПЛИС очень полезно будет на начальном этапе ознакомиться с даташитами на IP-ядра от тех вендоров, с которыми будете работать. В даташитах подробно описаны основные моменты, без сильного углубления в теорию. Дополнительный плюс таких IP-ядер — легкость моделирования и отладки.
High Speed Trancsivers:
— High-Speed Serial I/O Made Simple от Xilinx.
Книга позволяет получить первичное представление о гигабитных трансиверах и их начинке, дает основные определения и описывает проблемы, возникающие при разработке интерфейсов передачи.
Но есть и критика.
Во-первых, не согласен категорически с разделом «Не соблюдение принципов синхронного дизайна». Как говорят классики, шедевр создают только те, кто выходят за пределы правил. Асинхронщина часто помогает сделать тот же кусок кода в 2-3 короче, просто, что бы понимать как работают асинхронные схемы нужно больше опыта и понимания, чем при тупом ваянии синхронных схем. Более того, есть случаи, когда без асинхронных схем не обойтись. Нужно, как в анекдоте, просто уметь их готовить :))
Насчёт использования STP. «Нет, ребята, всё не так, всё не так, ребята». Во многих случаях гораздо быстрее и удобнее прикрутить STP и посмотреть, что там происходит. Насчёт 5-10 минут, кто вам мешает пересобирать только тот кусок, который не работает, не трогая остальной проект? Я не слышал, что бы в Квартусе оменили опцию частичной пересборки. Или по-вашему для проверки какого-то небольшого тонкого куска лучше и быстрее ваять на 20 страницах верстак (который больше не понадобиться)? А дальше, что бы было (относительно) адекватное моделирование, вы запустите моделсим в режиме вентильного моделирования и этот неповоротоивый монстр будёт её обсчитывать минут 20-30 и в конце-концов тупо свалиться. Ну да, конечно, это явно быстрее, чем в два щелчка прикрутить stp и за 10 мин пересобрать схему :)) И не надо забывать, что stp вам показывает живые сигналы, а моделирование — это некоторое и довольно грубое к оным приближение.
Ну и, кстати, реально СистемВерилог по-сути не имеет существенных преимуществ на тем же Верилогом-2001. Мало того, как выразился как-то про СистемСи Панчул, — «это очередная попытка изнасиловать мозг разработчика». То же я бы сказал про СистемСи. Единственная полезность для меня там оказалась в упакованных массивах. Всё остальное — нафиг не нужно. Я уже 20 лет ваяю сложнючие схемы обработки сигналов (топовые Стратиксы-4 забиваются под завязку), но ничего сложнее тупого верстака на верилоге, который вычитывает входные данные из файла, сгенерённого Матлабом, прогоняет через Моделлсим и потом пишет выходы для того же Матлаба мне никогда не надо было.
Но есть и критика.
У каждого свой взгляд на эту сферу и это вполне нормально)
Спасибо, что высказываете своё мнение по данной теме.
Или по-вашему для проверки какого-то небольшого тонкого куска лучше и быстрее ваять на 20 страницах верстак (который больше не понадобиться)?
Лучше — да. Быстрее — нет. А вообще ответ зависит от специфики граничного случая.
Этот «верстак» можно сохранить как один из тесткейсов, и запускать каждую ночь в continuous integration и спать спокойно, зная, что с утра вам придет репорт о том, что вы или ваши коллеги ничего не сломали после последнего коммита.
Я уже 20 лет ваяю сложнючие схемы обработки сигналов (топовые Стратиксы-4 забиваются под завязку), но ничего сложнее тупого верстака на верилоге, который вычитывает входные данные из файла, сгенерённого Матлабом, прогоняет через Моделлсим и потом пишет выходы для того же Матлаба мне никогда не надо было.
Если на протяжении 20 лет вам удается обходится минимальными тестами и окружениями для тестирования и всё разрабатывается за минимальное время и работает с первого раза, без дебага и пр., то это очень здорово.
У меня другая сфера разработки под FPGA (не ЦОС) и другой опыт, который говорит о том, что лучше студента/джуниора заставлять писать тесты, и сначала на них прогонять данные, а только потом запускать это всё на железе. Возможно, когда у меня будет 20 лет разработки под FPGA, то у меня будет другое мнение по этому вопросу.
Какой путь трансформаций проходят исходники (*.v файлики) с момента написания до момента попадания в Flash память FPGA?
Подобно программированию на С(ях), где цепь такая
*.с->*.obj->*.elf->*.bin->OnChipNorFlash
Какая "пищевая цепочка" файлов в ToolСhain(е) для FPGA?
Можно ли представить схему ToolСhain() для разработки на FPGA?
https://habr.com/ru/articles/688542/
3. Напишите модуль для управления светофором, который будет зажигать красный, желтый и зеленый фонари во всем известной последовательности: красный, красный и желтый, зеленый, зеленый моргает, желтый, красный. Параметры, задающие время горения фонарей светофора и период мигания зеленого фонаря являются параметрами модуля. Время задается в количестве тактов синхросигнала clk_i.
Для изучения FPGA нужна такая учебная задача, которую на микроконтроллере решить нереально .
Реализацией на FPGA светофора или soft процессора сегодня никого не удивишь. Это наоборот провоцирует отвращение, так как выглядит техническим садизмом. Разумнее взять готовый микроконтроллер и сделать этот пресловутый учебный светофор.
На FPGA можно DSP на лету делать. Вот на это надо акцент делать! Дискретное преобразование Фурье, цифровые фильтры, корреляция, свертка, смешивания сигналов. Вот это надо сразу пробовать на FPGA.
Поэтому FPGA и используют как основу радиолокаторов (РЛС).
Но ADC DAC для РЛС школьникам и ВУЗовцам не по карману. Там цены за полмиллиона рублей за микросхему ADC (AD9208-3000EBZ)
https://www.chipdip.ru/product0/8005793559
Зато вот аудиокодеки стоят дёшево.
https://habr.com/ru/articles/703588/
Поэтому FPGA надо изучать в контексте аудио обработки.
Причём в США так уже давно делают вот ссылка на учебный курс (канал Bruce Land )
https://www.youtube.com/watch?v=56ax9pXFY-A
https://www.youtube.com/watch?v=E-DvVidEvVg
Audio+FPGA просто калейдоскоп приличных вариантов учебных проектов
-звуковые сонары
-Звуковые дальномеры
-Детекторы стрельбы
-Звуковые эффекты в реально времени (эхо, дисторшн),
-Звуковая локализация,
-Передача бинарных данных модулированным звуком (DTMF)
-обновление прошивок звуком
-Звуковые лазеры (см проекты MIT)
-Определение скорости поездов по доплеровскому смещению от звука колес
-Звуковая навигация
-наушники с активным шумоподавлением
--датчики шума в реальном времени
-дефектоскопы
-звуковые датчики уровня жидкостей
-звуковые датчики скорости потока жидкости
и прочее
При этом все полученные в аудио обработке знания легко переносятся на радиодиапазон просто повышением частоты и стоимости микросхем ADC/DAC.
Какую отладочную плату с FPGA Вы могли бы порекомендовать в качестве отладочной платы для изучения и экспериментов? Желательно, чтобы на PCB был чип аудиокодека.
Junior FPGA Design Engineer: как стать?