dxp

LT3042 разве не обеспечит такое? Вполне укладывается в 5 В, 100 мА. Нужно только без грубых ошибок спроектировать -- первичное питание сделать почище, конструкцию грамотно сделать.

Порядок файлов задаёт пользователь. Если IP ядра Out-Of-Context, то они вообще сами по себе все собираются, не пересекаются. А на остальные клок подаётся снаружи. А он уже переименован. Впрочем, не настаиваю, нечасто это использовал, может какие-то трудности имеют место быть.

Переименование -- это именно переименование, а не введение псевдонима. Если клок уже использовался, то его нельзя переименовать, т.к. имя клока (идентификатор) должно быть уникальным, а если переименовать уже используемый, то получается уже как минимум два идентификатора. А псевдонимы для этого он не поддерживает. Технически нужно просто сразу его первым делом переименовать и далее ссылаться только на этот имя клока. Про внутренние xdc не понял, они тут при чём? Вот создали клок с помощью MMCM/PLL, переименовали его, используем. Я пользовался, не помню проблем.

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

Во-первых, у вас create_generated_clock закомментарено, я не догадался, что это вы тоже запускали. Во-вторых, там есть -divide_by 1 а это в констрейне переименования не допускается. В констрейне переименования не должно быть никаких опций. Только имя и источник. Всё. Это, насколько помню, документировано.

Да, с помощью create_generated_clock: create_generated_clock -name <new clock name> [get_pins <path-to-source-pin>] Типа: create_generated_clock -name sys_clk_100M [get_pins inst_mmcm/mmcm_adv_inst/CLKOUT0] Вроде так.

Уже давно было, подазабыл многое. Насколько помню, там как раз передача кредитной информации осуществляется на канальном уровне -- DLLP (Data Link Layer Packet) летают. Кстати, на этом же уровне и гаратния доставки организована -- ACK/NACK пакеты. Кредитных политик там много -- под реализацию обычно выбирается. Например, если я хочу иметь максимальную скорость (мне именно так надо было), я при запросе данных с хоста должен гарантировать приём этого трафика (там это реализуемо, т.к. ПЛИС успевает весь трафик прожевать в реальном времени). Если какие-то иные сценарии, то уже и поведение кода соответствующее. И даже выделение ресурсов -- сколько памяти выделять под заголовочные кредиты, сколько под данные (там они разделены). Кроме того, там разные кредитные буферы для posted и non-posted запросов. Доставкой кредитов занимается аппаратура блока PCIe, пользовательская логика уже видит их значения. У вас тут совершенно другой контекст, вряд ли реализация PCIe тут может пригодиться.

Существенно. Но тогда, если там битовая упаковка, можно выделять не байт, а пару бит. 🙂 Которые будут индицировать, сколько на приёмнике -- пустой, половина, четверть, полный. Или даже 1 бит -- по типу, как в аппаратных FIFO есть сигналs almost_full/almost_empty, которые встают по, когда количество данных пересекает заданный порог. Например, флаг имеет значение 1, соответсвенно, можно без опасения послать энное количество байт. Ну, а с другой стороны, если так напряжно по трафику, слать кредиты тоже ведь накладные. Да, их можно не в каждом пакете передавать, но тут тоже компромисс: редко передавать -- контекст устаревает, часто -- трафик растёт.

Вообще, имхо, на канальном уровне было бы самое то сообщать о возможности приёма. Ну, не вообще на канальном, а на уровне, где гарантия доставки организуется. В том же TCP (хотя это транспортный, L4) тоже это делается -- и гарантия доставки, и инфа о возможности приёма (Window Scaling, вроде, называется). Нужто 1 байт в заголовке так сильно может попортить картину? Какой процент накладных это получается? Там из-за повторов при потерях данных избыточный трафик наверное побольше будет. Приниципиальным препятствием тут является, например, то, что реализация стороняя, не ваша, а вам только API. А если ваша, то, имхо, вполне вариант.

