WitFed

Интересное дело обнаружилось: https://en.wikipedia.org/wiki/Write_combining. В Intel и ARM давно есть, помогает писать в видеопамять пачками около 64 байт, предварительно собирая до кучи мелкие соседние записи. Как его применить к BAR памяти в драйвере Windows, подскажите. Читать быстрее оно тоже может помочь ?

Да, для ПЛИС меня это и интересует, уже сколько лет мучаемся с тормозными разовыми обращениями. По 8, 16 байт оно, конечно, немного быстрее. Но "продвинутые" мосты пока не попадались, чтобы совсем до кучи слепить хотя бы запись. Она же эффективнее, чем чтение из самого устройства. В инете гуглилось, что в GPU данные закачиваются медленнее, чем выгружаются обратно, это лишнее подтверждение, что там на борту тоже своё DMA. Реализация DMA в плате у нас в конце концов и делается, но это криво, с моей точки зрения. Какие могут быть разумные аргументы для отсутствия в архитектуре Intel прямого DMA для любых пересылок, и в первую очередь -- записи наружу ? Пнул и отвлёкся, ещё кого-то стартовал через FIFO запросов большой глубины, занимаешься другими добрыми делами, а потом как-то узнал, что всё закончилось.. Это же очень удобно. В https://electronix.ru/forum/topic/174010-api-dlya-bystrogo-kopirovaniya-bolshih-obyomov-dannyh-v-ustroystvo-dma/ я спрашивал -- там знатоки молчат. В книге Guk-M.-Entsiklopediya.-SHiny-PCI-USB-i-FireWire-2005.pdf прямо сказано: Т.е. мы в устройстве на чтении даже не знаем, какая будет длина транзакции, открываем страницу и читаем сразу большой кусок памяти, а начинаем отдавать -- и после первого обмена облом. Похоже, это только со стороны Intel осмысленная недоработка, которую легко исправить, учитывая обычную сверхсложность решений этой фирмы, просто ещё добавить арифметики в реализацию REP MOVS*. Мы же знаем сразу, какой объём последовательных данных предстоит передать, и по аналогии с обращением через SSE/AVX регистры можем подать в PCI запрос W/R именно на этот размер. Доброе дело тормозится по политическим причинам, как обычно ? А другие архитектуры бывают посолиднее ? В PCI Express тоже всё нормально в архитектуре заложено, там копия PCI, для совместимости. Большим пакетом можно всё сложить и послать при записи REP MOVS*, а на чтении -- один пакет запроса с общей длиной и обоими адресами. Или как ?

К конкретному устройству привязываться неправильно, даже если его и расковырять, нужен стандартный метод. В книге "Михаил Гук. Интерфейсы ПК" в разделе "6.2.5. Пропускная способность шины" про PCI говорится, что: > при записи массива данных в устройство PCI (передача с последовательно нарастающим адресом) мост может пытаться организовать пакетные циклы. > продвинутый мост может пытаться собирать в пакет и последовательные запросы, что может породить пакет существенной длины. Если использовать "REP MOVSD", где счётчик повторений известен, то современный процессор порождает burst операцию, кто-то пробовал ? Скорость памяти обычно гораздо больше, чем в шине, подгрести должно успеть.

Обидно. Всем нужно, у всех есть, и никто не хочет "вынести за скобки" или поделиться. Видеокарты ведь качают большие объёмы данных к себе и обратно, как GPU. Это тоже всё изнутри делается, а не снаружи, от CPU, только по его командам ? И никакого API не экспортируется для любой пары физических адресов ?

Народ, за 15 лет произошли какие-то сдвиги ? Появилось системное средство, чтобы без самописного DMA что-то быстро (burst-) писать/читать в PCIe ?

