yes

может я чего-то путаю, последний раз со 188 имел дело в прошлом тысячелетии, но из общей эрудиции - если греются устройства на общей шине, то наверно к этой самой шине надо внимательнее присмотреться Х86/88 имеют мультиплексированую шину адрес данные, то есть напрямую к 29 флаши не подключишь, должен быть какой-то регистр для защелки адреса и даже не разбираясь со схемотехникой - точно все линии, особенно двунаправленные АД не просаживаются? И если устройство ценное, то стоит приложить усилия, чтобы считать флашку, может какой-то микроконтроллер прицепить и его гпио ногами подергать адреса флэши и скачать содержимое. По дизасемблеру сразу будет видно нормальная флаш или какието битики адреса/данных выгорели. По моему, стартует 18х откуда то ближе к концу флэши чтото типа 0xffff0 там точно код, а не дата

на всякий случай Если структура packed typedef struct packed { и поля в ней переставить, чтобы как-то lsb соблюдалось ... field_3; ... ... field_1; то можно msg=msg_reg; или msg_reg=msg; Если размеры l-value r-value не совпадают, то лишние биты не будут использоватся, недостающие не поменяются

и на ксайлинских демо бордах и потом у себя использовал TI TCA/PCA - там разное число каналов 2-8 . но там надо команду на переключение шин давать. https://www.ti.com/interface/i2c/switches-and-multiplexers/overview.html

inout sda_master; inout scl_slave; input [2:0] Pos; inout sda_slave[0:4]; // LSB / MSB - better to change endianess i.e. [4:0] inout scl_slave[0:4]; Не понимаю, какие бубны? Допустим, клок слэйвы тормозить не умеют (ну иначе так же как SDA) inout в плис -> out, oe (0-ena, 1-HiZ), in reg [4:0] sel; always_comb begin sel=`1; sel=sel^(1<<pos); sda_slave_oe={5{sda_master_in}}|sel; scl_slave_oe={5{scl_master_in}}|sel; sda_master_oe=&sda_slave_in; scl_master_oe=1; // only FPGA input, i2c slaves do not drive scl* {sda_slave_out, scl_slave_out, sda_master_out, scl_master_out}='0; end upd: sda_master_oe=&(sda_slave_in|sel); // так наверно надежнее будет, на случай если какойто слэйв заглючит наверно, я плохо подумал... сам так не делал. но ведь техасовские то ли TBA, то ли TBX буфера для согласования I2C-шных шин с разными питаниями приблизительно так устроены... - посмотрю их на досуге.

FPGA-шный DC (что то даже не могу вспомнить, как он назывался) - вообще был жалкое зрелище, по-моему. Но гейслеровский fpu нетлист я вытягивал и что-то даже симулировал с азик-овой библиотекой. Хотя результаты синтеза/мапирования были плачевные.

Технически, декодер+ключ в виде вивады уже есть. То есть вопрос не криптоустойчивости, а настойчивости в дебаженьи той самой вивады. И насколько я знаю, некоторые участники на этом форуме вполне это умеют. Сильно сомневаюсь, что во взрослом IP, даже не обфусцированном, чтото удастся поправить. Эти IP (ну то что я видел), обычно написаны так, что обфускатор не нужен. Похоже, что используются какието высокоуровневые описания, скрипты-генераторы кода, конфигураторы и т.п. В древние времена ксайлинс давал библиотеки DC для своих плис, какихто виртексов. Можно было "перемапировать" нетлист под другую технологию, или возможно даже размапировать в gtech. Наверно, при должном усердии и обилии свободного времени, можно написать библиотеку под современную ПЛИС и размапировать даже современное ИП. Сомневаюсь, что на практике кто-либо так делал. 2автор - IP позволяет ещё и симулировать проект (с нетлистом будет гораздо медленнее). Ну и кроме честности покупателя, ничего не мешает сгенерить из IP нетлисты для разных технологий. В случае вивады и ксайлинса наверно не особо важно, так как логика в его новых семействах одинаковая и нетлисты тоже. Но "вообще"

может я туплю, но в чем проблема? Они же опендрейн - то есть аут ечейки в 0, а на аут_ена сигнал с общего входа "подсвеченный" селектором Ну а на микроконтроллер просто все объеденить, без подсвечивания, если сенсоры молчат пока их не спросят (в и2ц иначе нельзя жи) Извиняйте за небрежность, пишу из горящего танка без клавиатуры upd: аут_ена должен быть с активным нулем, а "подсвечивать" ОРом, надеюсь, излишний клмент, но маю час та натхнэння

Может не в тему, просто столкнулся с такой фигней, в rust-е стандартные строки utf-16 и есть их преобразование в байты. Наверно с учётом всех исключений и всей этой разноразмерности (я в ютф не вникал). Предполагаю, что растовские сорцы можно понять, если даже раньше не

И раз тема всплыла... peakRDL умеет экспортировать IP-XACT, который можно импортировать в Kactus2, а из него сгенерить MD доки, вполне читаемые, имхо Но SystemRDL как исходник, имхо, гораздо лучше IP-XACT-a

wiki Отец — Барак Хусейн Обама — старший (1936—1982) — кениец, сын знахаря из народа луо. Миссионерская школа оплатила ему учёбу в Найроби и отправила для изучения курса эконометрики в Университет Гавайев в Маноа, где он организовал Ассоциацию иностранных студентов и стал лучшим в своём выпуске. то есть я так понимаю, что знахарь из Кении входил в число тех 100? или хусейнович был просто петрушкой, которому рокфеллеры-ротшильды-рептилоиды засунули в соответствующее место руку и управляли? ----------- имхо, основной признак конспирологических теорий, что они какие-то простые вещи всегда объясняют с привлечением сложных и несвязаных между собой объяснений

Да много там разных инструментов, не только кросскомпилятор. У каждого инструмента может быть свой набор библиотек даже для одного и того же дистрибутива системы. Эту проблему пытаются решить очень давно, те же autoconf/automake например, но, имхо, безуспешно. Всегда приходится возиться, чтобы собрать какой-то не мейстримовый пакет (старый, малопопулярный и т.п) Постоянно появляются какие-то модные-современные сборщики - cargo, sbt, bazel ... это только на той неделе столкнулся, а так их сотни Практически, чтобы на xосте сборщик увидел динамическую библиотеку, в баше надо сказать (это должно быть в первой выдаче гугля, помоему) export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:_my_path_ upd: libGLESv2.so может быть линком, а самой библиотеки может и нету. Я билдрут очень давно использовал, контретных деталей не помню

Спасибо. В общем сильно много добавилось со времен прошлого моего интереса к теме. Вроде бы эта табличка выше не упоминалась (извиняюсь, если все таки тут была ссылка) https://chipsalliance.github.io/sv-tests-results/ как стартовый список Удивительно, что даже какието формальные опенсорс тулзы появились. Я не проверял. ---------- что собрал, проверил и работает sv-parser (rust) verible slang ---------- проще всего приклеить к питону мне получилось (то есть из коробки заработало) sv-parser через svinst питоновский интерфейс Но наверно, кроме генерации кода, прикручу ещё lint из verible

Спасибо. Вот ещё на rust https://github.com/dalance/sv-parser –--------–--------------–----------- Смотрю пока, прокомментировать и сказать, что подошло ещё не могу

минимально нужно, чтобы разбирал иерархию, но если ещё умеет сигналы и их подключение к портам разбирать, то вообще замечательно. я посмотрел на PyHDI/Pyverilog - но как-то никакой из моих проектов он так сразу, без исправления кода, не отпарсил. Наверно, ограничено синтаксисом icarus verilog-а, по крайней мере, ему требуется что то от икарус-верилога. Посмотрел ещё парочку простых проектов, но там работает пофайлово, про иерархию вообще ничего нет... --- Пойдет и просто синтаксическое дерево для lex-yacc вроде бы в питон можно его засунуть. Не хотелось бы самому какой-то примитивный парсер ваять...

eyephone - футурама, какие-то старые сезоны ~2000