Pull to refresh
101
0
Иван @ishevchuk

User

Send message
Скорее всего при сборке под Arria 10 вы будете использовать Quartus Prime Pro.
Самая последняя версия на текущий момент — 19.4.
В <директория установки квартуса>/hld/README.txt есть такие строчки:

The Intel® FPGA SDK for OpenCL(TM) is a C-based heterogeneous parallel
programming framework for Intel® FPGA devices.
This is an implementation of the Khronos OpenCL 1.0 Specification.
This version passes the Khronos OpenCL Conformance Testing Process.
Проделана большая работа, респект!

Правильно ли я понимаю, что Layerth и другие системы, которые применяются при трансляции проигр, для получения подобной информации используют какие-то «простые» API Dota/Valve/Source, и обходятся без реверс инжиниринга?
Немного опоздал к прямой линии, но не могу не спросить:

есть ли в планах добавить возможость:
шарить черновик статьи с другими хабрапользователями, хотя бы в режиме read-only, а как максимум в режиме редактирования?

Кейсы использования:
1) (read-only) получить рецензию на статью (поиск ошибок, опечаток) перед публикацией от коллег/знакомых
2) (редактирование) тривиальная помощь в оформлении, исправлении опечаток и пр.
3) (редактирование) отдача на аутсорс перевода статьи. Например, у вас есть хороший текст на одном языке и надо его перевести на русский (или на английский). Вы шарите ссылку на конкретный черновик переводчику и он это делает уже в самом интерфейсе хабра, а не где-то в гуглдоке или чем-то таком.
Теперь у многих читателей постов про ПЛИСы часто возникает вопрос: «А зачем это надо, ведь на Джаве работ больше?»
На это можно ответить: согласно сайту glassdoor, в Сан-Хосе, Калифорния, разработчики цифровых схем ценятся дороже, чем разработчики на Джаве:

А разработчики С++ ценятся выше, чем разработчики цифровых схем. Да и Java работ не больше, чем у «железа» (если говорить про тот же Сан Хосе). 1700 вакансий у С++, 1900 у Hardware Engineer и 1300 у Java.

Дмитрий, спасибо за статью.
Я надеюсь, что Вы не будете в обиде за мнение о статье.

Мой комментарий содержит две части, в каждой из них делается акцент на разных проблемах.

Часть первая (содержание статьи)

Вы подняли интересную и важную тему (сравнение конструкций языка в симуляции и в железе, и что делать, чтобы они совпадали). Мне кажется, можно было бы улучшить статью, если изначально предложить код, и попросить читателя провести “симуляцию” кода в голове и на железе, а затем уже обсудить почему получаются расхождения. А затем предложить еще примеры, когда происходят различия. Но это всё мелочи.

Главная проблема в том, что Вы не даете доказательств. Например, ссылки на стандарт, который обсуждается в статье. На мой взгляд очень важно делать отсылки на конкретные части конкретного документа, когда мы говорим про нюансы языка/окружения. Читатель должен иметь возможность перечитать это на английском языке и “перепроверить” перевод/понимание автора статьи. Мы бездумного сравниваем примеры VHDL и Verilog, но может там есть разница в симуляции? Было бы здорово указать марку и версию симулятора, в котором производились “измерения”. В качестве доказательства, что в железе будет по-другому можно было бы приложить скриншот из SignalTap/ChipScope.

Дельта-задержка это не единственный “нюанс” в симуляции. Там есть “слоты”, “регионы”, “события” и так далее. Я ожидаю от статьи, где разбираются задержки и симуляция, описание как действительно работает симулятор, с всеми фазами, ограничениями/допущениями, либо ссылки на другую статью на русском языке где это хорошо описано. Такую статью можно было бы использовать как референсную, когда кто-то что-то забыл про симуляцию и решил освежить память и прочитать это на русском языке с хорошими примерами.

К сожалению, эта статья скрывает все подробности работы симулятора, а начинающего разработчика, который хочет разобраться как работает симулятор, она только запутает, т.к. нет ссылок на конкретный стандарт и литературу, из которой и делаются выводы, например:
Вот здесь начинается самое интересное — когда надо изменить значение b. Казалось бы надо изменить его сейчас, в этот момент времени. Но у нас параллельные процессы. Может быть, нам ещё понадобиться значение b для расчёта других сигналов. И вот здесь появляется понятие дельта задержки.