Много лет проблема стоит для Windows. (И для Linux тоже.) Запись в память устройства по PCI ещё как-то устраивает через оптимизированный код в memcpy(), где применяются команды по 8 и 16 байт за такт. А вот читать уже на порядок медленнее, даже порциями по 16 байт, там хочется слепить соседние запросы в burst-транзакции, чтобы стало похоже по эффективности на запись. В идеале -- надо запустить свободный системный канал DMA (их масса на материнке) "туда" или "обратно", самому заняться другими делами, а по готовности операции уже вернуться обратно на готовое. Наверняка кто-то уже решал подобную задачу. Или MS где-то припрятала такой функционал ? Базовая вещь. Физические адреса в устройстве есть, они непрерывные. У нас в памяти виртуальные непрерывны, а физические попутаны, как ОС раздаст, но с этим ядро ОС разбирается хорошо. К физическим и вообще аппаратуре не подпускают из верхнего уровня приложений, нужен драйвер. Писал уже кто-то такое "на продажу" ? Чтобы не ходить по граблям в 1000...-й раз, вызвать функцию волшебного драйвера и забыть...

Да, была такая функция, но в силу видения "выстрелов в молоко" не сильно верится в её использование. Хотя и в мою дееспособность тоже, 😉 если ни у кого таких проблем больше нет. Вот примеры обёрток: ULL FParamUnit = (ULL)&pUM_local; // Структура с параметрами модуля, это указатель, его память вернута из драйвера, обращение к ней в отладчике почему-то вешает ПЛИС, потому обёрнуто функциями WCHAR* get_HardwareId() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->HardwareId; } ULONG get_vBarMem_Count() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->vBarMem_Count; } DEF_DLL_EXP(ULL) get_vBarMem_Size(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->vBarMem_Size[i]; } ULL getPhis(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->memBase[i]; } ULL getVirt(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->pBarMem_Virt[i]; } int /*bool*/ isBAR(ui bar) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; if (!pu || bar >= pu->vBarMem_Count) return 0; return 1; } pUM_local -- статическая переменная, её заполнение идёт в ините устройства по памяти, выданной нашим драйвером, со всеми добытыми нужными потрохами. Её адрес кастуется в длинное целое, в обёртках выкастовывается обратно, идут чтения и возврат значений. Память эта точно локального процесса, но степанье отладчиком в районе вызовов "стреляет" и регулярно вешает всё, файлы регулярно портятся. Там в структуре есть физические и виртуальные адреса, они разыменовываются после получения в других функциях типа: ULONG getUL(ULL a) { PULONG p = (PULONG)a; return *p; } void putUL(ULL a, ULONG d) { PULONG p = (PULONG)a; *p = d; } ULL getULL(ULL a) { ULL *p = (ULL*)a; return *p; } Но "стреляет" и виснет даже не возле них, а возле первых, вызовы типа: ULL pB = getVirt(barR) + ofsR; Что заставляет Студию лазить адресам, соответствующим целым числам, совсем неясно. Типа очень крутой ИИ, прослеживающий всё на "годы вперёд" и без Релиза, что потом из pB будет скастован указатель, который можно нам показать "ради удобства" незаказанного, или что-то ещё... И обращения не в саму эту память, а рядом или "в молоко", хотя и повторяемое от зависания к зависанию. Незря нам Илон Маск (++) предлагает нейросети запретить. Даже если кнопку "Выкл" к ним прикрутишь, а они её изнутри отгрызут 😉

Ура, Мышка по делу высказалась. СпасиБо за отзывчивость. Паранойи и менеджмент/маркетинг давайте отбросим, это диавольский перемудрёж, как и вся система драйверов у MS, нам хотя бы детский функционал отладить, W/R регистров и памяти, а хаканье оставить имеющим больше мозгов и проблем от них. Сегодня на другой плате та же беда -- с точками останова и степаньем по коду виснет всё напрочь, даже кнопка резета не помогает. Без отладочных действий, но из Студии по F5, всё работает чисто, и нет ни одного окна, которое можно заподозрить в подсмотрах, и указателей тем более на уровне степанья. Т.е. скомпилированный код сам чист. В поддержку MS писать бес-полезно -- старые Студии они патчить не будут, а в новых столько других проблем, что там эта решённая никого не спасёт. Только ключик вдруг кто-то вычитал и знает об редуцировании избыточных сущностей. Сколько любители усложнений на 2-3 порядка ни думают вширь, всё равно вирусов и хакеров меньше не становится, а дырок -- только больше, ибо путь тупиковый. И всё в зверски мощных гаджетах больше и больше тормозит, что есть маркетинг, основа демо-жизни. Норушка, есть ещё одно лекарство, но я от своих желязячников его никак не добьюсь за 10+ лет: чтобы запросы чтения в общую шину всегда возвращали хоть FF, и хоть через секунду, это недорого, как бывает обычно устроено в сильнее развитых архитектурах. Когда-то жареный клюнет наконец, качества и надёжности захочется не только на словах. MS на этом свойстве Intel базируется, исключения у них могут происходить при обращении не туда, а когда у нас "собирающий" и "окружающий" массу содержимого блок не отвечает за "небазар" своих подчинённых, мы потом неделями отлаживаемся и ловим неописаные глюки отладчиков, в которых логику ещё надо найти.

