xvr

Обычно делают в 2 фазы - формирование строки из вашего числа в памяти, и отдельно вывод этой строки на индикатор. Не стоит пытаться совместить эти фазы

Неправильное правило - reinterpret вообще применять нельзя. Это очень опасное средство - оно полностью отключает всяческий контроль за тем что и куда преобразовывается. reinterpret в программе это признак некоректного использования базовых типов языка (т.е. хакерство в чистом виде). Для всего

Шутить изволите? У автора 'концептуальный' процессор - главное что бы в HEX всё было красиво, работать ему (процессору) не обязательно 🙂 А уж в свете последних достижений - расширяемого регистрового файла под управлением 'концептуальной' программы, какие то мелочи в виде производительности вообще не имеют никакого значения!

Ваша ошибка в том, что вы считаете что CRC32 это какой то один единственный алгоритм, а это не так. Их мульён (точнее их несколько разновидностей, и для любой из них есть как минимум 1 32х битный параметр, называемый полином, который и определяет, что именно будет считаться. И полиномы эти разные) Тут уже многократно приводили ссылки на сайты с калькуляторами CRC, генераторами и чёрт ещё знает чем 🙂

В вашем сорце сначала в тексте принимается размер всего бинарнртка, потом сам бинарник одним куском

А размер перед отправкой файла не забыли в TeraTerm набить?

Ну и что? Это же не мешает использовать готовые IP блоки в своём дизайне. Можно с учебными целями запились своё FIFO, но в проекте лучше использовать готовое - оно по крайней мере работает 🙂 Кроме того, даже с учебными целями лучше использовать готовое - как минимум поймёте как выглядит более менее стандартный интерфейс FIFO, прежде чем пилить свой велосипед с квадратными колёсами 🙂

Вы не того хотите 🙂 Посмотрите в Gowin готовые макроблоки (там должно быть что то на эту тему), и найдите там готовое FIFO (2х клоковое). Не надо изобретать велосипед. Верхний уровень - сама память, ещё модуль где вы из неё читаете и 3й - где в неё пишете. Должно быть так - память и процессы чтения и записи в одном модуле, управляющие сигналы и сигналы данных от этих процессов выдаются наружу через порты. Сама память никуда не выдаётся. Но в вашем случае лучше взять готовое FIFO

Это не хорошо. У вас физическая память и её порты оказались размазаны по 3м модулям. Что из этого сделает синтезатор предсказать трудно. Всё же рекомендуется физические и логические блоки держать на одном уровне иерархии. Это упростит жизнь и синтезатору и в первую очередь вам, как разработчику. При таком разделении, как у вас результат синтеза блоков будет зависеть от других блоков, что черевато неожиданными и трудно выявляемыми ошибками. Например вы можете изменить код в одном месте, а синтез сломается совершенно в другом. Не сможете синтезировать. Вам очень повезло, что он смог. Я бы не стал расчитывать, что синтезатор всегда так сможет.

VHDL (равно как и Verilog) поддерживает 2 набора операций и конструкций языка - первый набор синтезируемый. С его помощью описывают реальную схему. Второй - не синтезируемый. Он не может использоваться для описания схем, а используется (вместе с 1м набором) для создания верификационных тестов. Ваш 'голый' массив относится ко 2му набору. В схеме его так использовать нельзя. К тому, что нельзя передавать массив между модулями - можно только его порты (в виде набора сигналов чтения/записи). А уж где вы этот массив расположите - отдельным модулем или внутри какого то другого модуля, решать вам.

Вам это для только симуляции или синтезировать тоже будете? Если второе, то так работать не будет (ни с какими inout и пр). Не бывает в железе generic памяти с проиэвольным доступом откуда угодно. В железе память вообще напрямую не доступна - только через порты, которых у неё ограниченное количество и с ограниченными возможностями. (Я сейчас не рассматриваю память, которую синтезатор может сделать на регистрах - у такой может быть практически любое количество портов). И что бы синтезатор понял, что из вашего массива надо сделать память, его описание и способы доступа к нему должны быть весьма определёнными. Каждый порт описывается определённым набором сигналов, а сама память обычно располагается целиком внутри какого нибудь модуля. Весь доступ снаружу идет через порты (эти самые сигналы).

