Ну STM32 примерно так и работает. А вот GD32, если видит в этом поле входящего пакета ноль, то игнорирует такой пакет. При этом не выявлено каких-либо флагов ошибки. По крайней мере, мы ставили точки останова на участки, где в дескрипторе вернулся признак ошибки. Ни разу не сработали. И те счётчики ошибок в портах, что мы мониторили - не увеличивались. А пакеты именно с таким признаком именно GD32 - теряли.
Что касается флагов ошибок - может не то смотрели, может где-то что-то и отмечалось. Но что настоящий STM32 в тех же ситуациях ничего не терял - факт. Отключение проверки контрольных сумм заголовков решает проблему - тоже факт.
Это что. Мне однажды свалился баннер - купите отечественный RISC-V контроллер. Ну я зашёл. Ага! Не купите, а запишитесь на покупку. И когда он будет доступен, то у него будет 8 килобайт флэша... При том, что по моим ощущениям, RISC-V с Compressed командами требует в среднем вдвое больше памяти для кода, чем Cortex M. А самая базовая голубая пилюля 64К флэша на борту имеет...
В общем, всё познаёмся в сравнении. Тут - пойманные проблемы неприятны, но пока не смертельны.
В полном соответствии с логикой STM32, с которым эти контроллеры функционально совместимы. Причём настолько совместимы, что вот у STM32F10X MAC намного проще, чем у STM32F4.... Поэтому у GD32F107 MAC похож на STM32F107, а у GD32F450 - на STM32F4. У первой парочки, скажем, нет расширенных дескрипторов.
А так - там на уровне MAC ещё и аппаратная поддержка PTP имеется. У всех выше перечисленных. И опять же, парочка STM/GD32F107 имеет логику PTP попроще, А которые F4 - покруче. Всё совместимо.
У меня такой печальный опыт общения с первыми линиями разных техподдержек, что я без нужды к ним не обращаюсь больше. Обычно никому это не надо у производителя. А если кому-то и надо, то пока до него прорвёшься... А смысл?
Конечным пользователям будет полезно - я задокументировал. Заказчик в Штатах тоже в курсе теперь. Возможно, он с производителем свяжется.
Да я тоже плаваю. Для себя я решил, что всей этой штукой буду пользоваться только для того, чтобы генерить шинно ориентированную основу. А остальное - навешивать снаружи.
Потому что писать модули на MiGen... Я понял, как народ это делает, но мне кажется это противоестественным. Использовать готовые процессор и контроллер ОЗУ от LiteX - те ПЛИС, с которыми мне пока что довелось работать, дают с ними дикие тормоза, а процессор ещё и расходует массу ресурсов. Мы даже DHCP в итоге на трёх простеньких автоматах реализовали, чтобы процессор не внедрять ради него. А нормальные ПЛИС имеют свои похожие вещи со своими процессорными ядрами, там и без LiteX можно обойтись.
В общем, кроме как организовать шинную основу для ПЛИС, где этого исходно не предусмотрено - не вижу, зачем этот LiteX может пригодиться. Но вот шины на нём реализуются прилично. Этим пользоваться буду... А остальное - навешивать Верилоговское на эту основу. Как в статьях описано...
Ну да. Любая задача имеет множество решений. И вот у ПЛИС. Те же мои статьи с анализаторами. Сколько стоит купить готовый анализатор USB? А на ПЛИС - я уже на базе универсальной платформы сделал целых два анализатора. USB и Ethernet на два канала (для проверки EtherCAT). Причём Ethernet получился за несколько дней из USB. На базе одного и того же железа, только обвязка разная втыкается и прошивка заливается.
ПЛИС - гибкая штука для штучных решений. А штучные решения нужны часто. Это как 3D принтер. Массовые вещи на нём тоже делать бесполезно.
В рамках этого цикла, ну попробовал я систему LiteX. И поделился с читателями тем, что мне показалось там классным. А выводы к этой статье, показывают, какие я там вижу проблемы. Причём там чётко сказано, что проблемы, похоже, тупиковые. Если только не придёт кто-то, кто раскроет мне глаза...
Вот в комментариях про производительность USB на STM32... Рылся я, рылся, ничего в сети нет. Опубликовал... Рррраз! Сразу три отечественных библиотеки в комментариях подкинули! Так что если нет решения - все увидят, куда соваться не стоит. Есть решение - оно будет зафиксировано, а до того никакой поисковик не обнаруживал его. В любом случае, стоит опубликовать.
Но даже при наличии тупиковых проблем, шинная система у LiteX классная и шустрая. На неё нанизывать блоки - вполне можно. А это упрощает и ускоряет разработку. В этом практическая польза от цикла.
Какой SDRAM, когда DD3 уже снимается (посмотрите графики производства).
Да, но сколько он стоит и какие требования к плате, на которой он установлен? И на данной конкретной плате стоит именно SDRAM. Но даже и DDR3. Посмотрите таблицы по той ссылке. Для DDR3 производительность иногда лучше, но сильно не всегда.
Какой VGA (из прочих статей)?
Это точно. В выводах к той статье так и было написано: "Больше с VGA мы дела не имеем, глупости это, теперь все это сами видели". А в уме я держал: "Перейдём к HDMI - сошлюсь на все эти формулы, так как они все будут точно такими же". Половину той статьи занимал вывод критически важных параметров.
На GPU производительность просто чудовищная.
Тут надо смотреть в комплексе. Производительность - один из параметров. А энергопотребление? А автономность? А цена? В первой статье я отмечал, что тут ПЛИС + плата + два ОЗУ + флэшка + генератор + два гигабитных Ethernet (PHY и обвязка) + куча барахла... Всё это было куплено менее, чем за тысячу рублей, включая доставку. Сейчас цены плавающие, так что текущую смотреть не буду. Будем ориентироваться на стабильные времена. Потому что плавают цены на всё. На GPU - тоже.
Порог входа в системное программирование под Линукс гораздо выше. А конвейер GPU это просто вывих мозга.
То есть, трудозатраты (а значит - цена разработки) существенно выше. Специалистов тоже искать сложнее. Странное преимущество.
Последний аргумент, если я ничего не путаю, станции и марсоходы NASA летают и бегают без плисин и микроконтроллеров.
Да, но наш Заказчик конкретно на эту ПЛИС не марсоход делает, а станки с ЧПУ. Не со всеми его задумками я согласен, но деньги платит он. Заказчик, как я уже отмечал в комментариях к прежним статьям, не из России. А так... Цены на космическую технику таковы, что ещё недавно их могло выкладывать только государство. Поэтому ориентироваться на марсоходы, как на основу для массового решения... Ну, я бы не стал. Помню, фирма Fujutsu перешла на альтернативный формат сервометок, который создал дичайшие трудности. Аргументация была - это снижает себестоимость жёсткого диска на сколько-то там центов... Даже не на доллар! Правда, в том конкретном случае, они прогадали.
Всё верно, но то, что можно написать один компилятор вместо N-компиляторов из каждого формата - не главное. TVM - в первую очередь мощный фреймворк для создания компилятора. Ведь для «N-форматов» есть еще ONNX, в который можно сконвертировать почти каждый формат, но не кросс-компилятором, а просто конвертерами.
Ну и самое главное – это оптимизации на разных уровнях – от вычислительного графа до аппаратных блоков и профилирование через встроенные инструменты, поддержка различных платформ. Ну и, конечно, гибкость самого TVM и и его активное развитие.
К HDMI я пока не знаю, с какой стороны лучше зайти. Поэтому давайте покажу текущие мысли. Может мы даже чего-то вместе придумаем, куда лучше двигаться.
С одной стороны, было бы здорово рассказать, как выводить свою картинку через HDMI, но это будет пересказ ряда уже существующих статей. Неплохая статья уже есть на сайте Марсоход. Реализация HDMI в ПЛИС (marsohod.org) . В ней некоторые вещи не очень раскрыты, так как автор считает их само собой разумеющимися. Их бы раскрыть, и... Опять же, эта статья ссылается на fpga4fun.com - HDMI
Но во-первых, писать пересказ скучно, во-вторых, для реальной жизни важнее что-то, легко встраиваемое в любую типовую систему. Есть ещё в-третьих. Я мечтаю когда-нибудь сделать красивый и чётко документированный эмулятор БКшки (что добавляет требований по моим хотелкам к конкретным видеорежимам для качественной поддержки графики и кадрового прерывания), но это уже мечты из области идеала. Пока хватит первых двух пунктов.
Так вот. Самое логичное, что видно при движении в эту сторону - стандартные Litexовские контроллеры алфавитно-цифрового и графического дисплеев. Но там я пока буксую на том, что их надо подключать к Native шине SDRAM, а у неё производительность пока что выходит такая, что страшно её показывать. Документации никакой. Вот, сижу, потихоньку тыкаюсь, чтобы получить все сведения по возможным режимам работы, по настройкам частот, по настройкам режимов и прочему. Чтобы было всё обосновано хотя бы, а не "попробовал, кажется работает". Короче, пока тоже нечего описывать. Что уже могу собрать, то другим советовать стыдно. А остальное - тыкаюсь потихоньку, чтобы освоить.
Заказчик Латтисовского проекта сказал часы на это не расходовать, делать всё без базовой системы. Так что теперь разбираюсь в свободное время. Набегами. Было бы полезно с кем-то пообщаться, чтобы в диалоге во всём разобраться. А может где есть документация, на которую я до сих пор не смог выйти, как не мог выйти на OSS CAD Suite.
Посмотрел, что это такое. Наконец-то версия под Windows свежая. Всё, что я раньше находил, было древним, либо содержало только сборки под Linux. Возможно, тогда Вы и правы. Надо будет изучить.
Понимаете. Сначала я работал в RT-11. Потом - в MS DOS и оболочке Dos Navigator. Дальше были Win3.1, Win95, NT4.0 и далее по нарастающей. Я уже привык к файловой иерархии такого вида. Мне не комфортно в Линуксе. Я там нервничаю. А как можно писать нормальный код, когда нервничаешь? Тем более, нервничаешь от того, чего можно избежать?
При работе в Windows через FAR, я чувствую себя комфортно и думаю только о коде. Я стар. Переучиваться бесполезно. MC меня выбешивает своими особенностями, если что. Дерево файлов - тоже выбешивает. Это не лечится. Это надо принять.
Вот для тех, кому переучиваться бесполезно, я и поделился опытом. А что остальным это не нужно - вынес в заглавный абзац.
А, то есть, мы о разных асинхронностях. Вы на уровне тактирования, а я - на уровне транзакций. Пока не завершится предыдущая транзакция - новую начинать нельзя. Сигнал завершения транзакции обязателен.
К счастью, Википедия допускает дикое число знаений слова "Асинхронность".
Но в целом - да, не совсем хороший термин выбрал. Многозначный. Я подумаю, как поправить его, не корёжа текст.
Если не выставить ACK - Master дальше не пойдёт. ACK обязателен.
Это у AVALON линия Wait опциональна. А тут - без ACK ну никак. По крайней мере, из моего опыта это следует. Сейчас порыскал по спецификации. Не нашёл ничего опционального на эту тему. ACK, ERR или хотя бы RTY. То есть, отклик обязателен.
Ну, тут главное - видеть, что не на пустоту стараешься. Так как на подготовку сил уходит много... Если реакции почти ноль - одна из возможных причин, что никто и не читает. и тогда зафиксировать знания можно в более простом формате, не развёрнуто, а тезисно, внутренним документиком. Именно поэтому и желательно отмечаться, что "угу, тема интересная"...
Эта пара статей как раз была фиксирующая глобальные знания. Чтобы преодолеть страх перед непонятными Питонами в рамках работы с ПЛИС. Дальше - уже по накатанной. Ну, раз есть те, кому интересно - будем разбираться вместе... Пока интерес совсем не угаснет.
Тестили... А сейчас по указанию. Заказчика, даже на пробу сделали версию, которая при старте отключает поддержку гигабита в опциях Auto Negotiate. Тем самым, зажимаем скорость, не выше сотни. Через это снизили требования к тактовой, идущей на PHY. Ну, и системную частоту понизили, благо там связь через FIFO.
Ну, на самом деле, такая формулировка позволит избежать юридических последствий, если вдруг кто-то скажет, что я сею панику и распространяю заведомо ложную информацию. Мне было не сподручно искать его и допытываться, где именно он пытался купить.
Но сейчас, по прошествии времени с публикации, я уже снова общался с ним и знаю, что он искал много где. Поэтому если у Вас иные сведения, то просто сообщите, где можно сейчас взять десятых Циклонов. Скажем, 10CL006YU256C8G. Не макеток, а чипов. Скажем, сотню. Если что - я ему передам. Он будет рад.
Посмотрел. Ничего особенно не понял. Но судя по имени"Гугль", есть шанс, что рано или поздно пойдёт в народ. Потом когда-нибудь кто-нибудь закажет разработку на этой штуке, тогда и разберёмся :-).
Помню, в комментариях к статье, написанной в начале 2018 года, мне пеняли, что я не принимаю во внимание ПЛИС LATTICE. Причём про них тогда уже многие знали. Должно было пройти три года, чтобы нам свалился реальный заказ на этих ПЛИС. Ещё полгода понадобилось мне, чтобы понять, что об этом вообще имеет смысл писать. Ну, и накопить базу знаний, которые будут интересны другим.
Ну STM32 примерно так и работает. А вот GD32, если видит в этом поле входящего пакета ноль, то игнорирует такой пакет. При этом не выявлено каких-либо флагов ошибки. По крайней мере, мы ставили точки останова на участки, где в дескрипторе вернулся признак ошибки. Ни разу не сработали. И те счётчики ошибок в портах, что мы мониторили - не увеличивались. А пакеты именно с таким признаком именно GD32 - теряли.
Что касается флагов ошибок - может не то смотрели, может где-то что-то и отмечалось. Но что настоящий STM32 в тех же ситуациях ничего не терял - факт. Отключение проверки контрольных сумм заголовков решает проблему - тоже факт.
Это что. Мне однажды свалился баннер - купите отечественный RISC-V контроллер. Ну я зашёл. Ага! Не купите, а запишитесь на покупку. И когда он будет доступен, то у него будет 8 килобайт флэша... При том, что по моим ощущениям, RISC-V с Compressed командами требует в среднем вдвое больше памяти для кода, чем Cortex M. А самая базовая голубая пилюля 64К флэша на борту имеет...
В общем, всё познаёмся в сравнении. Тут - пойманные проблемы неприятны, но пока не смертельны.
В полном соответствии с логикой STM32, с которым эти контроллеры функционально совместимы. Причём настолько совместимы, что вот у STM32F10X MAC намного проще, чем у STM32F4.... Поэтому у GD32F107 MAC похож на STM32F107, а у GD32F450 - на STM32F4. У первой парочки, скажем, нет расширенных дескрипторов.
А так - там на уровне MAC ещё и аппаратная поддержка PTP имеется. У всех выше перечисленных. И опять же, парочка STM/GD32F107 имеет логику PTP попроще, А которые F4 - покруче. Всё совместимо.
У меня такой печальный опыт общения с первыми линиями разных техподдержек, что я без нужды к ним не обращаюсь больше. Обычно никому это не надо у производителя. А если кому-то и надо, то пока до него прорвёшься... А смысл?
Конечным пользователям будет полезно - я задокументировал. Заказчик в Штатах тоже в курсе теперь. Возможно, он с производителем свяжется.
Да я тоже плаваю. Для себя я решил, что всей этой штукой буду пользоваться только для того, чтобы генерить шинно ориентированную основу. А остальное - навешивать снаружи.
Потому что писать модули на MiGen... Я понял, как народ это делает, но мне кажется это противоестественным. Использовать готовые процессор и контроллер ОЗУ от LiteX - те ПЛИС, с которыми мне пока что довелось работать, дают с ними дикие тормоза, а процессор ещё и расходует массу ресурсов. Мы даже DHCP в итоге на трёх простеньких автоматах реализовали, чтобы процессор не внедрять ради него. А нормальные ПЛИС имеют свои похожие вещи со своими процессорными ядрами, там и без LiteX можно обойтись.
В общем, кроме как организовать шинную основу для ПЛИС, где этого исходно не предусмотрено - не вижу, зачем этот LiteX может пригодиться. Но вот шины на нём реализуются прилично. Этим пользоваться буду... А остальное - навешивать Верилоговское на эту основу. Как в статьях описано...
Ну да. Любая задача имеет множество решений. И вот у ПЛИС. Те же мои статьи с анализаторами. Сколько стоит купить готовый анализатор USB? А на ПЛИС - я уже на базе универсальной платформы сделал целых два анализатора. USB и Ethernet на два канала (для проверки EtherCAT). Причём Ethernet получился за несколько дней из USB. На базе одного и того же железа, только обвязка разная втыкается и прошивка заливается.
ПЛИС - гибкая штука для штучных решений. А штучные решения нужны часто. Это как 3D принтер. Массовые вещи на нём тоже делать бесполезно.
В рамках этого цикла, ну попробовал я систему LiteX. И поделился с читателями тем, что мне показалось там классным. А выводы к этой статье, показывают, какие я там вижу проблемы. Причём там чётко сказано, что проблемы, похоже, тупиковые. Если только не придёт кто-то, кто раскроет мне глаза...
Вот в комментариях про производительность USB на STM32... Рылся я, рылся, ничего в сети нет. Опубликовал... Рррраз! Сразу три отечественных библиотеки в комментариях подкинули! Так что если нет решения - все увидят, куда соваться не стоит. Есть решение - оно будет зафиксировано, а до того никакой поисковик не обнаруживал его. В любом случае, стоит опубликовать.
Но даже при наличии тупиковых проблем, шинная система у LiteX классная и шустрая. На неё нанизывать блоки - вполне можно. А это упрощает и ускоряет разработку. В этом практическая польза от цикла.
Да, но сколько он стоит и какие требования к плате, на которой он установлен? И на данной конкретной плате стоит именно SDRAM. Но даже и DDR3. Посмотрите таблицы по той ссылке. Для DDR3 производительность иногда лучше, но сильно не всегда.
Это точно. В выводах к той статье так и было написано: "Больше с VGA мы дела не имеем, глупости это, теперь все это сами видели". А в уме я держал: "Перейдём к HDMI - сошлюсь на все эти формулы, так как они все будут точно такими же". Половину той статьи занимал вывод критически важных параметров.
Тут надо смотреть в комплексе. Производительность - один из параметров. А энергопотребление? А автономность? А цена? В первой статье я отмечал, что тут ПЛИС + плата + два ОЗУ + флэшка + генератор + два гигабитных Ethernet (PHY и обвязка) + куча барахла... Всё это было куплено менее, чем за тысячу рублей, включая доставку. Сейчас цены плавающие, так что текущую смотреть не буду. Будем ориентироваться на стабильные времена. Потому что плавают цены на всё. На GPU - тоже.
То есть, трудозатраты (а значит - цена разработки) существенно выше. Специалистов тоже искать сложнее. Странное преимущество.
Да, но наш Заказчик конкретно на эту ПЛИС не марсоход делает, а станки с ЧПУ. Не со всеми его задумками я согласен, но деньги платит он. Заказчик, как я уже отмечал в комментариях к прежним статьям, не из России. А так... Цены на космическую технику таковы, что ещё недавно их могло выкладывать только государство. Поэтому ориентироваться на марсоходы, как на основу для массового решения... Ну, я бы не стал. Помню, фирма Fujutsu перешла на альтернативный формат сервометок, который создал дичайшие трудности. Аргументация была - это снижает себестоимость жёсткого диска на сколько-то там центов... Даже не на доллар! Правда, в том конкретном случае, они прогадали.
Всё верно, но то, что можно написать один компилятор вместо N-компиляторов из каждого формата - не главное. TVM - в первую очередь мощный фреймворк для создания компилятора. Ведь для «N-форматов» есть еще ONNX, в который можно сконвертировать почти каждый формат, но не кросс-компилятором, а просто конвертерами.
Ну и самое главное – это оптимизации на разных уровнях – от вычислительного графа до аппаратных блоков и профилирование через встроенные инструменты, поддержка различных платформ. Ну и, конечно, гибкость самого TVM и и его активное развитие.
К HDMI я пока не знаю, с какой стороны лучше зайти. Поэтому давайте покажу текущие мысли. Может мы даже чего-то вместе придумаем, куда лучше двигаться.
С одной стороны, было бы здорово рассказать, как выводить свою картинку через HDMI, но это будет пересказ ряда уже существующих статей. Неплохая статья уже есть на сайте Марсоход. Реализация HDMI в ПЛИС (marsohod.org) . В ней некоторые вещи не очень раскрыты, так как автор считает их само собой разумеющимися. Их бы раскрыть, и... Опять же, эта статья ссылается на fpga4fun.com - HDMI
Раскрыть опущенные подробности - всегда полезно. А вдохновение по коду для Латтисов можно черпать из вот этого кода, который я собрал и убедился, что он работает: wuxx/Colorlight-FPGA-Projects: current focus on Colorlight i5 series module (github.com) Там - /src/i5/hdmi_test_pattern/.
Чего оттуда не ясно, можно подглядеть в проекте, который пилил мой начальник atari800-u16/rtl/reverse-u16/hdmi at master · fintros/atari800-u16 · GitHub - там есть скандаблер (это он мне такое неприличное слово сказал) и упаковка звука. А если взять более ранний коммит, то можно найти и стандарт.
Но во-первых, писать пересказ скучно, во-вторых, для реальной жизни важнее что-то, легко встраиваемое в любую типовую систему. Есть ещё в-третьих. Я мечтаю когда-нибудь сделать красивый и чётко документированный эмулятор БКшки (что добавляет требований по моим хотелкам к конкретным видеорежимам для качественной поддержки графики и кадрового прерывания), но это уже мечты из области идеала. Пока хватит первых двух пунктов.
Так вот. Самое логичное, что видно при движении в эту сторону - стандартные Litexовские контроллеры алфавитно-цифрового и графического дисплеев. Но там я пока буксую на том, что их надо подключать к Native шине SDRAM, а у неё производительность пока что выходит такая, что страшно её показывать. Документации никакой. Вот, сижу, потихоньку тыкаюсь, чтобы получить все сведения по возможным режимам работы, по настройкам частот, по настройкам режимов и прочему. Чтобы было всё обосновано хотя бы, а не "попробовал, кажется работает". Короче, пока тоже нечего описывать. Что уже могу собрать, то другим советовать стыдно. А остальное - тыкаюсь потихоньку, чтобы освоить.
Заказчик Латтисовского проекта сказал часы на это не расходовать, делать всё без базовой системы. Так что теперь разбираюсь в свободное время. Набегами. Было бы полезно с кем-то пообщаться, чтобы в диалоге во всём разобраться. А может где есть документация, на которую я до сих пор не смог выйти, как не мог выйти на OSS CAD Suite.
Посмотрел, что это такое. Наконец-то версия под Windows свежая. Всё, что я раньше находил, было древним, либо содержало только сборки под Linux. Возможно, тогда Вы и правы. Надо будет изучить.
Понимаете. Сначала я работал в RT-11. Потом - в MS DOS и оболочке Dos Navigator. Дальше были Win3.1, Win95, NT4.0 и далее по нарастающей. Я уже привык к файловой иерархии такого вида. Мне не комфортно в Линуксе. Я там нервничаю. А как можно писать нормальный код, когда нервничаешь? Тем более, нервничаешь от того, чего можно избежать?
При работе в Windows через FAR, я чувствую себя комфортно и думаю только о коде. Я стар. Переучиваться бесполезно. MC меня выбешивает своими особенностями, если что. Дерево файлов - тоже выбешивает. Это не лечится. Это надо принять.
Вот для тех, кому переучиваться бесполезно, я и поделился опытом. А что остальным это не нужно - вынес в заглавный абзац.
А, то есть, мы о разных асинхронностях. Вы на уровне тактирования, а я - на уровне транзакций. Пока не завершится предыдущая транзакция - новую начинать нельзя. Сигнал завершения транзакции обязателен.
К счастью, Википедия допускает дикое число знаений слова "Асинхронность".
Но в целом - да, не совсем хороший термин выбрал. Многозначный. Я подумаю, как поправить его, не корёжа текст.
Если не выставить ACK - Master дальше не пойдёт. ACK обязателен.
Это у AVALON линия Wait опциональна. А тут - без ACK ну никак. По крайней мере, из моего опыта это следует. Сейчас порыскал по спецификации. Не нашёл ничего опционального на эту тему. ACK, ERR или хотя бы RTY. То есть, отклик обязателен.
Большое спасибо!
Ну, тут главное - видеть, что не на пустоту стараешься. Так как на подготовку сил уходит много... Если реакции почти ноль - одна из возможных причин, что никто и не читает. и тогда зафиксировать знания можно в более простом формате, не развёрнуто, а тезисно, внутренним документиком. Именно поэтому и желательно отмечаться, что "угу, тема интересная"...
Эта пара статей как раз была фиксирующая глобальные знания. Чтобы преодолеть страх перед непонятными Питонами в рамках работы с ПЛИС. Дальше - уже по накатанной. Ну, раз есть те, кому интересно - будем разбираться вместе... Пока интерес совсем не угаснет.
Хм. Смотрится красиво. И даже неплохо документирован
Use LiteScope To Debug A SoC · enjoy-digital/litex Wiki (github.com)
Спасибо! Буду изучать!
Тестили... А сейчас по указанию. Заказчика, даже на пробу сделали версию, которая при старте отключает поддержку гигабита в опциях Auto Negotiate. Тем самым, зажимаем скорость, не выше сотни. Через это снизили требования к тактовой, идущей на PHY. Ну, и системную частоту понизили, благо там связь через FIFO.
Тестовые пакеты бегают, не теряются.
Ну, на самом деле, такая формулировка позволит избежать юридических последствий, если вдруг кто-то скажет, что я сею панику и распространяю заведомо ложную информацию. Мне было не сподручно искать его и допытываться, где именно он пытался купить.
Но сейчас, по прошествии времени с публикации, я уже снова общался с ним и знаю, что он искал много где. Поэтому если у Вас иные сведения, то просто сообщите, где можно сейчас взять десятых Циклонов. Скажем, 10CL006YU256C8G. Не макеток, а чипов. Скажем, сотню. Если что - я ему передам. Он будет рад.
Посмотрел. Ничего особенно не понял. Но судя по имени"Гугль", есть шанс, что рано или поздно пойдёт в народ. Потом когда-нибудь кто-нибудь закажет разработку на этой штуке, тогда и разберёмся :-).
Помню, в комментариях к статье, написанной в начале 2018 года, мне пеняли, что я не принимаю во внимание ПЛИС LATTICE. Причём про них тогда уже многие знали. Должно было пройти три года, чтобы нам свалился реальный заказ на этих ПЛИС. Ещё полгода понадобилось мне, чтобы понять, что об этом вообще имеет смысл писать. Ну, и накопить базу знаний, которые будут интересны другим.
Так что ждём, когда эта штука выстрелит.
Посмотрите, пожалуйста, тут Yosys Open SYnthesis Suite :: Command Reference :: write_verilog (clairexen.net)
Там в конце страницы большой трактат, который мне ничего не говорит. Возможно, Вы опытным взглядом быстрее определите, что там можно, что нельзя.