Макс, это очень серьёзное заявление. Надо подкрепить логикой и конкретикой, чего мы должны бояться. Хотя это уклонение в сторону от нити топика. Если имеем физический адрес BAR-а в драйвере, отобразим его в виртуальный и дадим пользовательскому уровню для обращений к своему устройству, то что может пользователь поломать больше драйвера в своём устройстве ? Конечно, если другое устройство или чужую память нам дать потрогать, мы сможем грязно у кого-то в огороде потоптаться, но и драйвер может то же самое, если захочет, и с гораздо большими правами. И отлаживаться там гораздо сложнее, в ядре, дров можно наломать. ...Т.е. никто с такой проблемой "заступов" в продуктах MS не сталкивался ? Продолжать винить себя можно, искать свои глюки, но сильно непохоже. Записей таких левых пока не встречалось.

😉 Драйвер нам вначале всё выдал, а потом мы его трогаем в конце, чтобы отдать ресурсы обратно. Или вообще не трогаем, если программа завершается неожиданно. Хотя там тоже что-то ОС вызывает у драйвера, чтобы автоматически отключить устройство. Макс, подскажи(те) или ссылку дай(те) на теорию, как у вас глобально всё организовано, если вся работа повешена на драйвер. по-штатному. У нас используется концепция, что драйвер под Винду -- дело жуткое, переусложнённое, небезопасное, и отлаживаться внутри в ядре в тысячах строк кода вдобавок к драйверным и по шагам ходить -- смерти подобно. Для того MS с Intel и вводили много уровней привилегий и сертификацию драйверов, чтобы самые опасные действия были под максимальным контролем. Потому у нас в своём драйвере что-то как-то давно наляпано и отлажено, которое открывает наш девайс, ворует у Винды все BAR-ы и маппит их адреса phis/virt, передаёт на уровень MS VS особым запросом, и там всё в шоколаде для прикладного программиста, порушить уже что-то сложнее. Закрывается устройство -- всё размапливается и отдаётся системе, никаких признаков проблем не было. Вот кроме этих спорадических "прилётов" от отладчика, зависящих от траектории хождения по исходнику и портящих жизнь на начальных этапах оживления и разборок, пока всё не полетит. Вряд ли портятся маппинги, ибо в BAR-ах всё (память и регистры) работает глобально чисто, пока не закроем девайс. Это у MS (догадываюсь) просто записей по дефолту никуда нет, ибо дело опасное, а любые чтения для своих окон отладчика из любого региона они считают несмертельными, потому много подсматривающих недоотлаженных чтений, которые нам без теории объяснить невозможно -- и когда все-все окна закрыты, всё равно что-то выстреливает и мешает. В очередной раз хочется настройку "Выключить весь интеллект", ибо регулярно он перемудривает и мешает.

Вин7 сейчас, драйвер выдал отмапленный адрес BAR-а AC0000 в моё пространство адресов размером 4 М. Просто читаю из VS.2012 по указателю, сформированному из базы виртуального адреса и смещения внутри. Но глючит не при обращении в BAR -- оно честно происходит, а где-то рядом. Прилетают или чтения по 4 байта из адресов 18, 10, 08, или из какого-то мусорного типа В31870, в зависимости от места, но первые 3 чаще. Это автор прошивки видит в ЛА. В принципе, там выше/ниже в памяти всё от моего процесса, стек, данные, код, но пересекаться они не должны. Тем более, что обход "страшных" мест выше уровнем всё нивелирует. Из Убунты на другой плате ребята тоже "делали" 4 чтения, которых не хотели -- VS Code. Долго разбирались, концов в коде не нашли, тем более, что дизассемблера там нет, и с ним всё тоже у меня меняется...