Эффективность реализации сильно зависит от протокола передачи данных. Например, если в обратную сторону передаётся (условно) в 10 раз меньше данных, то можно просто присылать значение доступного размера. Если трафик в обе стороны плотный, то значение кредита просится встроить прямо в заголовок пакета (если там пакеты). Это называется piggybacking -- всего один байт, например, накладных, не должен сильно испортить картину. И передающая сторона всегда отправляет количество данных не более того, которое ей сообщает приёмная сторона. Это хорошо работает, когда трафик идёт регулярно в обе стороны. Но даже если в одну сторону трафика нет, то канал пустой, можно слать регулярно пустые пакеты (к примеру, на каждый принятый) только с заголовком ради передачи размера. В общем, тут много всяких trade-off, автору виднее, какой подход лучше.

Да, они нашли компонент, который имеет запас по температуре, протестировали его. И взяли ответственность за отказы на себя. Риски включили в стоимость оборудования. Производителю МК они бы ничего предъявить не смогли в случае чего, все возможные проблемы взяли на себя. Наверное, это было оправдано в этом конкретном контексте.

Но это всё равно не снимает ответственности с разработчика -- как только использование элемента не в режиме, ответственность сразу переходит на разработчика. Да, входное тестирование -- это правильный подход в этом случае, но его объём и корректность являются отдельными вопросами. Иногда без этого не обойтись, но по возможности лучше избегать такой практики. К тому же, кто даст гарантию, что даже прошедший испытания компонент через какое-то время не откажет? Входной контроль -- это проверка в моменте, а надёжность на протяжении срока эксплуатации этим не проверить. Поэтому это опять на свой страх и риск.

Этот термин означает, что прибор включен и работает. Правильно ли он при этом работает, именно этой фразой не оговаривается. То, что этот пункт находится в разделе Absolute Maximum Ratings, означает, что это температура, при которой прибор не выйдет из строя необратимо. Ровно то же самое относится и к другим параметрам в этом разделе -- повышенное напряжение питания -- предельное -- при котором не произойдёт выход из строя, но работать прибор может при этом неправильно или вообще не работать. Нет. Storage Temperature -- это предельная температура, куда прибор можно помещать вообще, а Operating Temperature -- это при которой его можно включать. Т.е. до -65 прибор можно морозить, но если его включить, то он может сломаться -- корпус треснет, например, Вот вы сами верно ответили: прибор можно включить, он не погибнет, но работоспособность не гарантирована, прибор не в режиме, любые отказы в этом случае переходят на ответственность разработчика, который нарушил условия. Многие микросхемы вполне исправно работают при превышении параметров, но нет никаких гарантий, что завтра будет партия, которая не будет исправно работать. Для серийных промышленных изделий такое неприемлемо, только для макетов и частных поделок, где ответственность не важна.

-55 там -- это не рабочая температура, а такая, при которой МК необратимо не выйдет из строя, никакой работоспособности при этом не гарантируется. Рабочая температура -- т.е. при которой гарантируется правильная работа микросхемы, там именно -40.

MMU даёт защищённый режим работы памяти -- во-первых, изоляцию процессов друг от друга, во-вторых, каждый процесс (приложение) получает линейное адресное пространство. Когда имеете дело с RTOS, которая тоже многозадачная, то там все задачи (процессы) крутятся в едином адресном пространстве, и любая ошибка (прострел памяти) в одной задаче заваливает всё тему на раз. Но там весь код ваш, вы это можете контролировать, а в случае большой ОС, как линух, там запускается куча стороннего кода, корректность работы которого вы не можете контролировать, и любая утилита завалит ваш дивайс без вашего разрешения и контроля. Ну, и MMU позволяет радикально снизить проблемы из-за фрагментации памяти при работе со свободной памятью, а на больших ОС это обычное дело. Поэтому совершенно согласен, что для работы линуха нужно MMU, без него это баловство -- очень ограниченное применение, как делали с Blackfin'ами, которые ставили в медиапроигрыватели -- по сути делали закрытую сборку для дивайса, uCLinux там был нужен, чтобы можно было использовать библиотеки кодеков и проигрывателей, которые уже существовали.

