fguy

Интерфейс управления естественно должен поддерживать arp и ping для работы хотя бы с udp, а интерфейсу выдачи данных по тому же мультикаст/уникаст проку с этого нуль.

Проход пакетов от одного девайса до другого по такой сетке обеспечивает админ, а не навороченность (в плане поддержки кучи протоколов) ядра в плис. Мне реализации обычного udp c возможностью выставить нужные МАС, IP адрес и порт всегда хватало что бы пакеты дошли хоть по радиомостам, хоть по много-км территории предприятия с хз какой структурой сети.

То же вариант. Как то нужно было по быстрому конфигурить на плис адрес передачи - дык сделали это через пинг - ядро отправляло пакеты на адрес источника в пришедшем пакете пинга.

А IP другого компа вы как собираетесь ему давать - вот тем же путем и МАС. Если девайс на цинке, то передать параметры канала выдачи с плис можно через проц или зашивать конфиг с настройками в загрузочную флэшку. Если это обычная плис без встроенного проца, то ядро для упаковки пакетов подключаю к микроблэйзу для конфигурации, а так же для отправки пакетов с проца, а канал приема пакетов с ядра эзернет через фифоху в микроблэйз и свой микростэк (лвипу нужно будет 256 кбайт озу - а свой и в 64 кб помещается) с арп, пинг и удипи для управления девайсом. Если проц совсем не нужен, то все адреса можно положить в брам и его инициализировать дампом при сборке бит-файла (так же как интегрируется код микроблэйза), а ядром вычитывать из него адреса.

В том и фокус что для мультикаста мас назначения знать не нужно, а из "плюсов" мультикаст можно смотреть на нескольких пк одновременно, ну и из "минусов" он не проходит через радиоканал - его банят вай-фай роутеры и прочие мосты - в таком случае спасает уникаст. Для уникаста арп то же не обязателен - вы заранее узнаете мас назначения и пишите его в ядро. Для реализации обоих вариантов нужно иметь возможность задавать ядру формирующему пакеты MAC, IP адрес и порт для src и dst.

Это смотря что нужно - из плис мне например достаточно только выдавать данные и для этого хватает мультикаст или юникаст, а для их реализации достаточно сформировать пакет udp с контрольной суммой и отправить в мак (mac xilinx еще сам и кс посчитает), а на прием пакетов можно класть или ложить по вкусу. Обратная задача (только прием) решается так же.

Там много до чего руки не дошли - в той же виваде флоат в симуляторе декодируют, а в чипскопе нет - хотя с виду вьювер один и тот же.

Спустя всего 3 недели выпущен 1й апдейт...

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

удав в виваде свой, но она как то цепляет штатный прописаный в питонхоме и из за разницы версий питонов ругаются ее скрипты - похожее сообщение с ошибкой при установке видел еще в 2023.2 но там это обошлось без последствий, а тут витис просто жутко дурил. В новом витис сдк если нет этой лицензии вылезают сообщения с предложением получить ее на офсайте - понятно дело для России будут препоны. Сообщение вылезло при работе с витис хлс (на базе нового витиса - а другого нету) - при создании проекта из библиотеки (п.3) и при выводе иерархии проекта. Да новый - в настройках шрифт нужно прописывать ручками - нет никакого диалога, а про кодировки вообще не спрашивает. СДК на эклипсе тоже был не подарок, но к нему хоть как то привык, а эту дурь еще курить и курить... Я накидал тест на новом микроблэйзе с риск 5 (без ддр) - развелся и экспорт-импорт в новый витис без проблем (после чистки питона).

Потестил слегка: 1. Перед установкой убрать переменные среды винды для питона насовсем - иначе сабж жутко колбасит. 2. Для нормальной работы витис хлс нужна лицензия на опцию VITIS_HLS иначе ругается в ряде команд "меню". 3. Что бы добавить Vitis_libraries в офлайне в новый витис, нужно подсмотреть в витис классик (в новом этой команды просто нет) путь куда распаковать выкачанный с гитхабовской репы xilinix архив. 4. В исходниках хлс слетели все комменты на русском из за перехода на UTF-8. Из хорошего - спустя 5 лет господа изволили-с исправить свой косяк с генерацией брам-интерфейса в хлс (неправильно задается размер брам в параметрах ядра во всех 2019-2023). К сожалению не без ложки - старые версии позволяли вольности с шириной шины данных брама и сами округляли в большую сторону до ближайшей степени 2ки - новая это не делает и верификация в бд на это ругается.

На алике физлицам по плисам и доскам бывают такие предложения что юрикам и не снилось.