Перекиньте этот запрос в более подходящую ветку, если я пока что не нашёл её. Наверняка, с этим уже кто-то сталкивался и как-то порешал. Глобально -- есть устройство на PCI, управляемое через ПЛИС, ты ходишь в тестовом ПО по шагам, и в BAR-ы прилетают обращения R/W по дурацким адресам, которые ну никак не следуют из кода исполнения. Ассемблер смотришь -- нет там ничего опасного. Но виснет регулярно напрочь, ибо это не предусмотрено алгоритмами работы. Если обходить это место выше уровнем функций, то ничего страшного не происходит. А чем ближе к железу опускаешься, тем вероятнее встретить эти "выстрелы", которые, в принципе, повторяются, но адреса у себя найти не выходит. И в MS VS это бывает под Винду, и под Линуксом в MS Code, лет 10 точно эффект встречается, во всех версиях отладочного ПО MS. Не помогает удаление Autos, Locals, Memory, Call Stack, чтобы на каждом шаге отладчик не лез по записанным там адресам, которые, в принципе, и не глядели в наш BAR. Отладить отладчик -- дело немыслимое, но вдруг ключ в опциях кто-то нашёл, который выключает "левый интеллект" у него ? В старших MS Студиях я видел оценку времени исполнения следующей строки кода, это как-то заставляет отладчик "помудрить", но и в младших попроще всё падало давно. Какие методы лечения наработаны ? Оно же левое не предусмотрено никакими ТЗ, читает/пишет, что захочет, и нарушает алгоритм функционирования.

Я попробовал ещё одну версию "Xilinx_Vitis_2019.2_1024_1831.tar.gz" из закромов, Alt-Left не полегчало. А была "Xilinx_Vitis_2019.2_1106_2127.tar.gz". Накатывал Xilinx_Vivado_Vitis_Update_2019.2.1_1205_0436.tar.gz, тоже плохо. Решил завязать с "мантрами". Убито времени много и так. Как видно, все требования у Xilinx огульные, если они их потом не проверяют. "Xilinx_Unified_2020.2_1118_1232.tar" точно у меня ставилась на 7-ку, и работала. Видимо, в требованиях пишут то, на чём запускалось и пробовалось немного в самой фирме Xilinx, политически решённое. Ругаться не будем, хоть что-то хоть как-то дышит... С Покровом Пресвятой Богородицы !

Спасибо. Да, шаманство в наших переусложнённых системах, не особо удачно пытающихся объять необъятное, встречается регулярно. Прямой путь отладить им легче, он чаще встречается. Когда начинаешь ставить, оно пишет про необходимость Win 7 64 бита, но не знаю, проверяет ли. Win 7 стоит точно, SP 1. Это же и есть нужная 7. 1 ? Тем более, пускается там всё с первого раза. Но глюки у меня тоньше, тупиковые. У них такое регулярно -- закройте типа все приложения наши, и жмите "дальше", т.е. нет автоопределения запущенности, это тяжело. SSD -- это хорошо, но просто ускорит частоту метаний в поисках Alt-Left. Глюк какой-то более хитрый, если то работает, то пропадает. Глобально первая 2019.2 быстро компилила чужой проект МикроБлэйза, хотя мне обещали полчаса. В реестре я что-то почистил с "Xilinx", "Vivado", "Vitis", хотя есть подозрения, что в Линукс-подобных системах всё в основном лежит в файловой системе. В "C:\Users\я\.Xilinx\" тоже много было остатков, имена каталогов всех былых WS точно сохранялись после деинсталляций, убил всё. Может, и переставляться не надо, если знать, где настройки сидят ? И ".lock" пара была, хотя сообщений о недожидании их не выводилось в больших посмертных логах Java. И 2018.2 тоже находил в именах каталогов, но вроде уже сносил её перед 2019.2. С Альтерой могут не дружить Ксайлинксы ? У меня старые Эклипсы для Ниос так и не запускаются, для них Java не находится, хочет каталог 17-го Квартуса, которого давно нет. Это явно не конфликт с Альтерой, если она сама у себя запротиворечила. ...Вот поставилась после всех чисток в очередной раз 2019.2, проект сразу из примеров создал, Alt-Left не работает, но живое. Наверное, лучшее -- враг хорошего.

