nice_vladi

Up. Поставил новый matlab 2020a. Вижу почти такую же проблему: Тулбар отсутствует совсем. Однако хоткеи работают нормально. Любые идеи насчёт того, как это всё починить приветствуются) Matlab R2020a upd 4. Ubuntu 18.04.5 Upd. Обновился до Ubuntu 20.04.1 - симптомы все те же.

Отличный повод просветиться и повысить компетенции =)

Лучше на питоне. Даёшь кроссплатформенность)

Выбор есть всегда. Например, открыть мануал на Libero SoC и вбить в поиск Default I/O или не открывать) Libero SoC User's Guide, page 251 говорит нам: Все пины будут в default io technology. Если хотите изменить стандарт каких-то пинов - нужно будет явно указать в attribute editor или ручками, в .pdc. ЗЫ. Если уж вас склонили к работе с Microsemi - так качните мануалы и даташиты с их оф. сайта к вашей версии софта/модели ПЛИС. И сначала ищите там. Там точно *гораздо* компетентнее, чем на форуме будет описано то, что вы ищите.

Нет, это вообще не про тот файл. Посмотрите внимательнее: строка с точкой утверждает, что всё уже сохранилось успешно (Design saved to file...) а вот следующая строка, красная, уже говорит об ошибке. Он существует в "грязном" проекте и отсутствует в "чистом". В файле проекта и в скриптах никакого упоминания об этом .tcl файле нет. Скорее всего, у Libero где-то внутри что-то забагалось и она складывает все файлы в реализацию +1, а этот скрипт ищет в предыдущей. Я подобные глюки лечил пересозданием проекта. Зачем? Пусть создает этот файл - от него же ни жарко ни холодно. Откройте, посмотрите - там просто сваленные в кучу констрейны из других .sdc. Как говорил выше - создать проект заново. По-идее, если предыдущие разработчики не крутили тонкие настройки синтеза/компиляции, а оставили всё по умолчанию (в пользу чего говорит небольшой размер проекта и краткость в констрейнах) то набора RTL+constraints будет достаточно для получения идентичной прошивки. Во всяком случае - по поведению.

Ошибка указывает не на существующий файл с точкой (toplevel.adb) а на действительно отсутствующий run_pinrpt.tcl, который лежит в несуществующей папке designer/impl1 Это файлик констрейнов, в котором слепленны в одно все констрейны проекта. Он автоматически создается Libero, если стоит соответствующая галочка в настройках синтеза. И точно так же автоматически удаляется при очистке проекта. ЗЫ. А что мешает просто создать заново проект, добавив в него констрейны и RTL файлы? Там не так уж много файликов... ЗЗЫ. Попробовал собрать в 11.9. Суть в том, что после очистки проекта Libero инкрементирует номер реализации (implementation) и создаёт под него новую папку impl<номер>. В вашем "очищенном" проекте создалась папка impl3. И все временные файлики ложатся в неё. Но, почему-то, файл run_pinrpt.tcl Libero продолжает искать в папке предыдущей реализации (impl1). Почему так - не знаю. Такой затык не встречал)

Всё, сдаюсь, все навыки удаленной отладки использовал)) Если хотите - можете отправить проект, попробую его собрать в версии 12.3. Можно в ЛС. Да, именно, перепутал. Я точно названия не вспомнил. У вас просто Mark as Used/Mark as Unused. Но сути дела не меняет. В 12й всё только через constraint manager делается: У меня это спрятано (и в 11.х версиях тоже, если не ошибаюсь) в файлик top_pinrpt_name.rpt. Он доступен из менюшки репортов Libero, либо можно текстовым редактором открыть и посмотреть. Идея в том, что бы проверить, что Libero *действительно* назначила на пины именно те сигналы, что вы указали. Потому что, как я говорил постом выше, бывали ситуации, когда файл описания пинов не применялся/применялся неверено.

Так вы компиляцию заново запустите.

Мосье знает толк в извращениях =)) Это очень странно... Квартус хранит информацию о размещении пинов, их стандарте и т.д. в .qsf файле. Ну, или в .tcl скриптах, которые запускаются из .qsf (это любят их инженеры делать в design example'ах). Но уж никак не в папке /db Вас не смущает, что пути в обоих проектах отличаются? В частности, ошибка указывает на диск F:\, а на другом скрине все пути ведут на диск C:\. Скорее всего, где-то тут собака порылась. Да, всё так, жмакаете Export Programming File. Откроется менюшка с настройками. И там всё по вашему вкусу настраиваете. Есть очень тонкий момент с констрейнами и пинами. При определенных обстоятельствах (точно не помню, при каких) Libero "забывает" файл пинов и компилирует проект, назначая все входные/выходные сигналы на какие-нибудь рандомные пины. При этом никаких явных ошибок не показывает (мб, что-то в глубине логов и закопано, не знаю). В общем, при сборке проекта стоит убедиться, что к проекту подключен файл .sdc и Libero его использует. Можно проверить нажав на него ПКМ -> Use for compile, Use for synthesis. Точное название пунктов меню не помню, но увидите - поймёте. Так же, в одном из репортов place and route есть список связей пин-сигнал. В него тоже можно заглянуть. В свое время дня три убил, пытаясь понять, что не так со 100% рабочим проектом. Оказалось, дело в этом, и все сигналы были хаотично раскиданы по пинам. В 12 версии они неплохо поработали над интерфейсом и в целом, по design flow прошлись: что-то соптимизировали, что-то причесали. Можете полистать release notes, для интереса. Так же, начиная с 12й версии полностью убрали режим описания констрейнов classic (вроде, так назывался) и оставили только новый режим, с мастером констрейнов. ЗЫ. В целом, политика microsemi по отношению к своему софту импонирует. Все выглядит, что как будто "для людей" стараются. Функционально, с хорошими манулами, без кучи рюшечек. Но работы все равно еще много =)

Ждал, когда появится эта тема) Зачем столько негатива? Игрушка занятная. Чуваки честно расписали все её особенности, не претендуют на какие-то высокие вещи. Выложили на кик, народ потянулся, денег занёс. Значит есть вероятность, что этот девайс увидит свет. Всё. Думаю, стоит порадоваться, что отечественные бойцы собрали такой интересный широким массам девайс.