Сейчас статья напоминает неформальное обсуждение за пивом.
А: Слушай, ну помнишь, есть дельта-цикл, из-за этого мы ставим задержки.
B: А, да, точно я что-то про это читал. Ну, да, вроде логично, спасибо, тоже буду ставить.

Она не помогает разобраться и точно понять что происходит и почему, и как это перепроверить/доказать.

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

Часть вторая (выводы)

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

Как известно, самая важная часть в статье – это её заключение или вывод.

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

Пример, который Вы привели слишком вымышленный. Сложно поверить, что в модуль заходит клок, из него делается второй клок и часть триггеров питается от одного “клока”, а часть от другого.

Потому что это нарушение принцпов синхронного дизайна: формирование клоков и ресетов должно быть в отдельных модулях, отделённых от логики.

Допустим, наоборот, два клока приходят на входе модуля (которые по факту являются одинаковыми и переназначаются в другом модуле), то возникает вопрос: почему значение d берется с триггера b, хотя они находятся в разных клоковых доменах и не происходит корректной пересинхронизации между клоковыми доменами. А если это всё-таки один клок, то зачем заводить на модуль два клока?

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

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

Если был бы разобран такой пример (со всеми констрейнами) и было бы “доказано”, что без использования задержек в конкретном случае нельзя (либо нужно написать в десять раз больше кода), то я бы согласился, что это полностью оправдано в данном конкретном случае, и использование задержек допустимо в модулях, где происходит некоторая “магия”, а когда уже все “синхронизировано” и идет поток данных, уже можно без них обойтись. Но из этого нельзя сделать вывод, что когда у меня один клок в системе и полностью синхронная схема я должен везде расставлять задержки.

В комментариях Вы написали, что написание задержек это отчасти некоторое легаси, и Вы напоролись на некоторые проблемы из-за старого кода и теперь приходится их везде писать. Наследие неидеального кода – это проблема, которая встречалась многим разработчикам. В фразе “я делаю так, потому что у нас такое наследие, и нет бюджета всё исправить” я не вижу ничего плохого, такое, к сожалению, бывает, и идеальная картинка в книгах (советах из интернета) рушится с тем, что происходит в жизни.

На самом деле вопрос же заключается в том, что если удалить все исходники, уволить всех коллег, оставить только Вас и набрать в FPGA команду студентов, которые ничего не знают, то Вы тоже будете им предлагать писать задержки во всех модулях и во всех проектах или нет? При условии, что Вы их руководитель/учитель/ментор и Вам дают большой бюджет и никто со сроками не торопит.

TLDR: содержание статьи слабое, т.к. подробно не разобрано как работает симулятор. Вывод статьи дается на суперсложном странном примере, который может встретиться при плохой организации разработки или легаси. Его нельзя распространять на всю индустрию.
Как я понимаю, команды из ЛЭТИ и ИТМО составлены из программистов, которые успешно работают в коммерческой разработке в течение долго времени.

Как мне кажется, наличие отдельных сильных программистов не влияет на область целиком.
Не уверен, что одна/две/три команды сильных FPGA-разработчиков из СНГ отображает «силу» на поле)

Не имеют возможности написать техническую статью?

Если такой возможности нет, то чего тогда жаловаться, что хабр не торт?
Есть очень простой ответ/совет — необходимо не стесняться минусовать те статьи, которые вы считаете лишними на Хабре.

Если все люди, которые поставят плюс к комментарию (на текущий момент их 20) будут каждый день минусовать «ализаровщину с кликбейтом и блоги компаний со смешными картинками», то некоторые из таких статей не будут попадать на главную, и как результат — их станут меньше писать со временем.

У нас же саморегулируемое сообщество.
Вы правы, статья не для новичков.

Как я и писал выше:
Если вы купили кит и хотите обучиться разработке под FPGA, не рекомендую делать тетрис прям в качестве первого проекта.

Честно говоря, быстрого освоения темы («Тетрис за 21 день»), я не рекомендую, т.к. в FPGA слишком много нюансов и различий относительно обычной софтовой разработки.

Я думаю, что стоит начать с этого: habrahabr.ru/post/281525

Скорее всего там будет литература, которая позволит разобраться в проекте, хотя, он и не идеален, и иногда отходит от «хороших правил разработки».
Но есть и критика.

