dxp

Вопрос такой: есть DHO4804, исправно работает кроме одного момента: при включении питания иногда нет "лучей" сигналов. И никакими действиями их добыть не получается. Только ребутом. Такое бывает не каждый раз, примерно в половите случаев. Не фатально, но изрядно анноит. Кто-нибудь сталкивался с подобным? Есть идеи, куда ковырять? Гуглением ничего не нашёл.

Конечно -- некомпетентность руководства в вопросах управления ко всему этому и приводит. В первую очередь -- к внедрению скрама. Потому как если бы руководство было управленчески состоятельно, оно бы выстроило эффективную иерархию управления, найдя, отобрав, поставив на ключевые позиции правильных людей, которые отрабатывают задачи на своём уровне иерархии так, как надо. Поскольку оно этого не смогло, а понимание, что как-то управлять надо, то тут привлекательно выглядит готовая методология. И скрам тут представлен лучше и ярче всех остальных -- реклама, продвижение: на этом немало народу кормится. Скрам-мастера. Это зачем они вообще нужны? Это люди, которые не обязаны быть специалистами в целевой тематике разработки, их задача -- организовывать процесс: проводить дейлики, планирования, ретры. Т.е. это по сути секретарь-стенографист на заседаниях. Дейлики. Зачем они нужны? Зачем обязательно собираться каждый день? Собираться надо по делу -- on demand. Надо если, то хоть три раза за день можно собраться, а не надо, так и неделями можно этим не страдать. Какие-то локальные вопросы люди, работающие совместно над задачей, решают оперативно сами на своём уровне, не отвлекая остальных. Более глобальные вопросы курирует руководитель работы, и если надо, собирает людей -- не всех, а только тех, кто нужен с его точки зрения -- на совещание/планёрку. Когда люди собираются по делу -- для решения возникшего вопроса, это собрание полезное и живое. А когда они собираются, потому что так положено по распорядку -- ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации. Продукт овнер. Он кто? Руководитель работы? Нет! Это типа заказчик или внутренний представитель заказчика. Он озвучивает (ставит) задачи -- в бэклог, а команда выбирает из бэклога те, что считает нужными делать в первую очередь. Команда решает! Да, команда, конечно, лучше знает, что надо делать в первую очередь. Вот прикольно было бы посмотреть, если на корабле команда бы решала, куда плыть, а не капитан. При этом продукт овнер -- не командир над командой (как заказчик не командир над разработчиками), поэтому прямого непосредственного влияния он не имеет. Он не может поручить конкретному человеку делать то или иное, он не может снять исполнителя с задачи и поручить её другому. Это понижает и без того ущербную управляемость. Все эти проблемы решены при правильно выстроенной иерархии управления. Скрам-мастера Секретари там не нужны. Митинги проводятся по необходимости и целевым образом. Вместо продукт овнера там руководитель (группы, работы и т.п.), который персонально отвечает перед вышестоящими уровнями иерархии за результат и облечён властью (т.е. реализуемой на практике способностью управлять) на своём уровне. Он организовывает рабочий процесс, следит за ходом его выполнения, оперативно реагирует на вводные. Всё это даёт реальную эффективность, а не мнимую, как в случае скрама. Потому что у ошибок и успехов есть имя, фамилия и отчество, сиречь, настоящая персональная ответственность, а не мнимая коллективная. И дело не в SCRUM vs Waterfall, а в грамотно выстроенной иерархии управления! Такая иерархия зарулит любой скрам по эффективности на раз. Главная проблема с ней состоит в том, что выстроить её сложно: это требует от управленца ума, опыта (жизненного и управленческого), множества хороших человеческих качеств (таких как настоящая (а не показная) уважительность к людям, мудрость, доброта, строгость-требовательность, дальновидность и справедливость) и умение разбираться в людях. Это редкие умения и это дано далеко не каждому. Такой человек -- это куда более ценный кадр, чем даже очень квалифицированный специалист в предметной области. К сожалению, большинство менеджеров не таковы. И из них ещё изрядный процент тщеславных мудаков, для которых на первом месте стоят личная слава и доходы, а не интересы дела. Такие "управленцы" (а их много -- они активно лезут наверх, к власти, которая для них кормушка и "тёплое место") в принципе не способны эффективно работать в иерархии управления, т.к. они будут решать в первую очередь свои личные карьерные задачи, а не отдаваться интересам дела. Выстраивать иерархию управления должен самый главный босс в организации -- это его прямая и нативная обязанность. От неё зависит вообще всё. Если он этого не может, то и этой системы управления тоже нет. Но управлять-то как-то надо. Вот и хватаются за готовые методологии. Но вместо реального управления там иллюзия оного. В мире софта это как-то едет, т.к. там процессы такие, что многие ошибки сглаживаются (и качество результата оценить сложно (например, если штукатур плохо сделал работу, это сразу видно по кривой стене, но по софту этого сразу не увидишь -- это надо поработать с ним, а т.к. его постоянно правят, то не понятно, какое его состояние надо оценивать), и исправлять ошибки дёшево -- почти бесплатно в том смысле, что не требуется ни затрат материалов, ни значительных временнЫх затрат, нет проблем с логистикой (отзывать бракованную продукцию и заменять её на исправленную) и т.п. В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР. И качество процесса определялось исключительно компетентностью кадров. Так было, так есть и сейчас. И так будет и дальше, ибо природа человека не меняется.

Только ценник на них ого-го. И в прежние-то времена оно под полтинник тянуло, а сейчас 100+ тыр. Готовы ради двух десятков контактов за это платить? Имхо, два десятка проще и дешевле купить обжатыми. А этот инструмент приобретать только если операции обжима требуются постоянно (периодически).

Тут ничего рассчитывать не нужно, нужно просто задать задержку, вносимую внешними цепями в пути данных. set_input_delay как бы говорит анализатору (STA), что, мол, там снаружи сигнал ещё задерживается на столько-то, поэтому у тебя вот бюджет таймингов уменьшается на эту величину. Например, если снаружи нет ничего, кроме проводников на плате, и их длина такая, что задержкой в них можно пренебречь, то следует указать значение ноль. Если есть какие-то ощутимые задержки, то их и указать. Особенно это касается случаев, когда данные, например, проходят через какой-то буфер, который вносит пару нс, причём, там ещё и разброс значений присутствует -- тогда для max и min будут разные значения.

Если речь про инструментарий, то Jira+Confluence+Gitlab.

Нет, скрам -- это методология ведения работы. А система следующий, более низкий уровень иерархии, система управления строится на основе методологии. Что не делает методологию системой. Конечно. Логистика, закупки, отлаженные производственные процессы -- да. Где всё более-менее предсказуемо и поддаётся адекватному прогнозированию. Но не в разработке нового. Серьёзно? 🙂 Ещё как даёт -- просто методы лодыри применяют другие. Например ИБД (имитация бурной деятельности). А в совокупности к хорошо подвешенным языком бездельник вообще может казаться самым деятельным -- скрам предоставляет как раз возможность демонстрировать (дейлики и прочие регулярные митинги). Не даёт лодырничать никакой не скрам. Вообще, никакая методология или система управления не решает сама по себе эту задачу. Её решает конкретный человек -- руководитель. Если он на своём месте, он прекрасно видит, кто что стоит, кто чем занимается, где есть толк, а где пустота (имитация). Потому что принцип "Кадры решают всё!" применим не только к исполнителям, но и (в первую очередь!) к руководителям. Управление -- живой процесс. И всё зависит от квалификации, умений, опыта и адекватности человека, который осуществляет это управление. Никаких других вариантов нет. Полагать, что скрам что-то там кому-то не даёт или наоборот обеспечивает результат -- есть вредная иллюзия. Далее по пунктам. Ещё одна иллюзия. То, что скрам-методология предполагает ежедневные митинги наряду с планированием спринтов и ретрами, никакой вовлечённости не повышает и не обеспечивает: сидят люди на митинге, слушают бубнение очередного выступающего, ждут своей очереди отчитаться и того, когда это бесполезное и бессмысленное мероприятие закончится. Только и всего. Много раз лично участвовал в этих митингах и наблюдал оную картину. Вовлечённость в проект может поднять тот же самый человек, который руководит процессом, применяя три рычага (это известная тема из психологии): поднять интерес подчинённого сотрудника-коллеги, правильно выбирая для него задачи -- далеко не все задачи интересны всем, поэтому тут надо внимательно и чутко подходить. Будет интерес -- будет результат. Интерес -- это самый главный мотиватор; помочь с пониманием трудных моментов (сам или привлекая других, более квалифицированных в вопросе людей). Когда человек имеет хорошее понимание того, что он делает, это тоже прилично мотивирует (повышает вовлечённость), позволяет работать эффективнее, что поощряет исполнителя, который видит позитивный результат своей работы; довести важность дела до сотрудника-коллеги: нужность результата, ответственность перед заказчиком, уважение товарищей и т.п. Всё это -- живая работа с людьми. Только она и даёт результат. А пустая говорильня на дейликах -- просто трата времени и сил. За счёт чего? Что такого уникального даёт скрам для этого? Что собрались и поговорили? Ну, собрались и поговорили. Наговорились, устали, ничего не решили -- это сколько угодно. Даже более того -- это обычный результат, когда толпа пытается что-то решить. "Лебедь, рак и щука". И эта говорильня продолжается из раза в раз без всякого результата. Решение менять курс (адаптироваться) должен принимать тот, кто отвечает за результат. Его ответственность, его и решение. Как правило, это тот же самый руководитель работы. Он может собрать людей, спросить их экспертное мнение, выслушать каждого, и на основании этого, а также своего опыта и знания своих людей (к чьему мнению в какой ситуации нужно прислушиваться больше, а чьё умножать на 0.1) принять решение, за результат которого ему потом отвечать. Никакие общие собрания и пустопорожная болтовня на них не нужны. Соблюдение сроков обеспечивается грамотным разбиением работы на этапы и контролем выполнения работы по этим этапам. А коллективная ответственность -- это миф! За исключением крайних случаев: типа, все мегасознательные и ответственные как главный герой из советского фильма "Коммунист", или когда в случае неуспеха всех расстреляют (лишат премии, уволят и т.п.). Во всех других случаях коллективная ответственность проявляет себя как коллективная безответственность. Всегда в группе (статистически) находятся раздолбаи, тормоза, рукожопы, эгоисты-индивидуалисты и т.п. И без присмотра и персональной ответственности всё это приводит к тому, что результат провальный, с спросить не с кого. Итого, опять всё сводится к компетенции и квалификации управляющего процессом конкретного человека. Работает только в случае простых задач. Проходили не раз. Когда задачи сложные, требующие серьёзного вникания, всё это не работает от слова совсем. Пример из реальности: пилим командой ПЛИСовый проект, я занимаюсь PCIe DMA (на TLP), а коллега -- поиск паттернов в потоке сетевого трафика. У нас задачи не пересекаются вообще никак! И каждая из них требует глубокого погружения. В итоге, все скучают, когда я что-то бубню запросы чтения памяти хоста, проблемы негарантированного порядка прихода CplD от разных запросов, про кредиты non-posted запросов и подобное, а когда коллега говорит про свою работу, я из его рассказов понимаю только, что у него там какие-то блум-фильтры, перфектные таблицы кукбука и ещё какая-то хрень, названия которой я не запомнил. Чтобы мне понимать, о чём он говорит, мне нужно серьёзно погружаться в тематику его работы, но я не могу этого делать -- у меня своей выше крыши. И у него ровно та же ситуация. И у всех в группе. Получается, что все сидят и тупо ждут, чтобы отчитаться, и когда это пустое мероприятие закончится. Скрам-мастер не понимает вообще ничего из того, что там говорят, т.к. он не специалист ни в ПЛИС, ни в тематике проекта. Ну, по скраму он и не должен. Его задача -- быть секретарём заседания. И вот в итоге проектом занимается 8 человек, но задачи у всех перпендикулярные, какие-то общие места есть только на стыковках, а это очень небольшая часть проекта. В итоге, на общие темы мы можем поговорить только про какое-нить CDC FIFO, проблемы с STA, нюансами использования общего инструментария (симулятор, синтезатор и т.п.) и другими общими вопросами, которые к непосредственно проекту имеют опосредованное отношение. Итого, эффективно задачи решаются при правильно организованной иерархии управления, когда все люди -- и специалисты, и руководители (от крупных до тимлидов) на своих местах. Иерархия -- это естественный способ решения сложности в человеческой коллективной деятельности.. Да, тут важно не скатиться в раздувание иерархии на пустом месте, не допустить возникновения и роста бюрократии и формализации. Поддерживать процесс живым -- это достигается только правильным подбором кадров и никак иначе. Скрам же тут не помогает совсем никак. А мешает изрядно. Он размывает ответственность, распыляет цели, место чётко выверенного курса получается "рыскание". На локальном уровне хорошо работает самоорганизация, когда подбираются (или подбирают) люди ответственные, мотивированные, знающие и умеющие -- она сами между собой наладят и взаимодействие, и рабочий процесс. Но это происходит самодвижущимся образом у них без всяких скрамов. Скрам и тут только мешает, пытаясь формализовать этот естественно сложившийся процесс. Когда задача совсем новая и непонятная, то, конечно, никакого внятного ТЗ быть не может. Поэтому ведётся предварительная работа -- например, как вы правильно назвали, выполняется НИР. А потом при выполнении ОКР ещё эскизный проект (ЭП), на входе которого присутствует проект ТЗ, и цель ЭП -- создать технический облик объекта разработки и разработать уже нормальное ТЗ, с которым можно смело идти в технический проект (ТП), коий уже и есть собственно разработка. Где тут рулящая роль скрама? Да без него это сто лет делалось и делается. Он сюда вообще не вписывается. Что же касается корректировки ТЗ по ходу дела, то и это возможно, но не так огульно как это делается со скрамом. Если заказчик предлагает (просит) что-то поменять, это рассматривается, и если принимается, то выпускается специальные документ: дополнение к ТЗ. Все эти доп. хотелки отражаются там. И всегда видно, что было исходно, а что изменилось по ходу дела. Отдельный документ позволяет хорошо видеть, сколько чего, когда и как изменилось. И это позволяет эффективно пресекать излишнюю тягу заказчика к фантазиям . При разработке софта эти изменения реализуются ещё как-то более-менее безболезненно. При разработке железа -- это как правило боль, и часто оказывается неприемлемым. Иначе разработка затягивается на годы. Это проблема, когда софтовая контора берётся делать железо: тематика и средства радикально другие, а подходы те же самые. Я работал в софтовой IT комании, которая взялась разрабатывать железо (для себя, для своего продукта), в итоге 6 лет хардварному отделу, объём работы проделан колоссальный, сами разработки технически очень достойные (специалисты высокого уровня там трудятся -- контора может себе таких позволить), но в серии и у клиентов по истечении этого срока нет ни одного из полудюжины разрабатываемых изделий. Это происходит именно по причине постоянных корректировок хотелок, отрицания ТЗ как такового, отсутствия этапности в работе, зато есть скрам во всей его красе с коллективной ответственностью безответственностью и прочим. Да и странно предъявлять ответственность исполнителям, если от них тут мало что зависит -- каждый из них на своём месте свою работу сделал хорошо. Подводя итог Скрам, возможно, неплохо себя проявляет при разработке, например, веб-приложений, когда результат работы можно сразу предъявить, и заказчик видит его, может попросить что-то поменять или откорректировать -- вот тут спринты, как контрольные точки, помогают. Но когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП занимает по полгода, какие нафиг спринты?! То же самое и с ПЛИС: тот же PCIe DMA я пилил несколько месяцев, и эта работа почти никак не пересекалась с другими -- она несмотря на известную сложность, является локальной, законченной в себе -- ни вводные никакие снаружи тут не нужны, ни результат показать в конце спринта невозможно (вряд ли кому будет интересно смотреть на очередной добавившийся тест того или иного модуля). По итогу пристального наблюдения за этой темой и невольного участия в ней, для себя я сделал следующий вывод: скрам -- это вредная иллюзия управляемости процесса, которая проникла глубоко в сфере IT. Секрет успеха этого внедрения состоит из двух частей: Потребность руководства IT компаний в инструментах управления, которые оное руководство само создать не смогло, но тут ему предложили готовое "решение". Агрессивная реклама этой методологии со стороны консалтинговых агентств и лавок вроде AgileLab, желающих рубить немалые деньги на некомпетентности, доверчивости и легковерности руководителей IT контор. Ну, почему руководители контор ведутся на это -- это Даннинг-Крюгер в полный рост: уровень управленческой компетентности не позволяет ни организовать процесс эффективно, ни понять, что предлагаемое тоже не решение. Процесс разработки и продвижения софта сам по себе прощает многие косяки -- цена ошибки невелика, стоимость производства ноль, сроки производства -- тоже почти нулевые (сколько на пересборку требуется), возможность отлаживаться на клиентах и т.п. Всего этого нет в теме разработки железа, там всё эти ошибки стоят дорого. Поэтому там этот подход не работает совсем. Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

"Огласите весь список, пожалуйста" © Что вы понимаете под "системами управления проектами в электронике"? Какие знаете? Если что, то SCRUM -- это не система управления проектами вообще и уж точно не в электронике. Система управления проектами -- это, например, Redmine. Альтернативная связка Jira+Confluence. Хотя я бы не назвал это именно "системой" управления, это просто багтрекер + вики.

Ну, надо всё же чтобы прогон подольше был, а то тут уже начинает влияет время загрузки тулов. Вивада сама по себе тормозная, она запускается долго. За это время Gowin уже успеет всё собрать и закончить. 🙂 Надо подобрать так, чтобы время сборки занимало хотя бы минут 5.

Прогон для Vivado 2023.1.2: Конфигурация PC: AMD Ryzen 9 7900X, DDR5 2x32GB (на частоте 5200 МГц), MB на чипсете B650, NMVe (1000 ГБ SSD M.2 Samsung 970 EVO Plus). Время что-то очень коротким вышло -- либо проект простой (для современного железа), либо, может, сделал что-то не так. Но просто открыл проект вивадой, она предложила конвертнуть в нынешний формат, я согласился. Дальше пнул сборку и всё.

Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 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 процессор влёт. Тут как обычно вопросы разумной достаточности и цены вопроса.

Ну, так это ж application процессор. Он быстрый, но неповоротливый, прерывания для него -- дорогая штука. Основные задержки, полагаю, там в контроллере прерываний GIC: толстая штука с поддержкой 1000+ источников прерываний. С такими процами просто и подход исходно другой: они применяются обычно как управляющее ядро SoC, а SoC -- это система, состоящая из достаточно самостоятельных устройств, обладающих приличной "автономностью", т.е. способных без вмешательства процессора выполнять сложные цепочки операций. Процессор там в основном участвует для настройки аппаратуры, мониторинга процесса работы и корректировки, ну, и конечно, для организации интерфейса пользователя (хоть CLI, хоть GUI, хоть веб-интерфейс). Ну, и поскольку системы сложные, устройства непростые, там потенциально возможно большое количество прерываний, что налагает требования на контроллер прерываний. С другой стороны, поскольку устройства достаточно "самостоятельные", метаться по прерываниям на каждый чих не нужно. Вот и причина, почему такой сдвиг акцента: количество разменивается на скорость. Но при таких "неприятных" значениях задержки на практике всё не так печально -- абсолютное-то время всё равно получается вполне приемлемым за счёт высокой частоты. Я сам озабочен подобными описанным вами вопросами -- предсказуемость времени реакции. Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть), и это уровень L2, т.е. при промахе кэша L1 дальше этого уровня запрос не пойдёт (в отличие от случая, когда программа в SDRAM -- там возможен промах L2 кэша, дальше задержка обращения в SDRAM, в которой пасётся много кто -- та же FPGA часть -- в общем, тут задержка вместо нескольких тактов до OCM может вырасти до пары тыщ (видел отчёт несколько лет назад в Сети). Но baremetal на application процессорах -- это то ещё "удовольствие". В основном это касается, конечно, запуска, потом-то всё вполне обычно. Но старт весьма нетривиален.