Битые блоки в ддр встречаются действительно редко, а вот залипания адресных шин зависят от качества монтажа и патернами не обнаруживаются - только непрерывным счетчиком по всему объему - в ультрацинках он может быть разбит на 2 части при объеме ддр 4 Гбайта. А при удачной загрузке есть лог? Попробуйте включить вывод лога в FSBL - может это что то прояснит... Такая возможность действительно есть, но сам JTAG может повлиять на процесс загрузки. Этот вариант применим когда глюк стабильный.

Надо проверять весь объем и более тщательно, а не "вот это вот" из сдк. Если плисовая часть выставила Done после включения это значит что как минимум загрузился в проц FSBL и выполнил удачную загрузку плис, а штатный процессорный код может зависнуть по миллиону причин. Самое простое это смотреть логи проца - если они у вас конечно выводятся и отражают последовательность запуска штатного софта проца. В таких случаях часто подвисает на инициализации периферийных чипов - генераторов, клокменеджеров и контролеров чего-нибудь. Если в плис есть подключенный к процу AXI-интерконнект работающий от внешних тактов, то их отсутствие так же приведет к глухому зависанию проца при попытке чего-нибудь прочитать или записать через него.

Обязательно тестируйте ддр на проце - не полагайтесь на сигнал конец калибровки - он не дает полной гарантии работоспособности ддр. Необходимый минимум тестов во всем диапазоне адресов - несколько разных масок и непрерывный счетчик для выявления проблем с адресами. Тест лучше всего запускать из памяти проца а не из ддр.

ХЗ, возможно особенности реализации и самого tcp то же - вы и сами будете отправлять страницу по частям через tcp_write.

Под проц цинка проект собирался под виндой в SDK 2018.3, косяк лвипа со склейкой пакетов проверял еще и в Vitis (ex SDK) 2023.1. При сборке оболочка запускает разные тулзы - cmake это или что другое я не вникал - и так работает.

Откровенно блажная идея с веб-мордой в цинке доела не только мой мозг, но и мозги "начальства" - решение сделать было принято окончательно и бесповоротно. Само собой лвип с примерами был в первых рядах, т.к. поднимать линукс только ради этого не хотелось совсем. Учитывая динамический характер "сайта" и гемор со сборкой от виртуального диска тут же отказался. Файлы из примера были перенесены в проект и сделано динамическое формирование страниц в коде. Язык Си и работа со строками это отдельно-жутко-печальная песня. Желанный и никому не нужный на поверку результат был получен довольно быстро. Из подводных камней оказалось что разные браузеры шлют GET по разному, например, опера разбивает его на 2 tcp пакета которые лвип не склеивает хз почему - с эджем такой проблемы нет. Учитывая отсутствие с этим проблем у "больших" веб-серверов недоработка скорее всего в лвипе, включая и последние версии, из за упрощенной реализации.

На этом форуме автор предлагал свой проект для тестирования компонентов плис https://opencores.org/websvn/listing?repname=highload&path=%2Fhighload%2F#path_highload_ Если его кто то адаптирует под 200-й артикс и виваду то вполне годный тест и для вивады и потестить саму плис, да и как пример для переноса на другие чипы то же пойдет. Для топовых и7 тест должен собираться минут 30 что бы был запас и на будущее и не шибко долго на более слабых цпу.

В новостях последнее время часто ругают интелы 13 и 14 серий за то что слишком быстро работают и игры за ними не поспевают - сбоят и падают. Есть ли какой опыт у присутствующих по работе вивады на этих чипах уровня и7 - то же сбоит или виваде гигагерцы не помеха?

Цифровая электроника и в частности ПЛИС работает по тактам что само собой подразумевает "защелку" данных по фронту такта (упс - триггер). Даже варианты ядер которые могут работать за такт все равно требуют "защелку" данных, не говоря уже про сигнал "валид" (он то же по тактам) где в промежутках на шине данных может твориться любой треш. Уход от тактов и триггеров ведет в глубокую старину аналоговых вычислительных машин - стальной сундук с триодами-пентодами прекрасно обходился без триггеров и решал диф уравнения 20-х и более порядков в реальном времени. Хотя и в АВМ исследуется реакция RLC-цепочек на импульс...

AMD анонсировала 2е поколение Версалей - пока только 2 линейки - прайм и АI. Изменений куча - 4 или 8 ядер арм, вернули GPU, перешли на ддр5 - хорошо, но шина данных только 32 бит - плохо. https://community.amd.com/t5/adaptive-computing/amd-enables-single-chip-intelligence-for-ai-driven-embedded/ba-p/677330

В данном случае обсуждается как обойти ссанкции, а не местные запреты - что поделать если методика в обоих случаях примерно одинаковая.

Поискать анонимайзеры - к сожалению работают далеко не все - методом перебора более менее приличное отображение с картинками получил на этом https://proxyium.com/