Такое нужно, если переносите между компами, где разные ОС -- например, в венды на линух. А если ОС одинаковая, то ничо делать не надо -- запаковал, архив перекинул, распаковал. Там рядом с версией программы лежит директория profile, в которой директории по ному версии, где все настройки. Вот всё вместе (заглавная директория с программой архивируется) и переносится. Только так и таскаю, забыл уже, когда делал экспорт (вроде чисто для бекапа только). Шрифты, конечно, нужно установить, если они нужны и их нет в целевой ОС. VSCode как-то шупал, не зашло. Не понравился, как раз, подход с настройками -- длиннющая портянка, как в ней быстро ориентироваться. Может, избалован сликом, где всё структурировано и в иерархии. Не понравилось, что нет никаких контролов для сохранения/отмены правок в настройках -- как на телефоне: изменил опцию, всё, никаких Ok/Cancel нету. В телефоне, может, это и нормально, а в программе для десктопа нет. Хипстерский подход. Ещё я не люблю, когда при перемещении курсора в вертикальном направлении (Up/Down стрелки на клаве) он прыгает-скачет влево-вправо, потому что отрабатывает по концам строк, а у пустых строк конец в позиции 1. Это мельтешение отвлекает и занимает какой-то ресурс внимания на слежение за курсором. В слике есть опция Virtual Space, если её включить, то редактор как бы добавляет несуществующие пробелы, и курсор движется по вертикали ровно в той колонке, в которой был исходно. В VSCode я такой фичи не нашёл, нагуглил, что он сам не умеет, надо плагины, накатил какой-то, он не работал. На этом я сломался и снёс программу.

Да, у меня линукс, не знаю, подходит ли под виндовую версию.

Почему же не обновляется? Вон уже v30 лежит от 25-го года. Есть под все платформы, попасть можно отсюда: https://www.slickedit.com/downloads Вопрос в лекарстве, подойдёт ли от предыдущих версий. Сам сижу на v28, это от 23 года.

Т.е. вы говорите профессионалу: "Ты фигню говоришь", и он тут же "Ты совершенно прав!" и начинает нести противоположное, вы ему: "Опять лажа", а он: "Извини, был не прав!". Т.е. вот на такую аргументацию профессионалы на лету меняют мнение? Хороши профессионалы, бгг.

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

Только люди обычно и профессионалы в особенности в подобных ситуациях не переобуваются в воздухе в отличие от. 🙂

В ембеддед проектах постоянно это держу в поле зрения. Для хоста не так жёстко, но тоже постоянно держу под контролем, во что выливается та или иная конструкция. А на SV для RTL вообще без этого никак! Нет, не так. На том же Python вместо выразительных операций конкатенации через сложение использую append для списков и f-нотацию для строк, поэтому что это эффективнее. А главное, я понимаю, что будет в обоих случаях и действую зряче. А с LLM получается игра вслепую -- оно чёрный ящик, вы не знаете, что там происходит внутри и что оно конкретно выдаст. Это сколько угодно, но это и близко не погружение в алгоритмику предметной области в отличие от работы непосредственно с ЯП и компилятором, поэтому аналогия тут совершенно мимо.