А поставить триггер на DRDY и получить на его выходе WS для I2S не подошло?

Вот только ребята не знают, скедулинг команд оптимизаторы перестали делать при переходе от SC к OOO. Или вы имеете в виду другие оптимизации? Да, оптимизации циклов, кэшей и прочей микроархитектурной требухи компиляторы делают. OOO тут не спасает. Разумеется, но вот как раз с этим оптимизаторы как то борятся (не очень успешно правда) Суперскаляр это попытка загрузить по максимуму процессорное железо. То, что горло в память уже, чем вход в процессор позволяет не особенно стараться его (горло процессора) расширить - и так хватает. Но это не является принципиальным моментом - ускорится память (ч то вряд ли) - увеличат разрядность входной шины (там есть куда - кэш лайн в L0 64 байта). Разумеется, тогда всё начинает работать со скоростью интерфейса в память - ни о какой производительности говорить не приходится. Но этот режим не является штатным режимом работы и его никто не оптимизирвет, от него избавляются всеми доступными средствами. ЦП тут начинает практически простаивать, так что о его 'наворочках' в таком режиме речь не идёт. Но так как в таком режиме подение производительности громадное, то их очень быстро обнаруживают и искореняют на корню. Пока ничего лучше в этоим секторе не придумали, если сможете придумать - продайте Intel'у, озолотитесь 🙂 (У них тут кризис жанра 😞)

IBM много чего сделала, и ещё больше похоронила. Первый комерчески успешный OOO был у Intel'а - оттуда и надо считать.

Я бы сказал прорывная особенность. Она позволила выжать всю возможную (в рамках суперскаляра) скорость. Я бы сказал, что это новая архитектура, построенная на базе суперскаляра. Увы, не назову 😞 Но кажется мне, что были (хотя могу и ошибаться). Но даже 128 битов вполне хватит для заполнения входного окна. Не смешно

лядно, вы можете продолжать упорствовать в своих заблуждениях, ваше право. Но оптимизаторы кода перестали заниматься расстановкой команд при переходе от SuperScalar к OutOfOrder процессорам (т.е. лет 20 как уже) Там 512 бит, и загружает он их постоянно. Пока даже у OOO не получается отправлять на исполнение ВСЕ команды, так что дырки для постоянной подгрузки есть. Почитайте про OOO, не позорьтесь. Поситайте про OOO, не позорьтесь Суперскаляр устарел лет 20 назад, почитайте про OOO, не позорьтесь.

Это распространённое заблуждение. Существующая x86 архитектура близка к пределу производительности - частота процессоров практически не растёт, а что бы как то компенсировать это и занять место на кристалле (т.к. транзисторов стало много а воткнуть в одно ядро уже не получается) стали делать многокоровые процессоры. Но стековый процессор - это шаг в обратном направлении 😞 И где он? Цитата с их сайта: Сейчас 2023 год, если кто забыл 🙂 Видимо тоже массоны виноваты 🙂

Верно верно. Почитайте подробнее что такое OOO. OOO фронт енд закачивает ВСЕ инструкции подряд, и отправляет их ВСЕ на reservation station. А отправляться на исполнение они будут когда для них будут готовы аргументы. Так что, что бы 2 инструкции были исполнены не зависимо друг от друга они всего лишь должны попасть в 'окно' выборки (это несколько сотен команд). Порядок их внутри это окна абсолютно не важен. OOO было сделано как следующая ступень после RISC, как раз что бы уйти от скедулинга операций в компиляторе, т.к. он всё равно не мог выполнить его лучше (или хотя бы не хуже), чем железный процессор. И дело совсем не в том, что компилятор не достаточно продвинут, что бы это сделать, а в том, что аппаратура учитывает динамику исполнения кода, чего компилятор может сделать только частично. VLIW был сделан как шаг в сторону от RISC - для суперскаляров. Этот подход параллелен OOO, и он проиграл, как раз из за необходимости жёсткого скедулинга инструкций. OOO это делает более эффективно. NB. Большинство аргументов сторонников 'нестандартных' архитектур происходят от банального незнания, как построенны современные микропроцессоры. Они думают, что процессор последовательно, байт за байтом выполняет команды, как они идут в программе 😞 А современный микропроцессор напоминает айсберг - то, что видит програмист это всего лишь очень меленькая надводная часть 🙂 И предлагают свои 'свершения' как революционный прорыв, который на самом деле является диким анахронизмом времён 'когда компрьютеры были большими'. PS. Если интересно как работает OOO - я могу рассказать в подробностях (я в прошлом принимал участие в разработке таких процессоров и до сих пор принимаю участие) Не иначе заговор производителей с целью похоронить конкурента. Видимо Массоны виноваты 🙂 Вот, почитайте для саморазвития - https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)?utm_content=cmp-true

