В мемуарах Федерико Фаджина (который проектировал 4004) упоминается, что руководство Intel в те года в целом считало микропроцессоры какой-то малополезной штукой, которая в лучшем случае поможет поднять продажи памяти. И только после того как Фаджин ушёл от них и создал Zilog, зарабатывающий только на процессорах, они спохватились. Возможно Федерико лукавит, ведь борьбу с Intel он проиграл, да и в целом процессоры (хоть и не микро) к тому моменту были уже массовым явлением с понятной областью применения.
Для максимально простенького ядра некоторые вещи выглядят по меньшей мере странно.
Система команд плохо упакована, плотность кода на первый взгляд хуже чем у сопоставимых платформ. Для малых ядер обычно это важный фактор, только если ваше решение оптимизировано под конкретную внешнюю память, это можно считать несущественным.
Ко многим командам есть вопросы. Например почему длинный прыжок (up2M) с суммированием адреса? Для короткого это логично, но для длинного очень неудобно, указатели надо будет пересчитывать для каждого вызова.
Огромный регистровый файл, не очень понятно как компилятор должен его использовать? Только как регистры общего назначения великоват, как куча или стек маловат. Может быть просто как быструю память, но не проще ли тогда сделать малое число регистров и быструю память отдельно? Для регистров 253, 254 и 255 есть специальные инструкции, они прямо просятся в отдельный маленький файл регистров.
Регистровый файл разбит на 2 части, но не совсем понятно зачем. Они не работают как два контекста вне и внутри прерывания, они непонятно зачем раздувают систему команд, да ещё и не симметричны с её точки зрения.
Насколько я понял, есть скрытые регистры. Как минимум PC и LR. Добавьте их в регистровый файл, создатель компилятора скажет вам спасибо.
У вашего ядра наружу выходят целых 4 шины. Какие-то поменьше, какие-то больше 40 ног. Это отсекает огромное количество маленьких и средних ПЛИС с количеством выводов менее 100, для которых обычно такие архитектуры и используются. Если будете мигрировать на маленькие корпуса, попробуйте использовать мультиплексированную шину, либо перейти на QSPI/CSPI RAM или HyperRAM.
Не владею статистикой, но рискну предположить, что на написание компилятора под новую уникальную архитектуру обычно уходит больше усилий, чем на разработку железа. Будьте готовы поддерживать плотную обратную связь с вашим разработчиком компилятора и идти на архитектурные изменения по его просьбе.
Плата интересная. Но мне кажется, что для задач цифровой обработки звука на ней органично смотрелась бы ещё пара S/PDIF, можно в виде адаптера. Тогда студенты смогут воспользоваться стандартным интерфейсом для ввода цифрового звука и сконцентрироваться на ПЛИС.
Здравствуйте. Прочитал весь Ваш цикл про Litex, спасибо, интересно. У меня есть практическая задача - надо к этой экосистеме прикрепить slave на hdl с большим объёмом (256 Мбит) и непредсказуемым временем отклика (обслуживает и других мастеров). Строить такой адаптер на основе CSR мне кажется медленно и некрасиво. Есть мысли либо переписать hdl в виде litex-ядра, либо сделать адаптер, выносящий wishbone наружу, и там уже приклеить hdl. С hdl я разберусь, а вот в мигене пока плаваю. Что-нибудь посоветуете?
В мемуарах Федерико Фаджина (который проектировал 4004) упоминается, что руководство Intel в те года в целом считало микропроцессоры какой-то малополезной штукой, которая в лучшем случае поможет поднять продажи памяти. И только после того как Фаджин ушёл от них и создал Zilog, зарабатывающий только на процессорах, они спохватились. Возможно Федерико лукавит, ведь борьбу с Intel он проиграл, да и в целом процессоры (хоть и не микро) к тому моменту были уже массовым явлением с понятной областью применения.
Для максимально простенького ядра некоторые вещи выглядят по меньшей мере странно.
Система команд плохо упакована, плотность кода на первый взгляд хуже чем у сопоставимых платформ. Для малых ядер обычно это важный фактор, только если ваше решение оптимизировано под конкретную внешнюю память, это можно считать несущественным.
Ко многим командам есть вопросы. Например почему длинный прыжок (up2M) с суммированием адреса? Для короткого это логично, но для длинного очень неудобно, указатели надо будет пересчитывать для каждого вызова.
Огромный регистровый файл, не очень понятно как компилятор должен его использовать? Только как регистры общего назначения великоват, как куча или стек маловат. Может быть просто как быструю память, но не проще ли тогда сделать малое число регистров и быструю память отдельно? Для регистров 253, 254 и 255 есть специальные инструкции, они прямо просятся в отдельный маленький файл регистров.
Регистровый файл разбит на 2 части, но не совсем понятно зачем. Они не работают как два контекста вне и внутри прерывания, они непонятно зачем раздувают систему команд, да ещё и не симметричны с её точки зрения.
Насколько я понял, есть скрытые регистры. Как минимум PC и LR. Добавьте их в регистровый файл, создатель компилятора скажет вам спасибо.
У вашего ядра наружу выходят целых 4 шины. Какие-то поменьше, какие-то больше 40 ног. Это отсекает огромное количество маленьких и средних ПЛИС с количеством выводов менее 100, для которых обычно такие архитектуры и используются. Если будете мигрировать на маленькие корпуса, попробуйте использовать мультиплексированную шину, либо перейти на QSPI/CSPI RAM или HyperRAM.
Не владею статистикой, но рискну предположить, что на написание компилятора под новую уникальную архитектуру обычно уходит больше усилий, чем на разработку железа. Будьте готовы поддерживать плотную обратную связь с вашим разработчиком компилятора и идти на архитектурные изменения по его просьбе.
Плата интересная. Но мне кажется, что для задач цифровой обработки звука на ней органично смотрелась бы ещё пара S/PDIF, можно в виде адаптера. Тогда студенты смогут воспользоваться стандартным интерфейсом для ввода цифрового звука и сконцентрироваться на ПЛИС.
Здравствуйте. Прочитал весь Ваш цикл про Litex, спасибо, интересно. У меня есть практическая задача - надо к этой экосистеме прикрепить slave на hdl с большим объёмом (256 Мбит) и непредсказуемым временем отклика (обслуживает и других мастеров). Строить такой адаптер на основе CSR мне кажется медленно и некрасиво. Есть мысли либо переписать hdl в виде litex-ядра, либо сделать адаптер, выносящий wishbone наружу, и там уже приклеить hdl. С hdl я разберусь, а вот в мигене пока плаваю. Что-нибудь посоветуете?