dxp

Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 100%. ТЗ -- это отправная точка в разработке. Из него формируются этапы работы. Если через месяц выясняется, что ТЗ не про то, что надо, разработчика ТЗ (или того, кто ему задачу ставил) гнать за профнепригодность. Меняет и дополняет по ходу дела?!!! Серьёзно?! Вот это и корень проблем при использовании IT'шных подходов в разработке железа! Это в софте можно быстро перех..якать, с железом это не прокатывает. Да и с софтом эта практика порочна и является источником массы проблем, просто там последствия ощущаются не так больно. Вместо того, чтобы сразу подумать и спланировать процесс, там доминирует метод "х.як, х..як и в продакшн". Единственный сценарий, где такое оправдано -- это когда задача (что нужно конкретно сделать) недостаточно ясна на старте, и пока не начнёшь, невозможно понять, как конкретно это надо сделать. Поэтому применяется этот метод "тыка" -- сделали что-то, увидели, то или не то. Тут, конечно, нужно всем участвовать -- и заказчику, и разработчику, и периодичность этих контрольных точек должна быть достаточно короткой (1-4 недели) -- те самые спринты. Это как-то работает при разработке софта, но с железом это полный провал. Там нужно всё заранее тщательно проектировать и планировать, потому что перефигачить по ходу дела не получится, т.к. стоимость производства в отличие от софта далеко не ноль. Что знают? Что мешает это знать без скрама? А нужно ли всем участникам это знать? Не будет ли это "знание" отвлекать их от своей конкретной и сложной работы? Это нужно знать всем участникам команды? Зачем? Об этом нужно знать тем, кто к этому причастен. Это узнаётся адресно без всяких скрамов. При правильной организации работы есть её руководитель, который всё аспекты курирует (или назначает ответственных, если задач много). И для этого скрам нужен? А как же без него-то обходились десятки лет и продолжают обходиться? Когда приступать к выпуску КД -- очевидно на этапе РКД. Ну да, тут никак не обойтись без планирования спринта, дейликов, ретры. Ведь все разработчики должны быть в курсе, когда же надо отдать корпус в покраску. И уж стопроцентно это должны знать скрам-мастер и продукт овнер. Ну, если потеря кучи времени и отвлечение на посторонние процессы, зачастую искусственные и бесполезные, как натягивание работы на сторипоинты, никого не расстраивает, то пожалуй поверю. 🙂 Ну, о чём и речь -- годится только для простых и понятных задач, которые ясно, как делать, можно достоверно спрогнозировать трудозатраты и т.п. Словом -- не про разработку. Логистика, снабжение, какие-то уже более-менее отлаженные производственные процессы, когда есть опыт, на который можно опереться. В разработке нового такого опыта как правило нет, поэтому всё это скрам-планирование идёт лесом. Ну, удачи вам

Прошу прощения за офтопик, но вот это вот зачем при разработке железа? Это же как-то годится только для очень простых процессов и при разработке вебсайтов, когда нужна постоянная обратная связь с заказчиком/потребителем -- "курс" работы на спринтах и корректируется. При разработке железа нужен свосем другой flow: ТЗ, ведомость исполнения (план-график, роадмап и т.п.), этапность. SCRUM тут вообще не ложится никак и является только помехой. P.S. Если тема интересна и есть желающие обсудить/высказаться, то может имеет смысл создать отдельную тему.

А через JTAG подрубиться не пробовали? Там, вроде, есть режим, когда можно дебаг-сессию поднять, подключившись к уже загруженной в программе. Сам не пробовал такое.

Цель -- иметь сравнительную проверку РС железа, поэтому проект нужен один с конкретными настройками. Ровно так было с прошлым тестом. Вполне адекватно показывал производительность железа. BRAM, DSP, PCIe, etc -- это ещё одна "координата": эти аппаратные блоки имеют жёсткое расположение внутри FPGA, что даёт новые вводные для инструментария. В реальных проектах всё это как правило есть, поэтому для адекватности теста такие элементы тоже нужны. И никакая кроссплатформенность тут не нужна. Если хочется иметь тест, который можно собрать на любом тулчейне (Vivado, Quartus, PDS, Gowin и т.д.), то это должен быть совсем другой проект, и показывать он будет тоже нечто другое -- скорее производительность тулчейна, а не эффективность РС железа. Такой тест не должен иметь ничего, кроме логики и регистров. Ну, и на PnR всё равно будут проблемы с констрейнами по распределению пинов. Т.ч. по-любому придётся делать портирование. Моё мнение, такой тест достаточно бесполезен в отличие от предлагаемого варианта по тестированию производительности РС железа. IP ядра -- это блоки, которые могут собираться параллельно, это даёт преимущество многоядерным процам, это хороший тест на эффективность работы с памятью и кэшами в одновременном многоядерном нагруженном доступе. IP ядер в проекте может быть немало (десятки), и их сборка (создание и синтез) занимают время обычно побольше, чем синтез самого проекта. И это хороший способ разгрузить синтез, т.к. IP ядра обычно собираются в OOC режиме.

