И, наконец, утилита ecppack, в моём случае, формирует *.bit и *.svf. А svf я гружу через OpenOCD.
А так- глубоко не разбирался с файлами. Вот с timing reports - там забавно. Это я месяц сидел. Там в логе показывают всё о самой плохой цепи в каждом из тактовых доменов. Гипнотизируя сведения, можно догадаться, в каком файле и почему происходят задержки. Что приятно - все имена читаемые. Вот пример:
Как видим, есть полный путь в иерархии и точное имя цепи. На этом приятное заканчивается. Устранив проблему, получаем новую цепь. Список проблемных цепей, глубже, чем самая плохая, я получить не смог. И вот я месяц устранял проблему за проблемой, пока не довёл FMax с 64 до 125 МГц у Опенсорсного проекта.
Вот это я могу сказать. А остальное - прошу прощения, не совсем разбираюсь.
Впрочем, ARP очень простой протокол, не понимаю как для него сфитировалось 64МГц Fmax. Вот, для DHCP я бы однозначно сказал "верю".
Всё, разогнал. Теперь могу вкратце сказать, кто был виноват в том конкретном случае, помимо задержек от ОЗУ. Многобитные функции. 48 битное сравнение MAC, 32 битное сравнение IP с текущим, а также с FFFFFFFF для бродкаста. А ещё и с наложением маски подсети... Всё пришлось конвейеризировать.
Штатный опенсорсный проект собирает 48 и 32 битное значение MAC и IP соответственно, потом - сравнивает. Чтобы разогнать - по мере прихода байтов сравниваем. Потом - просто операцию "И" над шестью или четырьмя битами результатов побайтного сравнения выполняем.
Но это ещё не всё. У ARP таймауты есть. 2 секунды для ретрейнов и 30 для последней попытки. Они задавались в тиках 125 мегагерцового таймера. Итого у автора использовался 36 битный счётчик. Пришлось разбить его на три. Один генерит мегагерцовые тики, второй - килогерцовые, третий уже в миллисекундах таймауты отсчитывает. При такой разрядности каждого счётчика, быстродействие выходит в приемлемый диапазон
Ну, и прочие подобные уменьшения разрядности. Латтис и Yosys/NextPNR иначе не позволяют официальное решение найти. При этом проект с плохим FMax по факту работал. Но без гарантий.
Я тоже много разглядывал описания безумно дешёвых макеток на этой ПЛИС. К сожалению, из отзывов следует, что это - полуфабрикаты, которые надо дорабатывать. Не нашёл отзывов "Заработало", но ругачих - видел много.
Для Альтеровских ПЛИС с ARM всё было плохо. У меня есть DE0-Nano-SoC. Там чтобы начать компилить BareMetal приложения, надо отдельно покупать ARM Design Suite, Ну, если официально всё делать. Для Linux - можно GCC использовать. Но мой опыт работы с этой ПЛИС печальный. Там ПЛИС включена через несколько мостов от процессора. Поэтому одиночные запросы обрабатываются безумно медленно и с непредсказуемой задержкой. Это всё хорошо для потоковой обработки больших объёмов данных.
Когда возился с Xilinx (пробегала мимо макетка ZCU102, которую я для себя точно не смогу купить, но была возможность немного поиграть в неё) - там всё вставало вместе с Вивадой. Но там точно помню, что был ARM не девятый, а какой-то, более крутой. Боюсь соврать. Уж не 53-й ли?
"Старт" работ с ПЛИС в целом - это точно не тема статьи для Хабра в 2021 году. Всё общее уже давно написано. Здесь про старт работ с этим семейством. Вряд ли Вы сможете предложить свободно добываемую макетку на этом семействе дешевле, чем приведена в тексте. И в статье собрано всё, чтобы сесть и начать опыты именно с этим семейством. Без добывания лицензий, без каких-либо ещё плясок с бубном. При условии, что у Вас имеется общеПЛИСовый опыт, разумеется.
В заключении дословно сказано:
Мы познакомились с методикой быстрого старта работ с ПЛИС фирмы Lattice.
Чётко оговорено, что речь идёт о старте работ с ПЛИС фирмы Lattice, а не о ПЛИС, как явлении.
Хороший программист должен уметь работать с тем, что есть под рукой. Однажды мне доводилось дорабатывать систему, выкинув ЦАПы AD (они всё время горели) и вставив ШИМ и RC-цепочку. Плату выходного каскада ШИМа на базе двух оптронов я спаял заранее, в ангаре, а вот МГТФами в блок добавлять её надо было в лесу... Потому что аппаратура была в лесу, в сотнях километров от ангара. Короче, в результате накладок, пришлось греть дохлый паяльник на газовой плитке... Подогрел - припаял. Подогрел - припаял... Уметь полезно и такое
Программисту могут спустить указание: "Этот проект мы делаем на такой аппаратуре" (что было у меня вот прямо сейчас). В наше нелёгкое время могут кончиться чипы (кто бы мог подумать о таком ещё несколько лет назад?). Так что навык иметь - полезно.
Но при этом, если у меня есть выбор - я всегда настаиваю на том, что мне комфортней. Лично я настаиваю на Альтере (ну, или её наследниках). В этом проекте тоже несколько месяцев настаивал. Даже кое-что сделал на десятом Циклоне во время подготовки... И сейчас я настоял на том, что я веду разработку под Windows... Но если настоять не удаётся - рука у хорошего программиста должна быть набита на владение всем...
Наш Заказчик не из нашего ВУЗа, наш товарищ из Америки. Это я стилизовал ответ под цитату из фильма. Но реально - да, он из Штатов. К счастью, он дал нам разрешение на публикацию всего, что мы нароем, так как одна из его задач, как я понял - участвовать в развитии тех OpenSource проектов.
Цель, которую он преследует - разработка систем управления станками с ЧПУ. Пока мы просто набиваем руку по спущенным ТЗ. На платах стоят гигабитные PHY, плюс с ними можно работать через Open Source систему - нам велено на них тренироваться.
В личку - обязательно обращусь, когда сформулирую конкретные вопросы. Спасибо за предложение!
А я разве не это же самое в статье написал? И про Квартус, и про прочее в статье есть. Но в моём случае, я же написал, что Доктор сказал в морг Заказчик сказал Lattice... А для остальных - будет полезно подготовиться на случай, если правильные чипы кончатся. Другой момент, что они могут и не кончиться. Но и это я учёл во фразе "завтра может такую статью писать будет поздно". Не кончатся - и статья не нужна будет.
То есть, статья - не реклама Латтисов. Статья показывает, как быстро их освоить, в случае нужды. И это в ней особо подчёркнуто.
Что же до недели... Это я чтобы всё в Windows заработало неделю просидел. В Линуксе - в момент стартовать можно. И это отмечено. Но я сразу знал, что будут проблемы с FMax, и проект предстоит долгий. А долго сидеть под Линуксом лично мне не комфортно (и это тоже отмечено). Поэтому я предпочёл подготовить себе комфортное рабочее место для долгих опытов.
Мне почему-то кажется, что нет. По крайней мере, мне ничего такого не нашёл. В прошлой статье я приводил грустные картинки, как снимаю диаграммы настоящим анализатором. Благо на этой плате МНОГО ног, и все они - выходы. Но пробрасывать линии DBG транзитом из глубины через 3-4 модуля - то ещё занятие, разумеется. А после отладки - не забыть убрать везде.
Вот генератор PLL там уже есть неплохой. Но он консольный, поэтому и есть. Если дойдут руки до следующей статьи - опишу его. А интерактивного пока ничего не видел. Грустно всё там с этим делом.
Ну, наш Заказчик планирует в будущем RISC-V использовать. ПЛИС-то просторная, если по большому счёту. Места всем (в разумных пределах) хватит. Вот с предельными частотами - всё несколько хуже.
Но что касается фирменного софта, то взяли мы этот самый проект verilog-ethernet, собрали в Yosys/NextPNR. Получили FMax 62 МГц после упаковки. Поставили фирменный Diamond. Собрали там. Там, на самом деле, Place and Route до конца не дошёл, так как были какие-то проблемы с PLL. Но их я даже не стал решать. Потому что на выходе из синтезатора (то есть, чисто на логических задержках, без транспортных), по логам тот же проект давал сходное значение FMax.
Сейчас оптимизируем ручками. Отчёты у Yosys/NextPNR добротные, помогают в поиске критических мест. Вчера уже 110 МГц в логах видел. Правда, и при 62 он по факту работает. Но Заказчику подавай гарантии. Так что оптимизируем... Я предлагал заменить работу с байтами на 16 или 32 битные слова, чем снизить требования к частоте, но Заказчик хочет разогнать байтовый поток. Ему виднее.
В 2006-м внедряли мы в систему для газоанализатора поддержку LUA. И потом переписывали плюсовые алгоритмы, сделанные на первом этапе, на этот скрипт. Обработка ошибок стала занимать 2/3 кода и загромождать пространство так, что основной алгоритм стало не видно. Может, с тех пор что-то и поменялось, но мой опыт говорит, что вряд ли "гораздо проще на нём писать". Скорее, кто к чему привык.
Мне его пришлось поставить, чтобы запускать ncat, так как исходный проект для ПЛИС рекомендует вести тестирование с помощью netcat. Гугль сказал, чтобы я под Windows использовал ncat и не мучился.
Я точно не изучал, как там всё устроено, но при установке NMap, он предлагает поставить всё тот же NPap. Так что не удивлюсь, если он через этот же драйвер всё и реализует. Но и не поручусь.
Пока только могу сказать, что там у автора идёт две ОЗУшины ARP кэша, потом - куча логики и только потом результат защёлкивается. Кое-что уже удалось конвейеризировать, уже FMax не 64, а 83 МГц. Завтра продолжим разбираться, что можно сделать. На данный момент, я не понимаю, как имеющаяся ветка вносит нынешнюю задержку. Возможно, это вообще транспортная задержка, возникающая при разводке.
Тут кроме самого функционала, как я отметил, очень важно, что когда все галки сняты - к адаптеру никто не полезет. Их просто не пустит система. Если же поставить буквально одну галку IPv4, то тут же начинают лезть всяческие пакеты от различных протоколов в больших количествах.
В реальной жизни это не так страшно. Но во время отладки, особенно когда на том конце подключён логический анализатор с не самой развитой системой фильтрации (а при работе с ПЛИС Lattice под Open Source средствами разработки особого выбора нет) - все эти пакеты портят жизнь.
При таком же подходе, получил сетевушку в монопольный доступ и отлаживай всё, контролируя каждый пакет в кабеле. Даже ARP пакеты - только вручную. Чтобы проверить поведение отлаживаемой системы при разных сценариях. Собственно, сейчас мне предстоит чинить реализацию этого ARP, так как при требуемой частоте 125 МГц, штатное (по мнению Заказчика) решение с Гитхаба даёт на требуемой ПЛИС параметр FMax = 64 МГц, и критические цепи относятся как раз к ARP. Эту подсистему придётся сильно перепахивать.
Вот когда будет отлажено - тогда уже можно выпускать всё в реальный мир, с кучей левого трафика и автоматической работой с той же ARP.
Дополню, что в той статье скорее рассказывается про GPIO и группы контактов, но по факту, эта библиотека связывает эти самые GPIO с классами прочих устройств (таймеров, UART, SPI, I2C...). Потому что в наше время линии этих устройств могут быть выведены на произвольные ноги. И вот GPIO этой библиотеки прекрасно всё связывает. Плюс драйверы устройств написаны весьма и весьма компактно. В общем, mcupp охватывает так много всего, что я сам ею пользуюсь, и информирую о её мощи при любом удобном случае. Так что после прочтения статьи по ссылке, надо понимать, что статья показывает только часть возможностей.
Недавно я общался с @DSarovsky , он делает библиотеку, похожую по идеологии, но базирующуюся на более современных стандартах C++. Я там смотрел GPIO и USB. GPIO реализовано в соответствии с заветами товарища Чижова, а USB у Чижова нет, не сравнить. Формирование дескрипторов - замечательное и простое. Работа с конечными точками - понятная. Скорость - предельно возможная, за счёт использования двойного буфера. Про драйвера других устройств пока не скажу, не довелось изучить в бою.
А ведь и правда! Мы чего-то увлеклись. Просто исходно Заказчик хотел, чтобы код был перемещаемым от рождения. Ключики не давали правильного эффекта, поэтому мы начали менять генератор кода. И сначала всё было даже замечательно. Дальше Заказчик стал присылать всё более и более заковыристые конструкции... Добавляемый для этого код, распознающий каждый раз диапазон, стал всё более и более убойным. Вставляемых инструкций при вычислениях средней сложности становилось больше, чем рабочих!
И вот тут Заказчик сдался. Он согласился на то, чтобы код был не честно перемещаемым, а готовился перед прошивкой (кстати, абдейт прошивки и два банка - только одна красивая иллюстрация, по ТЗ он должен работать где угодно). Но к тому времени, настроение было такое (и команда проекта этому соответствовала), что надо продолжать править компилятор. Вот и понеслось. Что, собственно, и получилось.
Подкупало и то, что получившийся метод сохранял CLANGовскую возможность использования команд movt/movw для загрузки 32 битных адресов, что эффективнее, чем GCCшный вариант... Хотя, лично я признаю их эффективность, но не считаю её повышение уж слишком высоким. Но и правку делал не я. Я к тому времени уже был на другом проекте. Есть у получившегося метода и другие потенциальные плюсы, но в действующее ТЗ они всё равно не входили.
Спасибо, что сняли шоры с наших глаз. Сегодня было много проверок в GCC с Вашими ключиками. Пробовали разный тестовый код и разные уровни оптимизации, приговаривая: "Ну тут-то не поможет". Пока помогло везде... Склоняемся к тому, чтобы всё переделать...
И такая идея у нас была. Действительно, если в ELF сохранить информацию обо всех символах, то можно узнать многое.
Но дело в том, что наш подход концептуально позволяет выполнять очень широкий набор операций. Мы фактически расставляем метки и группируем их по сортам.
Например, коррекция адреса - это только одна из возможностей. В статье приводился пример исправления пары инструкций, где адрес разбит на две части и хитро перемешан с битами инструкции. Возможны и другие варианты.
Кроме того, исправление компилятора не было для нас проблемой, так что мы решили пройти по сложному, но многообещающему пути.
Оххх. К сожалению, на большинство вопросов я не могу дать ответ. Я работаю на уровне разработчика несложных вещей.
Yosys на выходе даёт JSON файл примерно такого вида:
Кажется, он умеет выдавать не только JSON, но я особо не разбирался. NextPNR берёт его и выдаёт на выход *.config примерно такого вида
И, наконец, утилита ecppack, в моём случае, формирует *.bit и *.svf. А svf я гружу через OpenOCD.
А так- глубоко не разбирался с файлами. Вот с timing reports - там забавно. Это я месяц сидел. Там в логе показывают всё о самой плохой цепи в каждом из тактовых доменов. Гипнотизируя сведения, можно догадаться, в каком файле и почему происходят задержки. Что приятно - все имена читаемые. Вот пример:
Как видим, есть полный путь в иерархии и точное имя цепи. На этом приятное заканчивается. Устранив проблему, получаем новую цепь. Список проблемных цепей, глубже, чем самая плохая, я получить не смог. И вот я месяц устранял проблему за проблемой, пока не довёл FMax с 64 до 125 МГц у Опенсорсного проекта.
Вот это я могу сказать. А остальное - прошу прощения, не совсем разбираюсь.
Всё, разогнал. Теперь могу вкратце сказать, кто был виноват в том конкретном случае, помимо задержек от ОЗУ. Многобитные функции. 48 битное сравнение MAC, 32 битное сравнение IP с текущим, а также с FFFFFFFF для бродкаста. А ещё и с наложением маски подсети... Всё пришлось конвейеризировать.
Штатный опенсорсный проект собирает 48 и 32 битное значение MAC и IP соответственно, потом - сравнивает. Чтобы разогнать - по мере прихода байтов сравниваем. Потом - просто операцию "И" над шестью или четырьмя битами результатов побайтного сравнения выполняем.
Но это ещё не всё. У ARP таймауты есть. 2 секунды для ретрейнов и 30 для последней попытки. Они задавались в тиках 125 мегагерцового таймера. Итого у автора использовался 36 битный счётчик. Пришлось разбить его на три. Один генерит мегагерцовые тики, второй - килогерцовые, третий уже в миллисекундах таймауты отсчитывает. При такой разрядности каждого счётчика, быстродействие выходит в приемлемый диапазон
Ну, и прочие подобные уменьшения разрядности. Латтис и Yosys/NextPNR иначе не позволяют официальное решение найти. При этом проект с плохим FMax по факту работал. Но без гарантий.
Я тоже много разглядывал описания безумно дешёвых макеток на этой ПЛИС. К сожалению, из отзывов следует, что это - полуфабрикаты, которые надо дорабатывать. Не нашёл отзывов "Заработало", но ругачих - видел много.
Для Альтеровских ПЛИС с ARM всё было плохо. У меня есть DE0-Nano-SoC. Там чтобы начать компилить BareMetal приложения, надо отдельно покупать ARM Design Suite, Ну, если официально всё делать. Для Linux - можно GCC использовать. Но мой опыт работы с этой ПЛИС печальный. Там ПЛИС включена через несколько мостов от процессора. Поэтому одиночные запросы обрабатываются безумно медленно и с непредсказуемой задержкой. Это всё хорошо для потоковой обработки больших объёмов данных.
Когда возился с Xilinx (пробегала мимо макетка ZCU102, которую я для себя точно не смогу купить, но была возможность немного поиграть в неё) - там всё вставало вместе с Вивадой. Но там точно помню, что был ARM не девятый, а какой-то, более крутой. Боюсь соврать. Уж не 53-й ли?
"Старт" работ с ПЛИС в целом - это точно не тема статьи для Хабра в 2021 году. Всё общее уже давно написано. Здесь про старт работ с этим семейством. Вряд ли Вы сможете предложить свободно добываемую макетку на этом семействе дешевле, чем приведена в тексте. И в статье собрано всё, чтобы сесть и начать опыты именно с этим семейством. Без добывания лицензий, без каких-либо ещё плясок с бубном. При условии, что у Вас имеется общеПЛИСовый опыт, разумеется.
В заключении дословно сказано:
Чётко оговорено, что речь идёт о старте работ с ПЛИС фирмы Lattice, а не о ПЛИС, как явлении.
Хороший программист должен уметь работать с тем, что есть под рукой. Однажды мне доводилось дорабатывать систему, выкинув ЦАПы AD (они всё время горели) и вставив ШИМ и RC-цепочку. Плату выходного каскада ШИМа на базе двух оптронов я спаял заранее, в ангаре, а вот МГТФами в блок добавлять её надо было в лесу... Потому что аппаратура была в лесу, в сотнях километров от ангара. Короче, в результате накладок, пришлось греть дохлый паяльник на газовой плитке... Подогрел - припаял. Подогрел - припаял... Уметь полезно и такое
Программисту могут спустить указание: "Этот проект мы делаем на такой аппаратуре" (что было у меня вот прямо сейчас). В наше нелёгкое время могут кончиться чипы (кто бы мог подумать о таком ещё несколько лет назад?). Так что навык иметь - полезно.
Но при этом, если у меня есть выбор - я всегда настаиваю на том, что мне комфортней. Лично я настаиваю на Альтере (ну, или её наследниках). В этом проекте тоже несколько месяцев настаивал. Даже кое-что сделал на десятом Циклоне во время подготовки... И сейчас я настоял на том, что я веду разработку под Windows... Но если настоять не удаётся - рука у хорошего программиста должна быть набита на владение всем...
А данная статья ему в этом поможет...
Я аж испугался. Проверил. Есть название OrangeCrab над самой фотографией.
Наш Заказчик не из нашего ВУЗа, наш товарищ из Америки. Это я стилизовал ответ под цитату из фильма. Но реально - да, он из Штатов. К счастью, он дал нам разрешение на публикацию всего, что мы нароем, так как одна из его задач, как я понял - участвовать в развитии тех OpenSource проектов.
Цель, которую он преследует - разработка систем управления станками с ЧПУ. Пока мы просто набиваем руку по спущенным ТЗ. На платах стоят гигабитные PHY, плюс с ними можно работать через Open Source систему - нам велено на них тренироваться.
В личку - обязательно обращусь, когда сформулирую конкретные вопросы. Спасибо за предложение!
А я разве не это же самое в статье написал? И про Квартус, и про прочее в статье есть. Но в моём случае, я же написал, что
Доктор сказал в моргЗаказчик сказал Lattice... А для остальных - будет полезно подготовиться на случай, если правильные чипы кончатся. Другой момент, что они могут и не кончиться. Но и это я учёл во фразе "завтра может такую статью писать будет поздно". Не кончатся - и статья не нужна будет.То есть, статья - не реклама Латтисов. Статья показывает, как быстро их освоить, в случае нужды. И это в ней особо подчёркнуто.
Что же до недели... Это я чтобы всё в Windows заработало неделю просидел. В Линуксе - в момент стартовать можно. И это отмечено. Но я сразу знал, что будут проблемы с FMax, и проект предстоит долгий. А долго сидеть под Линуксом лично мне не комфортно (и это тоже отмечено). Поэтому я предпочёл подготовить себе комфортное рабочее место для долгих опытов.
Мне почему-то кажется, что нет. По крайней мере, мне ничего такого не нашёл. В прошлой статье я приводил грустные картинки, как снимаю диаграммы настоящим анализатором. Благо на этой плате МНОГО ног, и все они - выходы. Но пробрасывать линии DBG транзитом из глубины через 3-4 модуля - то ещё занятие, разумеется. А после отладки - не забыть убрать везде.
Вот генератор PLL там уже есть неплохой. Но он консольный, поэтому и есть. Если дойдут руки до следующей статьи - опишу его. А интерактивного пока ничего не видел. Грустно всё там с этим делом.
Ну, наш Заказчик планирует в будущем RISC-V использовать. ПЛИС-то просторная, если по большому счёту. Места всем (в разумных пределах) хватит. Вот с предельными частотами - всё несколько хуже.
Спасибо! Сейчас посмотрю!
Но что касается фирменного софта, то взяли мы этот самый проект verilog-ethernet, собрали в Yosys/NextPNR. Получили FMax 62 МГц после упаковки. Поставили фирменный Diamond. Собрали там. Там, на самом деле, Place and Route до конца не дошёл, так как были какие-то проблемы с PLL. Но их я даже не стал решать. Потому что на выходе из синтезатора (то есть, чисто на логических задержках, без транспортных), по логам тот же проект давал сходное значение FMax.
Сейчас оптимизируем ручками. Отчёты у Yosys/NextPNR добротные, помогают в поиске критических мест. Вчера уже 110 МГц в логах видел. Правда, и при 62 он по факту работает. Но Заказчику подавай гарантии. Так что оптимизируем... Я предлагал заменить работу с байтами на 16 или 32 битные слова, чем снизить требования к частоте, но Заказчик хочет разогнать байтовый поток. Ему виднее.
В 2006-м внедряли мы в систему для газоанализатора поддержку LUA. И потом переписывали плюсовые алгоритмы, сделанные на первом этапе, на этот скрипт. Обработка ошибок стала занимать 2/3 кода и загромождать пространство так, что основной алгоритм стало не видно. Может, с тех пор что-то и поменялось, но мой опыт говорит, что вряд ли "гораздо проще на нём писать". Скорее, кто к чему привык.
Мне его пришлось поставить, чтобы запускать ncat, так как исходный проект для ПЛИС рекомендует вести тестирование с помощью netcat. Гугль сказал, чтобы я под Windows использовал ncat и не мучился.
Я точно не изучал, как там всё устроено, но при установке NMap, он предлагает поставить всё тот же NPap. Так что не удивлюсь, если он через этот же драйвер всё и реализует. Но и не поручусь.
Пока только могу сказать, что там у автора идёт две ОЗУшины ARP кэша, потом - куча логики и только потом результат защёлкивается. Кое-что уже удалось конвейеризировать, уже FMax не 64, а 83 МГц. Завтра продолжим разбираться, что можно сделать. На данный момент, я не понимаю, как имеющаяся ветка вносит нынешнюю задержку. Возможно, это вообще транспортная задержка, возникающая при разводке.
Тут кроме самого функционала, как я отметил, очень важно, что когда все галки сняты - к адаптеру никто не полезет. Их просто не пустит система. Если же поставить буквально одну галку IPv4, то тут же начинают лезть всяческие пакеты от различных протоколов в больших количествах.
В реальной жизни это не так страшно. Но во время отладки, особенно когда на том конце подключён логический анализатор с не самой развитой системой фильтрации (а при работе с ПЛИС Lattice под Open Source средствами разработки особого выбора нет) - все эти пакеты портят жизнь.
При таком же подходе, получил сетевушку в монопольный доступ и отлаживай всё, контролируя каждый пакет в кабеле. Даже ARP пакеты - только вручную. Чтобы проверить поведение отлаживаемой системы при разных сценариях. Собственно, сейчас мне предстоит чинить реализацию этого ARP, так как при требуемой частоте 125 МГц, штатное (по мнению Заказчика) решение с Гитхаба даёт на требуемой ПЛИС параметр FMax = 64 МГц, и критические цепи относятся как раз к ARP. Эту подсистему придётся сильно перепахивать.
Вот когда будет отлажено - тогда уже можно выпускать всё в реальный мир, с кучей левого трафика и автоматической работой с той же ARP.
Ну, тут главное - знать, что "так вообще можно было". А там - каждый под свои задачи найдёт что-то.
Огромное спасибо за дополнение!
Дополню, что в той статье скорее рассказывается про GPIO и группы контактов, но по факту, эта библиотека связывает эти самые GPIO с классами прочих устройств (таймеров, UART, SPI, I2C...). Потому что в наше время линии этих устройств могут быть выведены на произвольные ноги. И вот GPIO этой библиотеки прекрасно всё связывает. Плюс драйверы устройств написаны весьма и весьма компактно. В общем, mcupp охватывает так много всего, что я сам ею пользуюсь, и информирую о её мощи при любом удобном случае. Так что после прочтения статьи по ссылке, надо понимать, что статья показывает только часть возможностей.
Недавно я общался с @DSarovsky , он делает библиотеку, похожую по идеологии, но базирующуюся на более современных стандартах C++. Я там смотрел GPIO и USB. GPIO реализовано в соответствии с заветами товарища Чижова, а USB у Чижова нет, не сравнить. Формирование дескрипторов - замечательное и простое. Работа с конечными точками - понятная. Скорость - предельно возможная, за счёт использования двойного буфера. Про драйвера других устройств пока не скажу, не довелось изучить в бою.
А ведь и правда! Мы чего-то увлеклись. Просто исходно Заказчик хотел, чтобы код был перемещаемым от рождения. Ключики не давали правильного эффекта, поэтому мы начали менять генератор кода. И сначала всё было даже замечательно. Дальше Заказчик стал присылать всё более и более заковыристые конструкции... Добавляемый для этого код, распознающий каждый раз диапазон, стал всё более и более убойным. Вставляемых инструкций при вычислениях средней сложности становилось больше, чем рабочих!
И вот тут Заказчик сдался. Он согласился на то, чтобы код был не честно перемещаемым, а готовился перед прошивкой (кстати, абдейт прошивки и два банка - только одна красивая иллюстрация, по ТЗ он должен работать где угодно). Но к тому времени, настроение было такое (и команда проекта этому соответствовала), что надо продолжать править компилятор. Вот и понеслось. Что, собственно, и получилось.
Подкупало и то, что получившийся метод сохранял CLANGовскую возможность использования команд movt/movw для загрузки 32 битных адресов, что эффективнее, чем GCCшный вариант... Хотя, лично я признаю их эффективность, но не считаю её повышение уж слишком высоким. Но и правку делал не я. Я к тому времени уже был на другом проекте. Есть у получившегося метода и другие потенциальные плюсы, но в действующее ТЗ они всё равно не входили.
Спасибо, что сняли шоры с наших глаз. Сегодня было много проверок в GCC с Вашими ключиками. Пробовали разный тестовый код и разные уровни оптимизации, приговаривая: "Ну тут-то не поможет". Пока помогло везде... Склоняемся к тому, чтобы всё переделать...
Мы внесли изменения для платформы ARM. То есть, сделали патч. Но как я уже писал в ветке ниже - пока что всё делали локально.
И такая идея у нас была. Действительно, если в ELF сохранить информацию обо всех символах, то можно узнать многое.
Но дело в том, что наш подход концептуально позволяет выполнять очень широкий набор операций. Мы фактически расставляем метки и группируем их по сортам.
Например, коррекция адреса - это только одна из возможностей. В статье приводился пример исправления пары инструкций, где адрес разбит на две части и хитро перемешан с битами инструкции. Возможны и другие варианты.
Кроме того, исправление компилятора не было для нас проблемой, так что мы решили пройти по сложному, но многообещающему пути.