И их туда же =) Ну, про точку не знаю. Не встречал. Но НЕ открываться может и по другим причинам, например, сбились пути. Например, из-за того, что проект перенесли из линукса под вин. Было такое. Многие вещи можно проверить, открыв файл .prjx. Там все пути и т.д. Можно даже ручками поправить. Но осторожно и сделав backup) Вообще, при необходимости утащить куда-то прошивку я пользовался менюшкой Handoff Design for Production -> Export Bitstream в окне с Design Flow. Там сразу и тип экспортируемой прошивки можно выбрать и место, куда складывать. А то, что в "почищенном" нет файла битстрима - так это вполне нормально. Вы же всё грохнули и битстрим в т.ч.

.gitignore проекта под SF2 в Libero SoC: # Libero designer/ synthesis/ tooldata/ simulation/ smartgen/ *.digest *.def *~ *.aux *.log *.fdb_latexmk *.fls *.idx *.ilg *.ind *.synctex.gz *.toc *.bak # Sim files wave.do modelsim.ini *.wlf /testbench/*/sim/COREFIFO_LIB/ /testbench/*/sim/*.txt /testbench/*/sim/work ЗЫ: обычно, когда хочу 100% собрать всё заново грохаю всё, кроме hdl (исходники), component (IP cores), constraint (констрейны и пины), файл проекта .prjx. Можете проверить в отдельной папочке этот метод)

Ну это вы лишка хватили) А вообще - да, говорите очень дельные вещи по поводу вакансий. Не часто в разделе "Предлагаю работу" появляются люди, которые достаточно адекватны в полемике xDDD

Рекомендую просветиться. Годная статья. В том числе и про нескольких мастеров. http://easyelectronics.ru/interface-bus-iic-i2c.html

Ну рано или поздно все равно придётся где-то объявлять список задействованных файлов. В do скриптах можно в качестве цели указывать не файл, а папку: ./../rtl/blabla/*.sv А про помощников - все придумано за нас: hdlmake

Можете, действительно, в сторону матлаб посмотреть. Там есть два интересных режима: 1. Co-simulation. Это больше программные тесты, к матлабу подключается questa и матлаб работает с её сигналами. 2. Hardware-in-loop. Тут уже ПЛИС подключается к матлаб и матлаб работает непосредственно с её сигналами. Но там свои заморочки с согласованием интерфейсов в плис-матлаб и т.д. Наверное вам интереснее 2й вариант. Можно напрямую с целевой плис работать, можно собрать плис dut + плис driver.

Под задачу обработки данных хорошо ложатся яблочные поделки. Посмотрите в сторону Mac Air/Pro. Ну и видео-звук там одни из лучших. Корпус - металл.

Попробую в вангу и порекомендую очень хорошую книжку по SV в области верификации: SystemVerilog for Verification: A Guide to Learning the Testbench Language Features, Chris Spear Все основные несинтезируемы конструкции описаны приятно, просто, с объяснениями. Плюс масса примеров: как надо делать и как не надо делать.

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

Немного продолжу тему. Появился очередной вопрос на тему архитектуры коммутатора. Вопрос опять довольно "низкоуровневый", в сети и букварях не нашёл описания. Всё ниже относится к концепции коммутатора с общим буфером. Как то, что было описано выше. С передачей указателя всё понятно. Указатель передаётся в очередь каждого из портов, кроме порта-источника. А вот как *правильно* возвращать этот указатель в список свободных? Что я пробовал: 1. Передача пакетов блокируется, пока не будет передан широковещательный пакет. Работает, но однозначно плохой вариант, не обсуждаю. 2. К указателям на пакет добавляется флаг broadcast. С этим флагом передающие порты не возвращают указатель в общий пул. Вместо этого есть отдельный буфер для указателей, относящихся к широковещательным пакетам. Это буфер копит указатели и возвращает их по таймауту в общий пул. Основной недостаток: необходимо выбрать таймаут *гарантирующий*, что пакет будет разослан во все порты до того, как указатель вернётся в общий пул и, возможно, будет использован каким-либо приёмным портом. При большом количестве широковещательных пакетов память очень быстро заканчивается. Собственно, вопрос: как правильно обрабатывать указатель на пакет, предназначенный для широковещательной рассылки? Есть ли общепринятые правила?

Так можно отсимулить. Там есть ТБ

#япиарюсь https://gitlab.com/vborchsh/spi-core/-/blob/master/spi_slave.sv

Нет, все в одной зоне радиовидимости. Спасибо, почитаю. В моих мечтах это должна быть сеть даже БЕЗ координатора. Ну, например, кадр разбивается на 100 слотов. И каждый вновь включившийся абонент проверяет наличие свободного слота и встаёт в него. Ну это так, рассуждения. Я ж наивный и дословно ввёл) Тут тоже, судя по описанию, всё сводится в узел (шлюз) - "звезда"

Такой запрос отсылает в сторону биткоинов и веб-торрентов). Я немного не о том спрашивал) Все сети, которые нашёл, подразумевают наличие шлюза/маршрутизатора - устройства, которое и организовывает сеть, либо служит точкой доступа, базовой станцией. Мне же интересна сеть, состоящая только из "абонентов"-"пиров".