Именно АВТОМАТИЧЕСКИ. Растановка кода была нужна на конвеерных архитектурах без OOO. OOO это делает сам, никакой расстановки от компилятора или ещё от кого не нужно. Это взяимосвязанные вещи. FORTH система имеет смысл на стековом процессоре, иначе использование С будет куда более продуктивным

Это как раз понятно. Непонятно зачем Forth нужен СЕЙЧАС? Какая у него осталась ниша применения? Похоже, что никакой не осталось 😞 Есть ли у него какие либо ценные преимущества перед обычными архитектурами? Одно приемущество есть - компактный код, за счёт отсутствия в команде полей для номеров регистров. Но это преимущество само по себе бесполезное - на мелких МК (куда можно было бы встроить Forth) RAM заканчивается раньше, чем FLASH. Согласитесь, что для командной разработки это не 'совсем' удобный метод взаимодествия внутри команды - '- где сорец этой функции? - посмотри в системе'. Для разработчика одиночки (читай - как хобби) возможно и подойдёт, но хобби как возможная ниша смотрится несерьёзно. То, что вся эта параллельность в процессоре достигается автоматически, программист никаких специальных алгоритмов для этого не пишет. И всё это работает одновременно, в отличие от классического Forth. Вообще то есть. Для каждого стека свой набор слов для работы с ним. В классическом Forth стека 2 (арифметики и вызовов). К стеку вызовов есть програмный доступ с помощью слов R> и R@ Других стеков нет. И как Forth будет решать, через какой стек передавать? И потом как он будет решать на каком стеке запускать следующее слово? Единственное решение - сделать много отдельных интерпретаторов и в каждом запускать свой кусок программы. Но это совсем не то же самое, что OOO - вы перекладываете всю работу по распараллеливанию на плечи програмиста. А это не удаётся сделать эффективно даже на больших классических машинах. Вообще эта часть дискуссии бесполезна - OOO и прочее делается в высокопроизводительных системах, куда Forth не подходит (как мы это уже выяснили) PS. Один открытый вопрос остаётся - где СЕЙЧАС целесообразно применять Forth? Похоже нигде 😞

Это datasheet IL300.pdf

Зачем? Какое это даёт преимущество перед обычными языками, где 'человек пришет программу целиком'? Недостаток уже виден невооружённым глазом - Forth программы имеют тенденцию скатываться в write only формат, когда даже автор после некоторого времени не сможет понять, что он там написал. Построение языка этому способствует - ввёл команду и забыл про неё, ведь важен только результат - 'выращивается Форт-система'. Потому что их много, и работают они в параллель. Например в x86 несколько десятков исполняющих устройств и все они могут работать одновременно (пул OOO декодированных команд у него - несколько сотен). Предлагаете сделать пару десятков стеков? И поток команд распаллеливать вручную?

В DS 5 штук схем, не подходят?

Этой 'документации' 27 лет от роду. Возьмите что нибудь посвежее, и желательно не с Интернетовских помоек, а с оффициального сайта - https://usb.org/documents https://usb.org/sites/default/files/usb_20_20230224.zip usb_20.pdf

Потому что : Т.е. ниша для стековых МК непонятна 😞 Если только выжимать по максимму плотность кода, но это так себе цель 😞