У каждого свой взгляд на эту сферу и это вполне нормально)
Спасибо, что высказываете своё мнение по данной теме.

Или по-вашему для проверки какого-то небольшого тонкого куска лучше и быстрее ваять на 20 страницах верстак (который больше не понадобиться)?

Лучше — да. Быстрее — нет. А вообще ответ зависит от специфики граничного случая.

Этот «верстак» можно сохранить как один из тесткейсов, и запускать каждую ночь в continuous integration и спать спокойно, зная, что с утра вам придет репорт о том, что вы или ваши коллеги ничего не сломали после последнего коммита.

Я уже 20 лет ваяю сложнючие схемы обработки сигналов (топовые Стратиксы-4 забиваются под завязку), но ничего сложнее тупого верстака на верилоге, который вычитывает входные данные из файла, сгенерённого Матлабом, прогоняет через Моделлсим и потом пишет выходы для того же Матлаба мне никогда не надо было.

Если на протяжении 20 лет вам удается обходится минимальными тестами и окружениями для тестирования и всё разрабатывается за минимальное время и работает с первого раза, без дебага и пр., то это очень здорово.

У меня другая сфера разработки под FPGA (не ЦОС) и другой опыт, который говорит о том, что лучше студента/джуниора заставлять писать тесты, и сначала на них прогонять данные, а только потом запускать это всё на железе. Возможно, когда у меня будет 20 лет разработки под FPGA, то у меня будет другое мнение по этому вопросу.
Да и применение VHDL в определенном круге задач позволяет на этапе компиляции уже избежать потенциальных проблем, особенно когда код асинхронный.

Я не очень большой специалист в VHDL (больше ковыряюсь в Verilog/SystemVerilog), но как именно VHDL позволяет избежать проблем если код асинхронный? И что Вы понимаете под «асинхронный код» в данном контексте? Просто комбинациионную логику, или большие асинхронные схемы без тактовой частоты?
Какой наблюдается bit error rate при использовании кодирования 8/10, 64/66, 64/67 и без использования кодирования?

Сравнивался ли этот показатель с результатами, показанные на платами других производителей?
Напоследок проверим производительность Ethernet (ETH 1G) — разъем XS11, нижний коннектор:

Есть возможность проверить производительность 10G? Как на TCP, так и на UDP iperf-тесте? :)
Вот уже показалась призрачная экономия энергии. Я считаю, что каждая логическая функция кушает энергию.

На сколько я помню, логическая функция кушает два типа энергии — статическую и динамическую.

Если функция ничего не делает (не происходит переключений, например, N тактов стоит константа), то она не потребляет динамику.

В Quartus есть Power Estimator, который показывает сколько будет потреблять прошивка энергии при заданном количестве (частоте) переключений, тактовой частоты и пр. Возможно, для качественной оценки уменьшения количества энергии, надо поиграться с этой тулзой и посмотреть на результаты.
Дмитрий, спасибо, что рассказываете о своих разработках и достижениях.

Что требовалось от Операционной Системы, чтобы это всё заработало (приходилось ли драйвер писать/модифицировать для этого)? Как это сейчас видится в системе? Как два /dev/ устройства? Как данные попадают в юзерспейс?

Для сообщения о том, что дескриптор был обработан, используется прерывание или поллинг?

Задержки возникают из-за работы других устройств. Величина задержки может быть разной, это может быть 5 – 10 мкс, а может и больше.

Вы в Чипскопе видели, что обмен по PCIe встает на 10 мкс? Или 10 мкс это суммарное время простоя за измеряемую одну минуту? Какие еще PCIe устройства подключены были к CPU? Пробовали ли их отключать?
Возможно, поэтому о том, как привлекают (и удерживают) на работу лучших IT-специалистов, надо спрашивать у самих IT-специалистов.
Это может привести к тому, что разработчики проводят исследования, пишут код, используют новые библиотеки, а техлид снимает «сливки».

Он получает этот опыт за небольшое время, пишет об этом статьи на хабре и ездит по конференциям, представляя результаты работы своей компании (читай, своих разработчиков).

Вижу здесь два негативных момента:
  • Простые работяги, которые пишут код (и именно их результаты пиарит техлид), завидуют своему боссу, который зарабатывает известность и ачивки для линкедина.
  • На этих конференциях на вопросы по нюансам техлид может и не ответить.

Information

Rating
Does not participate
Registered
Activity