Помнится, было дело тут на форуме: кто-то скидал простой, но затратный на сборке проект под Quartus (как бы не для Cyclone II), и все желающие могли собрать его на своём железе и выложить результаты -- была какая-то более-менее объективная оценка эффективности сборочной машины. Может тоже так же сделать: скидать проект под Vivado, например, на Artix7-200, и выложить, чтобы все желающие могли попробовать и доложить какие-то более-менее объективные результаты? Показать: конфигурация РС, время сборки в формате: IP ядра. Синтез. P&R. Общее время. Вот только состав проекта надо подобрать, чтобы там не было перекосов, чтобы все компоненты равномерно задейстовались: комбинационная логика, флопы, блочная память, IP ядра (как минимум PLL, а ещё, может PCIe), DSP блоки (но без фанатизма). Может есть что-то готовое на примете? Думается, такое было бы и интересно многим, и полезно.

Да, так стала светлая тема, намного юзабельнее. Спасибо вам большое!

Xubuntu 22.04. P.S. Полагал, что это жаба-решение насквозь кроссплатформенное, иначе на кой оно.

Всем привет! Какое-то время назад доводилось работать с Xilinx SDK. Потом была пауза в несколько лет, и вот сейчас опять возникла такая необходимость, но вот SDK канул в лету, и теперь вместо него Vitis. Ну, в целом вроде то же самое - эклипсообразная хрень, но сразу же столкнулся с неприятной неожиданностью: если раньше там (SDK) была традиционная светлая тема, которая, может, не слишком красивая, но вполне функциональная -- во всяком случае, всё хорошо читаемо, но теперь это просто... я не знаю, как это назвать. Оно стало тёмно-тёмно серым (щас такая мода пошла -- многие софты в этот мышиный цвет красят), и ладно бы, если бы не некоторые "но". А именно: на этом фоне содержимое отдельных окон или плохо читаемо, или вообще нечитаемо! Вот сразу с ходу при загрузке: Прочитать этот мутно-синий текст можно, только выделив (тогда контрастно)! Такая же история, например, с окном дизассемблера -- тоже такой же блёкло-синий на фоне мышиного. Ковырял настройки нашел про цвета, но там в основном настройки цветом элементов интерфейса, подсветка синтаксиса и подобное. Можно поменять фон отдельных окон, от этого вид ещё ужаснее -- некоторые окна с белым фоном, некоторые -- вот такие, тёмно-серые. Изменить цвет шрифта этих окон и окна дизассемблера не смог. Погуглил про темы (скины), вроде нашёл какое-то описание что-то там установить в виде плагина через некий marketplace, но интерфейс плагинов в Vitis или отключен (так было сказано по одной из ссылок -- и есть основания этому верить, т.к. длительные попытки найти возможность что-то установить через этот самый маркетплейс, не увенчались успехом), либо унесён куда-то в непонятное место. В общем, у меня два вопроса: 1. Риторический, к авторам этой поделки: они сами-то пробовали этим пользоваться? 2. Практический: кто как обходит эту неприятность? есть ли способы?

А PLL'ки те же? Умеете как-то без IP ядер это описать? Аппаратные блоки ПЛИС далеко не все инферятся из кода, я знаю только про память и про DSP блоки. Т.ч. без корок далеко не уехать. Корки -- это ж по сути библиотечные модули. Более-менее заметный по размерам проект вряд ли обойдётся без них.

То, что она лёгкая и поэтому быстрая (да ещё и написана видимо на Qt в отличие от жабы у Vivado), это понятно и приятно. Но позволяет ли она собрать проект из командной строки полностью. Имеется в виду не только синтез и PnR, но и сборка всех IP ядер. Например, поменялся какой-то базовый параметр в проекте, который влияет на тактовые частоты и/или ширину шины, из-за этого надо перегенерить корки. На той же Vivado, к примеру, это делается спокойно штатными средствами, т.к. там все операции можно тиклевыми командами выполнять, поэтому такая автоматизация -- дело техники. Quartus, насколько помню, тоже так позволяет делать, хотя там местами мутновато. А вот в Gowin IDE я не нашёл, как корки собирать из командной строки -- только через GUI. И это для меня жирнейший минус. Это просто закрывает возможность автоматических сборок (прощай CI/CD), и вообще без такой возможности работать очень неудобно -- любое изменение базового (уровня проекта) параметра требует отслеживать его влияние вручную.

САПР их тоже больше Quartus'а нравится?

А частота сети от 50 Гц не в такой же пропорции отличается? Хотя многовато, конечно. Осциллографом посмотреть, что с оптрона летит, есть возможность?

Падение 0.12 при токе 0.5А -- это характеристика силового элемента этого стабилизатора - т.е. то, что он может обеспечить, а не всей схемы. При питании 3.6В и падении на светодиоде 3 В остальные 0.6В рассеятся на внешних элементах. Итого, 0.5*0.6 = 0.3 Вт. Если питание будет выше, потери на тепло будут больше. А 0.12 падения на стабилизаторе говорит только о том, что он способен обеспечить 0.5А и выдать в нагрузку 3В при питании 3.12В. Если вам КПД и тепловыделение не препятствуют, то это другое дело. Но линейным силовым схемам по КПД тяжело тягаться с импульсными. У линейных есть другие преимущества.

Как сказать. Пара-тройка сотен DSP блоков в FPGA на типовых ЦОС операциях типа свёртки уделают практически любой DSP процессор влёт. Тут как обычно вопросы разумной достаточности и цены вопроса.