Похоже, сносить тоже нельзя, оно уходит в нечистое состояние, что-то помнит после себя. Вчера оба инсталла официально снёс, не запускался из них только 2021.1. Сегодня Vitis 2019.2 заново поставился, и не работает. Висит процесс Eclipse.exe, 25 % кушает, и молчит. Ещё раз пускаешь -- ещё один на 25%... Поначалу бывает и 70 %, но потом ровно 1 проц занят, это на полчаса, потом глобально плачет, что не вышло, имя лог-файла сообщает, но там непонятный стек вызовов Java, общая "!MESSAGE Application error". Похоже, у Xilinx спецы больше по ПЛИС, чем в тестировании установки и удаления. Думаю, какие ещё идеи могут быть, чтобы 2019 ожил...

Да, оно при открытии WS 2019.2 из 2021.1 сразу говорит: создано в ранней версии Vitis. Мы обновим, станет несовместимо с прошлой версией. Лучше импортируйте в новое WS. И действительно, не открывает WS в 2019.2 после 2021.1. 2019.2.1 накатил поверх 2019.2 -- не работает Alt-Left. И в 2021.1 в импортированном WS 2019.2 не работает Alt-Left, хотя поначалу в самодельном примере из предустановленных заготовок всё было чисто. Даже 2021.1 перестала запускаться, "понюхав" 2019.2 впервые... Xilinx и Склифосовский, похоже, однокоренные, страшно сырые. В закромах много чего, пробовать не перепробовать...

У нас есть пока только 2021.1, без обновлений. Целый день ставилось... В 1.5 раза тормознее 2019.2. И работает Alt-Left сразу же ! У них между workspace есть обратная совместимость ? Чтобы в 21 поработать, и в 19 открылось потом чисто ? Тут в закромах есть 22.1.2 ? Говорят, скачать официально невозможно. И обновления к 19.2 лучше бы, вдруг там Back полечат.

Переставилось. Всё 1 в 1 с этой картинкой. Но не работает Alt-Left. Может от лицензии такая мелочь зависеть ? Сам Vitis вроде не требует лицензии. У кого-то 2019.2 стоит ? Есть такая проблема ? Завтра попробую Xilinx_Unified_2021.1_0610_2318, просто проверить. Там же есть Vitis ?

Да, в других версиях Eclipse всё работало. Спецы по Eclipse тут бывают ? Почему у Vitis сломалось, неясно. Пробую переставиться. Даже не могу сформулировать запрос к Гуглу на то, что всегда работало. Есть 3 Eclipse для Nios от Альтеры, но они перестали пускаться, на Java ругается. Может, она сдохла ? Давно не трогал ничего. Нашёл файл "\Users\*\workspace\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi", в котором есть добавление обоих команд, "Open Declaration" и "Back", 5 и 3 раза, потом именно это видно в "Additional/Keys". Но в этом файле меняешь что-то, и без толку, переписывается поверх. Там, очень похоже, в тексте сохраняется состояние всего при выходе, но потом не читается, где-то ещё есть "основа". В одной из "Back" сумел переназначить на "C/C++ Source" и "C/C++ Editor" по Alt+Left, но не работает обратный переход всё равно.

