Обратная сторона It

Субъективизм
 Этот пост является исключительно моим субъективным мнением посвященным "темной" стороне it (на самом деле худшим проявлениям людских качеств). В этом рассуждении и я не желал и не стремился кого-нибудь обидеть, хотя мне в общем-то пофиг.

Как все начинается

До того, как я начал работать в it и участвовать в проектировании и разработке электронных схем и ПО уровня Enterprise, я считал, что разработчики это люди увлеченные техникой, идеями глубокого познания самого мира через исследование прикладных сторон жизни. Со временем это мнение начало меняться в силу того, что программисты  и инженеры в большинстве не отличаются от людей, выбравших другие профессии. Для  многих "специалистов" it это способ выгодно пристроить свою жопу, сесть на теплое место и не париться (получать неплохие по сравнению, с другими отраслями, деньги). В It есть огромные плюсы: например, можно на протяжении нескольких лет делать примерно одно и тоже (постараюсь описать на примере нескольких пациентов) не напрягаясь, особенно если тебя не напрягают (это не работа на заводе во вредных условиях и т.п.) и при этом получать зарплату в 2-3 раза выше средней по региону. Такое поведение относится к области психологии, но при этом хорошо описывается законами физики (закон сохранения Энергии, принцип Ле Шателье и т.п.)

Прежде всего нужно разобраться с тем, почему так происходит (почему мои коллеги по профессии глупы, невежественны и заносчивы) нужно понять, а что может мотивировать человека делать ту или иную работу (тут скорее всего следует сказать не делать работу, а торчать на работе):

•  1. Материальное вознаграждение
• 2. Слава/признание других троглодитов/чувство собственной важности и крутизны
• 3. Страх неизвестности, что придется искать новую работу , а это уже новые вызовы, особенно, если квалификация не соответствует материальным запросам.

Как мне кажется, третья причина  очень сильно склоняет людей к консерватизму, нежеланию перемен, изучению чего-то нового и т.п. Для себя я четко определил, что раз жизнь относительно коротка, то не зачем делать либо скучную/неинтересную работу, либо сидеть на одном месте если есть более перспективные в финансовом плане варианты. Подобный консерватизм на корню убивает желание изучать новое (новые технологии, состояние отрасли, да хотя бы языка с использованием которого ты пишешь код). Жизнь это движение, а застой убивает все, т.е. в it все абсолютно как в жизни.


Я просижу тут до пенсии/смерти (выйду ногами вперед)
Карьера штука, конечно же, хорошая, однако если человек сидит N лет подряд и он такой же, каким был эти N лет назад (я не рассматриваю назначение человека на новую позицию/должность ). Такой человек по уровню, как правило, балансирует между джуниором и мидом (хотя может по позиции быть и сенионом, и тимлидом), но при этом он конечно же считает, что развивается и становится лучше. Но для того, чтобы оценить это нужно задать вопрос себе: "А сделал ли я за эти пять/десять лет хоть одно решение, которое можно считать проектированием вообще? Или я всегда стоял за чье-то спиной? Может быть я решил хоть одну по-настоящему сложную и интересную задачу? Или быть может я тянул весь проект и я был архитектором системы?".  У меня есть друг, который был обеими руками за все самые лучшие принципы проектирования, он говорил я учусь у тебя и тому подобное, но по факту оказалось, что он не может сделать ни одной серьезной задачи, более того он стал выбрасывать непроверенный код на "от****сь" в тех задачах где он мог себя неплохо показать, увы этот человек меня все больше и больше поражает своей некомпетентностью.

Я инженер, мне книги читать необязательно 

Был у меня уникальный коллега, который считал, что раз он получил диплом инженера, то книги читать вовсе не обязательно, что он все умеет идеально, а остальное посмотрит в интернете. Цензурно я не могу это прокомментировать, т.к. перед глазами стоит картина, как отец в выходные читал самые разнообразные книги по инженерном делу, деталям машин, изобретательству  или просто по прикладной математике. Но "крутым" инженерам это не нужно, они же новые Королевы, Александровы и др. выдающие инженеры.

Зона комфорта или плевать на все
Тут я опишу печальный личный пример. У меня был начальник (начальник небольшого отдела разработки), который отстаивал идеи хорошего проектирования, уменьшения хаоса в системе и т.п., однако, случилось несчастье и этого прекрасного во всех отношениях человека не стало. А он был бетонной стеной, защищавшей всех нас (разработчиков) от тупорылого технически неграмотного руководства и лагеря альтернативно одаренных бизнес-аналитиков, причем все говорили: "Ух да, аналитики козлы, вообще ничего не понимают". Но после всего этого, они забыли все и стали с руководством предельно любезными, продали все принципы ради того, чтобы получать регулярно премии от аналитиков.