Я ждал подобного вопроса. Аналогия, имхо, не уместна: компилятор работает по чётким правилам и просто транслирует код с одного языка на другой, пусть меняя уровень детализации и абстракции. Когда пишешь код хоть на С++, хоть на SystemVerilog, да хоть на Python, в голове всё равно крутится в фоне собственный "компилятор", который выдаёт мне оценку той или иной конструкции -- я примерно понимаю, во что это выльется, поэтому глубоко погружён в алгоритм и процесс мышления, с этим связанный. А с LLM подход совсем другой -- ты ей промпт, она тебе код. И хорошо, если ты взял этот код, изучил, перелопатил и вставил к себе в проект после такого чекинга и правок -- по сути это уже твой код, который ты получил пусть из некой "рыбы". Но ведь с агентами работают не так -- недавно читал статью на хабре, где автор с восторгом рассказывал, как он скомандовал агенту написать ему код климат-контроля для какой-то платки на STM32, и тот за 2 часа справился -- де, вот выставляет температуру, и плата отрабатывает (регуляторы там и всё прочее. А у меня возник мысленный риторический вопрос к автору: а сам-то ты что в этом понимаешь? Скомандовал машине, она сделала. Ну, так какая ценность в таких командирах? Прям напоминает сюжет отличного американского фильма "Идиократия". Когда человек выдаёт промпт, он зачастую и близко не знает про реализацию, никакой "компилятор" "LLM" у него в голове параллельно не работает. Когда имеешь дело с компилятором, знаешь об основных механизмах его работы, многих оптимизациях, инструмент работает предсказуемо. Нейросети же эти -- чёрные ящики даже для их создателей, никто толком не знает, как оно внутри работает. Это источник непредсказуемостей (с которыми борются путём замыкания контуров внешнего контроля) и глюков. Поэтому взаимоотношения человека и машины в интеллектуально-алгоритмическом смысле в случае с компилятором (даже таким сложным, как компилятор С++) и LLM различаются радикально. Аналогия не уместна! Человек -- существо ленивое от природы. И его мозг -- это самый ленивый орган. Если можно не думать, он не будет думать. Только человек своей волей может заставить тело двигаться, а мозг думать (за исключением случаев, когда это заставляет делать жизнь). Есть осознанные, волевые люди, но большинство не таково. И вот эта тема с LLM -- это ловушка для абсолютного большинства. С этой технологией надо быть очень осторожным и осмотрительным, чтобы не стать её рабом и придатком. Это после паузы -- тут основным является процесс вспоминания. А если несколько лет ездить верхом на агентах и достичь реально дзена в промптописании, то это знание/умение вытеснит прежние знания и навыки -- вспоминать будет нечего. Кроме того, технологии развиваются -- я вот несколько лет не использовал С++ (на FPGA проектах сидел), потом, когда нужно было вернуться к теме, обнаружил, что это во многом не тот язык, который я знал, и далее был тяжёлый процесс освоения -- весь прежний опыт и знания тут мало помогли. Тут тоже есть мутный момент. Сейчас он есть. Но будет ли завтра? Сегодня все сидят на американских и китайских моделях и агентах. Не факт, что завтра они будут доступны -- мир маргинализируется, происходит отсечение информационных потоков. Даже сегодня в РФ чтобы использовать платные модели, нужно обращаться к посредникам, а завтра это всё может быть заблокировано как ютуб и телеграм -- предложат вместо клодов, гроков и дипсиков юзать яндекс и сбер. Вне сомнений, это будет лютый провал по уровню качества моделей, во многих случаях он будет неприемлем для поддержания текущего уровня. Помимо геополитических рисков, есть ещё чисто экономический: вся эта тема ИИ -- это мощно надутый пузырь. Туда ввалили такие деньги, что они вряд ли когда-нибудь отобьются. Ажиотаж пройдёт, инвесторы захотят отдачи, которой не будет. Это приведёт к сильному оттоку средств от этой темы со всеми вытекающими.

Синьор тем не менее тоже пишет код и делает это достаточно много. Набор кода собственными руками является важнейшей частью работы -- тонкая моторика пальцев напрямую связана с процессами мышления в головном мозге. Попробуйте вообще перестать набирать код -- через какое-то время заметите, что процесс думания в голове тоже изменился, стал каким-то более отстранённым, утратил "резкость" и остроту. Сходные процессы имеют место, например, у композиторов -- любой композитор является ещё и, как правило, неплохим музыкантом (а некоторые и мультининструменталистами), и он постоянно упражняется в процессе сочинения музыки. Если исключить работу с музыкальным инструментом, это очень быстро и пагубно сказывается на качестве результата. Агентный вайбкодинг не предполагает ручную правку кода, да это и неэффективно -- править машинногенерированный код, который оно за секунды может переделать до неузнаваемости, совершенно пустое дело. Поэтому человек пишет промпты, к модель код. С джунами ситуация несколько иная -- если видно, что он пишет не то, то ему даются указания вплоть до переписывания некоторых фрагментов его кода с целью примера. Т.е. тут модель "наставник-падаван", где наставник работает с кодом обычным образом. С моделями это совсем иначе. А не опасаетесь сливать код -- ведь хотя и утверждают, что агенты с кодом только работают, но не сохраняют его, давно известно, что всё, что улетело в интернет, там и осталось. Или у вас свой собственный сервер?

Мои 5 копеек. Платные работают получше бесплатных за счёт больше выделенных ресурсов (глубина памяти, ширина "охвата" -- количество одновременно используемых параметров и т.п.). Но принципиальной разницы, имхо, нет. LLM неплохо справляются с контекстами, где они хорошо обучены -- например, нужно решить более-менее типовую задачу, которая для меня новая, а эти её на ура делают. Но как только что-то частное/необычное, начинаются сюрпризы. Например, описываю контекст (программа для хоста на С++), говорю, что хочу, они сыпят вариантами, один навороченнее другого. И вроде с виду всё логично и неплохо -- они даже приводят сравнительные оценки и дают рекомендации по выбору того или иного варианта в зависимости от условий/предпочтений, но не покидает ощущение, что что-то не то, как-то всё это сложновато и избыточно. Начинаю указывать им на это, приводить свои соображения, какое-то время идёт диалог, в результате которого понимаю, что задача решается вообще введением колбека в классе-агенте. Ни разу ни одна НС до подобного не додумывалась. Они всё время стремятся решить задачу стереотипно -- ну, на чём обучены, а тут контест для них новый. Вот тут, кстати, всплывает ещё один полезный аспект: даже если оно не выдаёт годного решения, процесс бодания с ним нередко выводит на такое решение. Т.е. как спарринг-партнёр вполне годная технология. Иногда использую для расшифровки ошибок в выхлопе С++ компилятора, когда там текст на полэкрана с раскруткой шаблонного метапрограммирования внутри стандартной библиотеки -- офигеешь там разбираться, что компилятору не понравилось, а LLM почти всегда с ходу выдаёт диагноз, и обычно вполне годный. Это объяснимо -- подобные баги имеют регулярную природу, модели на этом хорошо обучены. Несколько раз использовал как линтер, тут с переменным успехом -- где-то по делу, а где-то пурга. Ещё одно из полезнейших применений -- ассистент при изучении нового (для себя) контекста. Например, прошу объяснить концепт std::future/promise (тот же С++), получаю внятную и доходчивую выжимку. С помощью уточняющих вопросов очень быстро наводится полная ясность. Изучение подобного по книжкам и референсам занимает на порядок больше времени и усилий. Как сказал кто-то из экспертов по этой теме (цитата не дословная, только суть): как генераторы кода модели работают хорошо, но набор кода -- это лишь небольшая часть работы, а есть более важные и значимые её части -- разработка архитектуры, интерфейсов, компоновка программы -- чтобы это всё было читабельным, сопровождабельным, расширяемым и развиваемым. И вот тут модели не сильны. Возможно, когда-нибудь их обучат и на такое, но и тут они будут скорее всего хорошо справляться с хорошо проработанными конекстами, а когда что-то новое, то сразу провал. Ну, и в конце концов возникает сакраментальный вопрос: кто оседлал агентов и ездит на них даже "в сортир", вы не боитесь, что без агентов вы сами очень скоро не сможете и малой доли того, что умели до этого вайбкодинга? Человеческий организм и мозг в особенности устроены так, что если их не нагружать регулярно, они очень быстро деградируют. И обратный путь кратно тяжелее. Поэтому использование LLM для рутины -- годная тема, но как замена собственному мышлению -- нет! Для себя решил: LLM как ассистенты -- да, как агенты -- нет.