Простите за низкий вопрос. У меня не работает возвращение Back в Xilix Vitis 2019.2. Open Declaration по F3 нормально переходит к определению, а Back обратно по Alt+Left не возвращается к символу. Сталкивался ли кто-нибудь с таким ? Всю жизнь Eclipse работал чётко в этом месте. В Window/Preferences Additional/Keys есть переназначение клавиш, там с "Open Declaration" 8 вариантов, без конфликтов. А с Back -- всего 4. Картинки приложить не могу, извините. Я вычислил дихотомией с удалением сочетаний клавиш, что в исходнике срабатывает "C/C++ Editor / C/C++ Source". Такой же пары для Back нет. Наверное, потому и не срабатывает, что-то забыли разработчики. Возможно как-то добавить в Eclipse нужную Back с "C/C++ Editor / C/C++ Source" ?

У меня не работает Back в Xilix Vitis 2019.2. Open Declaration по F3 нормально переходит к определению, а Back обратно по Alt+Left не возвращается к символу. Сталкивался ли кто-нибудь с таким ? Всю жизнь Eclipse работал чётко в этом месте. В Window/Preferences Additional/Keys есть переназначение клавиш, там с "Open Declaration" 8 вариантов, без конфликтов. А с Back -- всего 4. Картинки приложить не могу, извините. Я вычислил дихотомией с удалением сочетаний клавиш, что в исходнике срабатывает "C/C++ Editor / C/C++ Source". Такой же пары для Back нет. Наверное, потому и не срабатывает, что-то забыли разработчики. Возможно как-то добавить в Eclipse нужную Back с "C/C++ Editor / C/C++ Source" ?

Спасибо за наводку. В 2019.2 у меня глючило по-другому. Существующий проект с другого ПК открылся, я вышел из Vitis -- и в него больше не зайду, что-то не стыкуется. Стартовый экран появляется, несколько секунд шуршит -- и всё. И через полчаса выдаётся окошко, что лог сохранён в такой-то файл, но там лабуда неясная из Jav-ы. Строку "RECENT_WORKSPACES=ХХХ" убил -- полегчало.

Книги кто-то встречал по разработке ПО в Xilinx SDK для MicroBlaze ? Где какие галочки и файлы ставить, что нажимать ? Как вообще идёт процесс, "вид сверху" на все стадии ? Железо как-то мне скомпилили, софт моргает диодами при зашитии вместе с .bit, но начать отладку с main() не получается. В закромах бывает популярное для обучения ?

И что, нет ответа ? Xilinx очень серъёзная фирма, настроек у них тысячи и тысячи, если не миллионы, трудно найти нужное. И по Xilinx SDK такой же вопрос. В https://russianblogs.com/article/2497528163/ есть совет, но меняется не всё. Заголовки вкладок, меню очень мелкие. Хочется хотя бы глобальные кнопки "Ещё больше", "Чуть меньше" для дефолтных настроек каждой программы, но не для всей Винды.

У нас интернет на отдельном ПК, там ничего нельзя поставить, тем более Вивадо, чтобы качать через него. И версии последних лет не рекомендуются, ибо нестабильные. Где на https://github.com/Xilinx примеры ? Особо "examples" не находятся. Там дикие объёмы данных, на публичном сервере стыдно выкладывать. Скорее всего, всё это на xilinx.com с разделением прав, много закрытого. Допустим, я на Site Keyword Search (xilinx.com) вижу ссылку на rdf0287-zc706-pcie-trd-2015-4.zip (https://www.xilinx.com/member/forms/download/design-license.html?cid=417310&filename=rdf0287-zc706-pcie-trd-2015-4.zip), но она превращается в "403 Доступ запрещен". Кто сможет, зареган, скачайте файл этот, пожалуйста. Нужны прямые ссылки, куда лезет Вивадо к себе на сайт. И кто знает, Вообще, из https://www.xilinx.com/microblaze лезет корень получения информации ? Меня как программиста интересует, как писать ПО ко всему железу из МикроБлэйза, есть ли стандартные библиотеки для разных типов устройств Ксайлов, причём руками, без Линукс. Чтобы SDK/Vitis сами посмотрели на описание сборки, к чему доступается МБ, да накидали в свой создаваемый проект .h и .c нужных файлов. А на свои ядра уже мы сами что-то подобное напишем по стандарту. Где эти документы искать ? Найти пример к плате -- только начало.