Да, в принципе, ничего нового

Да абсолютно так, все уже было написано ранее, возможно, отчасти в русской классике (например, Горе от Ума). Данный пост не является нытьем или чем-то в этом духе, просто для самого себя, хотелось до конца прояснить все эти моменты. Лень, нежелание двигаться вперед, попытка быть угодными всем, отказ от принципов делают нас слабыми и безвольными. В общем не стоит прогибаться...

Как справиться с багами в Vivado (Xilinx)

Предыстория 

До недавнего времени моя работа с ПЛИС (FPGA, PLD) касалась лишь работы с микросхемами серии MAX7000 Altera (Intel), на тот момент времени мне казалось, что хуже Altera ничего нет из-за изобилия недостатков их ПО (Quartus), например:

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

Мое мнение об превосходной отвратительности ПО Altera прожило ровно до того момента, пока я не погрузился в чудесный мир от Xilinx с Vivado. Начал я с последней, на тот момент времени (осень 2016),  версией - 2016.2 Сам перенос проекта на другую версию Vivado сопряжен с рядом проблем, о которых я напишу позднее, поэтому до полной реализации устройства я не решился переносить проект и продолжил работу с 2016.2.

Сказать ужасно значит вовсе не описать качества продуктов Xilinx.

1. Документация по софтовым продуктам, чипам, проектированию и т.п. доступна в разных документах с именами UGXXX, где XXX - номер документа. Документация временами и правда UG, многие вещи необходимо искать в многостраничным pdf, в которых на зерно информации тонна воды, документы не всегда актуальны (созданы для более ранних версий Vivado).

2. Сам принцип дизайна, у 12-13 версий Quartus проектирование строилось относительно создания топового модуля с использованием HDL, у Xilinx нужно нарисовать блок дизайн, затем на основе него создать топовый модуль,  причем обязательно нужно создавать процессорное IP - ядро и IP-ядро сброса, подцеплять к минимальной системе источники тактового сигнала (клок), подцеплять DDR оперативку и т.п. Хотя это SoC, поэтому тут все сложнее, чем для более простых семейств ПЛИС, но тем не менее Xilinx  не предусмотрела ситуации когда мне нужно только логические ячейки без всех наворотов (без AXI и т.п.).

3. Работа Vivado: сотни предупреждений на собственные IP-ядра (ядра от Xilinx) при синтезе.

4. Дизайн: ориентирован на IP-ядра, а не на модули. Я не думаю, что на легковесные модули типа таблицы преобразований или инвертора нужно создавать IP-ядро, однако Vivado сильно параноит при использовании модулей.

5. Ресурсы. Очень долго выполняется синтез и имплементация проекта занимающего процентов 10-20% всех ресурсов от Zynq-7020. Например на 4-ядерном E2-6110 (слабенький 1,5 ГГц и TDP всего 15 Вт) полный цикл - 1 час. На топовых процессорах летает (на моем i7 - 1-2 минуты). По ощущениям Quartus на слабых машинах работал в разы быстрее. На аппаратной виртуальной машине, созданной на KVM с 4 ядрами и 5 Гб оперативки может упасть с Out Of Memory Exception (даже жирный своп не помогает от этой болезни).

6. Кривые и забагованные Vivado и Xilinx SDK, которые могут вылететь и закончить работу по абсолютно любым причинам с потерей всех результатов работы (на практике я не решился использовать частичный результат работы синтеза или имплементации при вылете на одном из шагов для продолжения с этого шага).

7. Отсутствие средств для инверсии логических сигналов на блок-дизайне (да мне пришлось создать модуль инвертора с телом в 3 строчки verilog кода)

8. Куча других более мелких причин...

Использование СКВ (системы контроля версий) для работы с проектом 

Наиважнейший момент при разработке на ПЛИС. Отдельную функциональность/фичу я реализую в отдельной ветке и потом уже объединяю с основной ветвью (как правило, это master). На мой взгляд, идеальный выбор это git, для ряда своих проектов я использую github. У меня была ситуация когда по непонятным причинам код в двух ветках оказался полностью нерабочим, я не мог ничего сделать несмотря на массу попыток и относительно простых изменений в дизайне, поэтому пришлось откатиться на ветку, от которой я создал ранее обе эти ветви. Если бы у меня не было СКВ или СКВ с неудобной работой с ветками (CVS, Subversion) я бы попал в неприятное положение (получил бы нерабочий дизайн в trunk) и, возможно, мне пришлось бы создать весь дизайн заново.

