Лидеры

Коллеги, я решил проблему с ошибкой верификации битстрима. Что было изначально: - битстрим собран в Vivado с использованием патча от Fudan версии 5.2.0, итог: успешная верификация на всех чипах 2022 года и на 41% чипов 2023 года. Что я сделал чтобы решить проблему: - ранее собранный битстрим прогнал через инкрементальный патч в Platform Tools из Procise, дабы посмотреть, что будет меняться в зависимости от установленных галочек, итог: с дефолтными настройками получил битстрим, который успешно проходит верификацию на всех чипах 2023 года выпуска. *.msk файл при этом от исходного битстрима. Похоже, что патч для Vivado либо не до конца отрабатывает, либо не учитывает какие-то особенности более новых чипов. При этом я также получил Warning от Platform Tools, что у меня в битстриме есть SDP RAM, хотя патч должен был поправить SDP на TDP. Более того в логах самого патча нет никакой ругани на SDP. В общем проект спасён, вроде есть путь, по которому можно получить рабочее решение, но, как говорится, осадочек остался... Буду пробовать PangoMicro - со дня на день должны приехать 🙂

я так понимаю лицензия на просто "simulate SV" есть? у меня "штатная" лиц для 12-го не позволяла симулять SV - не помню где и как, вероятнее всего на тутошнем фтп нарыл какую-то лиц, в которой была сточка про SV симуляцию - вырезал и вставил эти строки в свой текущий файл license.lic и заработало. Вот эта фича - правильная? FEATURE ACTIVEHDL_SVA_SUPPORT? Я так понимаю что прято тут нехорошо фаел выкладывать...? Поройтесь в местных закромах - по-моему в названии архива должно быть чо-то типа "2050" - нужно в тексте поискать фичу которая вам нужна...

Преобразователь интерфейсов USB-RS485 от MOXA наверное единственный, который нормально поддерживает MODBUS-RTU. Весь остальной зоопарк преобразователей рвали прием/передачу на 32-ом байте.

Спасибо, отличный пример, как не следует делать БП при таких исходных. Сперва поинтересуйтесь, почём у них будут аналоги IRM-90-24, или даже оригинал в Вашей местности.

Ну, тогда уже и все остальное заказывайте по образцу и подобию. Дешевле будет.

Расшифрую немного. Сейчас вы видите в отчете что-то, чего сами не задумывали в дизайне. Значит, IDE собирает какой-то другой проект, НЕ ВАШ. И собирает его неправильно. Вам нужно детально проанализировать каждую строчку репорта - посмотреть код, посмотреть схему, проверить тактирование всех участвующих сигналов. Если IDE говорит, что есть пересечение клоков - то так оно и есть. По крайней мере, в "её" проекте. Вопрос только "где?" и "как это исправить?". В одной и предыдущих ваших тем на форуме мы уже обсуждали этот момент. С помощью констрейнов можно легко заглушить все нарушения. Но вам-то, наверное, не отчеты нужны, а работающий дизайн. Поэтому, скорее всего, каждая красная строчка отчета потребует некоторых доработок по коду. Где-то нужно будет добавить синхронизаторы, а где-то - констрейны. Каждый случай потребуется разбирать отдельно, и на форуме это сделать сложно. Почитайте книжки, которые я прикрепил, это самая лучшая литература по теме.

Не подобрать, а рассчитать, читаем документацию АкейГугла

Был (есть) в отпуске, но, пожалуй, скажу пару слов. Надежды, возлагаемые на C++ в части облегчения исходников, улучшения их сопровождения и в целом удобства разработки ПО - не оправдались. Этак, процентов на 90. Но это не значит, что я не буду писать на нем. Когда переходил с Си, основная болезненная для меня тема, а именно - сокрытие данных и более строгая изолированность модулей за счет применения классов и пространств имен - покрыта возможностями C++ на 100%. Наверное, это единственное, чего мне так сильно не хватало в Си. Будь в Си хотя бы пространства имен, как в плюсах, я, наверное, вряд ли бы переходил. Во всем остальном C++ весьма переусложнен и витиеват, особенно для ембеддед. Тучный и порою нечитаемый синтаксис, в котором приходится ковыряться, напрягая мозг и отвлекаясь от основной цели. Десять и больше способов сделать ровно одно и то же (например, инициализация объектов или переменных). Туманные перспективы писать действительно переносимый код - "фишки" последних редакций стандартов выглядят такими, что создается впечатление о их выпиливании уже в следующей редакции. Говнокод и нормальный код выглядят примерно одинаково - но это следствие первых двух факторов. Излишняя универсальность, при этом эта универсальность практически всегда смотрит "не туда" - C++ заставляет думать в неких заранее определенных категориях, поэтому шаг влево и идеальная структура твоего кода рушится. Стандартная библиотека, которая всегда хорошо выглядит лишь на учебных и удобных примерах, или в качестве вполне рабочих примеров-псевдокодов для объяснения на разных форумах - а в реальных проектах (и тем более для эмбеддед) многое из стандартной библиотеки реализуется по-своему. Очень странное желание комитета (вернее, той группы энтузиастов, что пилят очередную версию стандарта) объединить все области в одном месте - и принципы ООП, и какие-то уже вполне конкретные алгоритмы, и даже механизмы обеспечения многозадачности - стандартная библиотека уже давно обрастает трэд-сэфити конструкциями, которые упрощают (наверное) порог входа в многопоточное кодирование, но на мой взгляд такой подход потом заставит родить еще 100500 методов отлова ошибок юзеров, которые окончательно запутаются в назначении всех этих премудростей и начнут жоско говнокодить, лишь бы работало как-нибудь. Чего дальше ожидать? Собственные стеки протоколов? Судя по развитию языка - ожидать. Пишу ли я на C++? Ну, как сказать. Весь нижний уровень драйверов я пишу в стиле Си - заимствую по ситуации из плюсов вкусовщину - крайне стабильные в поведении вещи - нэймспейсы, классы, несложные шаблоны и перегрузки. Саму логику работы могу описывать в ООП-стиле, а могу не описывать. Честно говоря, какими бы сложными не были мои девайсы, применение абстракций и ООП-парадигмы в финальном варианте выглядит как "применил ООП ради ООП", а не ради упрощения читаемости и понимаемости кода. Лучше делать упор на "базу" - писать потокобезопасно, без гонок, без сомнительной универсальности, которая с вероятностью 99% не выстрелит, с адекватным пользованием ресурсов, с предположением, что тебе же этот код и сопровождать потом и главное - с твердым пониманием происходящего. А то, что я не пользуюсь огромным количеством встроенных в C++ премудростей - да и фиг с ними. Этих премудростей привносят в очередной редакции стандарта как г*на на лопате - и вуаля - твой код теперь пахнет дурно, потому что, видите ли, новый стандрат добавил в стандартную библиотеку то-то сё-то, а в твоем коде это "то-то" было впилено собственноручно.

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