Для всех своих проектов я использую следующие правила размещения создаваемых мною файлов:

./src - директория с моими HDL - исходниками, если использовать %ProjectName%.srcs/sources_1/..., то, во-первых, это выглядит ужасно, а, во-вторых, мы получим кашу из генерируемых Vivado файлов и собственных HDL-исходников, сама же Vivado любит на каждый чих делать толпу изменений в файлах. Если вы что-то поменяли в одном из модулей и желаете сделать коммит изменений одного конкретного модуля, то такой подходя позволяет быстрее находить измененные модули в списке измененных файлов .
/tests - файлы тестбенчей на HDL-модули
/constraints - директория для сохранения файлов ограничений (как временных, так и физических), здесь ситуация аналогичная с src
/app - рабочее пространство (воркспэйс) С/С++ Xilinx SDK-проектов (софтина, созданная на базе Eclipse, но с бОльшим числом проблем, чем у Eclipse.
/config - файлы аппаратной конфигурация SoC.
/ip - каталог моих IP-ядер.

Чтобы в коммите не было по 1000+ изменений файлов (я не шучу их реально несколько сотен минимум), нужно правильно настроить .gitignore (список не отслеживаемых файлов/директорий с возможностью задания имен по шаблону). Например, в качестве образца можно использовать такой шаблон: https://github.com/OpticalMeasurementsSystems/2DImageProcessing/blob/master/.gitignore

А вот и сами проблемы

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

1. Синтез/имплементация падают с генерацией исключения и демонстрацией мессадж бокса - проблема в кэше, для лучшего эффекта стоит удалить директории %ProjectName%.hw, %ProjectName%.cache, %ProjectName%.runs.

2. Синтез/имплементация зависли на длительное время - некоторые проблемы, когда Vivado падает не отображаются в виде мессадж боксом, но они видны в окне Log. Решение сбросить синтез имплементацию (нажать на кнопку Cancel в правом верхнем углу), прибить директорию %ProjectName%.runs.

3. На блок дизайне не обновляется размер некоторых портов, например, Concat IP-ядро. Для этого можно попробовать сначала сбросить Output Products (Reset Output Products при клике правой кнопкой мыши по экземпляру HDL Wrapper'а в иерархии исходных файлов модулей), а затем сгенерировать их заново (Generate Output Products).

4. При запуске Xilinx SDK появляется Splash Screen, потом пропадает, сам SDK не запускается. Нашел 2 причины с проблемами запуска SDK:
       1) Оказалось, что у меня на компьютере было установлено 2 версии Java Development Kit (x32 и x64 параллельно), удалил x32 и SDK стал запускаться без проблем.
       2) Хардкорное решение: удаление папки .metadata, тогда из воркспэйса пропадают все проекты кроме hardware platform, восстановить проекты легко File->Import->General->Existing Project Into Workspace, выбрать галочками необходимые для импорта проекты, нажать ОК.
Видео рения этой проблемы здесь: https://www.youtube.com/watch?v=R_dwpoqsmX4

      3) [Дополнение]: Заметил, что если удалить файл lock в metadata и директорию  eclipse.cdt.ui из плагинов там же в metadata, то можно избежать повторного муторного добавления проектов в воркспэйс (не знаю, работает ли это во всех случаях или нет).

5. Неожиданно перестал собираться BSP, вероятно, в воркспеэйсе появился доп. хардварный проект, а BSP связан с другим железом, для решения этой проблемы удаляем все лишние hardware проекты и обновляем железный проект через правый клик по проекту -> Change Hardware Description File (выбираем экспортированный hdf) и вуаля, после этого можно собрать BSP и приложение.

6. Не открывается репозиторий одним из гит клиентов (GitKraken и т.п.) - это связано с запущенным SDK, который блокирует доступ к скрытой директории .git, решение - закрыть SDK.

Почему все так ужасно?

Можно сказать, что это болезнь всего ПО, заточенного под Embed-проектирование, оно все, как правило, ужасно и изобилует большим количеством багов, а современные тенденции к генерации HDL-кода из ПО для моделирования типа Matlab + SimuLink приводят к разрастанию самого кода ввиду неоптимальных подходов, плохой поддержке этого кода, к созданию "одноразового (write only)" кода и т.п., уменьшают порог вхождения и увеличивают степень энтропии создаваемого продукта людьми далекими от какого-либо понимания принципов работы цифровой электроники и программирования.