[Arlleex 331]

Интересна в этом всем хозяйстве не частота M0-ядра, а его интерконнект с периферией SoC - всякими UART/SPI/I2C/GPIO/и т.д.

[sasamy 14]

11 minutes ago, mantech said:

Вы хоть почитайте, зачем был задуман этот М0 - для управления энергосбережением.

не знаю что вы курите, но зачем в таком случае ему производительность DSP ?

11 minutes ago, mantech said:

Реалтайм - это например среду исполнения ПЛК туда впихнуть

зачем ? для этого можно одно ядро ca7 через гипервизор отделить от Linux, да и нафик нужно - её и в linux можно запускать с пачем preemt-rt, микроконтроллерное ядро - чтобы снизить латентность отклика на внешние события

Edited November 27, 2025 by sasamy

[dxp 198]

3 часа назад, Arlleex сказал:

Ну так зачем конвейер городят для мелкоконтроллеров, которые должны работать в районе 50 МГц? Вопрос ведь тот же самый.

Скорее всего потому, что техпроцесс медленный, и single-cycle вариант будет работать едва ли не на 20 МГц. А если его разгонять, то сразу полезет питание, потребление, цена и т.п.

В конвейеры лезут не от хорошей жизни -- тот же single-cycle получается реально на порядок-другой проще: мой товарищ делал ядро RISC-V для FPGA, в 700 LUT уместилось, работало на 150 МГц на Artix-7 второго спидгрейда, сделал он его за несколько месяцев в одного по вечерам как хоббийный проект. А вот с конвейером он даже начинать не стал -- там совсем другие затраты времени и сил требуются. Даже трёхстадийном.

3 часа назад, Arlleex сказал:

в относительно простой ПЛИС реализовать простейшую систему команд Cortex-M0 и запустить на сотне МГц вполне реально

Только следует иметь в виду, что FPGA сама по себе достаточно быстрая микросхема -- даже старая 7-я серия Xilinx это уже 28 нм, а Gowin Arora дак вообще 22. Но я не припомню, чтобы тот же Microblaze трудился на сотнях МГц -- там сотня-полторы если получается, уже норм.

3 часа назад, Arlleex сказал:

И это все при одних и тех же условиях: техпроцесс, питание, температура задрана в +125 градусов.

Скорее это не температура задрана, а они разгоняли чип до тех пор, пока он не нагрелся до этой температуры, и этим определили предельную частоту. Обратите внимание, что вроде конвейер короче, а частота выше -- как-то совсем наоборот должно быть. Но тут это тест не на корректную работоспособность ядра, а на предельные режимы, когда оно ещё живое. Вот и получается, что если конвейер короче, логики меньше, энергопотребление ниже, частота предельная выше. Т.е. Max Freq там -- это предельная частота ядра, при которой оно достигло предела по температуре. Работает ли там оно корректно, тут не сказано, но и так понятно, что нет. Да просто посчитать тепловыделение -- на 567 МГц там получается из этих же данных 7.3 Вт! Кристалл площадью 0.06 мм2 за считанные секунды превысит предел и расплавится. 

Т.ч. это не характеристика тактовой частоты работы МК. Имхо.

[jcxz 359]

36 минут назад, mantech сказал:

И что такого реалтаймового вы впихнете в 32кбайта, кода+данных?

А зачем всё (весь код и данные) пихать в быструю память? Все настройки-конфигурирования периферии и т.п. - на кой???

32КБ - это овердофига для большинства проектов. Если компоновать туда только тот код, который реально нужно. Требующий производительности. А не всё подряд. Т.е. - компоновать с умом, а не "как компоновщик за меня решил".

Научитесь работать с компоновщиком, и для вас эта задача также перестанет быть непосильной.  

28 минут назад, Arlleex сказал:

Интересна в этом всем хозяйстве не частота M0-ядра, а его интерконнект с периферией SoC - всякими UART/SPI/I2C/GPIO/и т.д.

В том семействе, что вы упоминали, в LPC4370 есть два M0-ядра. Одно из которых насколько помню - сидит в отдельной подсистеме, со своим набором шин и ОЗУ. И даже небольшой набор периферии. И взаимодействует с остальными ядрами через мост.

Итого: LPC4370 = 2шт. M0, каждое из которых может работать на <=204МГц, и каждое - из своей памяти.

[Arlleex 331]

4 минуты назад, jcxz сказал:

В том семействе, что вы упоминали, в LPC4370 есть два M0-ядра.

Нет, этот не интересный - речь изначально о M0-ядре внутри SoC рокчипа.

[firstvald 47]

3 hours ago, dxp said:

Скорее всего потому, что техпроцесс медленный, и single-cycle вариант будет работать едва ли не на 20 МГц. А если его разгонять, то сразу полезет питание, потребление, цена и т.п.

В конвейеры лезут не от хорошей жизни -- тот же single-cycle получается реально на порядок-другой проще: мой товарищ делал ядро RISC-V для FPGA, в 700 LUT уместилось, работало на 150 МГц на Artix-7 второго спидгрейда, сделал он его за несколько месяцев в одного по вечерам как хоббийный проект. А вот с конвейером он даже начинать не стал -- там совсем другие затраты времени и сил требуются. Даже трёхстадийном.

оппа. Я считал, что конвеер, вводя независимые стадии, с гарантированно закончившимися логическими процессами на стыке, упрощает разработку,  давая возможность каждое звено рассматривать независимо.

[mantech 132]

4 часа назад, sasamy сказал:

зачем ? для этого можно одно ядро ca7 через гипервизор отделить от Linux

Ага, и клок-домен для него тоже отделите?)))))) Иначе со скачками частоты линукса будет скакать и ваше реалтайм-ядро)))))

4 часа назад, sasamy сказал:

можно запускать с пачем preemt-rt,

Если все там так здорово, чего ж тогда ядро с этими патчами не делают везде - так ведь круче, но скорее всего есть нюанс...))))

4 часа назад, jcxz сказал:

Научитесь работать с компоновщиком, и для вас эта задача также перестанет быть непосильной.

Я ленивый, если есть процессор, где можно отдаться на волю компоновщику, зачем усложнять себе жизнь, ну а кому надо пусть делает))

[sasamy 14]

30 minutes ago, mantech said:

Ага, и клок-домен для него тоже отделите?)))))) Иначе со скачками частоты линукса будет скакать и ваше реалтайм-ядро

элементарно однострочник решает

Quote

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

 

43 minutes ago, mantech said:

Если все там так здорово, чего ж тогда ядро с этими патчами не делают везде - так ведь круче, но скорее всего есть нюанс

сделали, но нюанс в том что реалтайм снижает производительность системы поэтому по умолчанию все используют обычное ядро

https://lwn.net/Articles/989212/

[mantech 132]

41 минуту назад, sasamy сказал:

элементарно однострочник решает

Ну хорошо, зададите вы минимальную и макс. частоту одинаковой - тем самым просто отключите DVFS, это не выход, проц будет всегда молотить на максималке, сильнее нагреваясь и пр. В ДСП можно задать 600МГц, а кортексы будут продолжать работать в DVFS.

[dxp 198]

4 часа назад, firstvald сказал:

оппа. Я считал, что конвеер, вводя независимые стадии, с гарантированно закончившимися логическими процессами на стыке, упрощает разработку,  давая возможность каждое звено рассматривать независимо.

Если б они были независимыми. А они ещё как зависимы -- ведь каждая следующая стадия кушает выход предыдущей, они тесно связаны между собой. Там возникает целый класс проблем:

• конфликты (data, control, structural hazards). Например, data hazard -- одна команда грузит данные регистр (пусть r0) на стадии WB(write back), а следующая команда использует этот регистр как операнд для чтения - на стадии ID (instruction decode) производится адресация регистра, а данные в нём ещё не "устаканились", получается доступ к неправильным данным, и чтобы избежать этой неприятности приходится либо делать stall конвейеру (это простой и неэффективный метод), либо forwarding (bypassing) -- это нетривиальная логика, которая пробрасывает инфу по путям параллельно конвейерного пути. Плюс к этому ещё логика обнаружения этих хазардов. С другими типами конфликтов не проще, там свои проблемы;
• проблема балансировки стадий (время выполнения стадий должно быть примерно равно, если будет хоть одна медленная -- она завалит тактовую, убивая всю идею в корне);
• усложнение обработки исключений -- если инструкция вызывает исключение, а в конвейере ещё загружены другие, то их тоже нужно корректно завершить;
• на условных переходах возникают потери производительности (и чем длиннее конвейер, тем больше потери), для борьбы с этим применяют предсказатели ветвлений разных типов -- это весьма сложные блоки, используют эвристики разного рода, адаптивные на статистиках, и даже вроде уже нейросетки туда применять начали. Это сложность, приличная площадь на кристалле;
• сложность всего этого порождает трудности с разработкой и отладкой -- разного рода гонки, которые подчас сложно воспроизвести (наложение условий), неопределённость предсказаний (ветвлений) прождает недетерминированное поведение и т.п.
• проблемы с производительностью, когда, например, инструкция лезет в память, возникает промах кэша и дальше простой на несколько сотен (а то и тыщ) тактов (в толстых процах), пока аппаратура слазит во внешниюю память и доставит требуемые данные. При этом остальные инструкции тоже стоят и ждут, возникает общее торможение. С этим борются с помощью техники внеочередного выполнения инструкций ( instruction reordering) и переименования регистров (register renaming). Суть метода в том, что если возникает такая ситуация -- например, команда грузит данные из памяти в r0, а через пару инструкций опять используется этот же r0, то аппаратура обслуживания конвейера анализирует, какие инструкции, стоящие в очереди за затормозившей, не зависят от ней и её данных, и пропускает эти инструкции вперёд, при этом в качестве регистра r0 используется физически другой регистр (там у ядра, например, при штатных 16 регистров реально их штук 40, и при выполнении инструкций динамически выделяется регистр из этого пула, поэтому можно выделять регистры с одинаковыми именами для разных независимых аппаратных контекстов). Это очень сложная техника, я снимаю шляпу перед людьми, которые это сделали. Такое умеет, к примеру, Cortex-A9 и Cortex-A72, а Cortex-A53 не умеет.

В общем, конвейеры в процессорных ядрах -- одна из самых сложных и неисчерпаемых тем. И сделать даже простой конвейер, свободный от хазардов, сбалансированный и просто корректно работающий во всех ситуациях, -- это очень достойный челлендж. И обычно это задачка не для одного человека, а для команды квалифицированных спецов. 

[firstvald 47]

Панчул постоянно повторяет: американские студенты не умеют делать конвееры вообще. 

[sasamy 14]

2 hours ago, mantech said:

В ДСП можно задать 600МГц, а кортексы будут продолжать работать в DVFS.

зачем для этого DSP ? он на т113 вообще для обработки аудио, на армах всё можно делать уже лет 15 big.LITTLE и современный вариант DynamIQ

[mantech 132]

41 минуту назад, sasamy сказал:

зачем для этого DSP ?

Для чего "этого"? У вас мысли путаются, чет смешали все в одном стакане...

41 минуту назад, sasamy сказал:

он на т113 вообще для обработки аудио

Да мне без разницы, что и кто задумывал, мне не нужна обработка аудио и я запустил рантайм ПЛК, это нельзя?

Edited November 27, 2025 by mantech

[sasamy 14]

17 minutes ago, mantech said:

Для чего "этого"? У вас мысли путаются, чет смешали все в одном стакане.

но ведь это вы с чего-то про DSP написали,  я так понял "это" у вас про гетерогенные системы 

так при чём тут DSP и почему CM0 нельзя если речь про процессор rk3506 ? 

25 minutes ago, mantech said:

и я запустил рантайм ПЛК, это нельзя?

проблема у вас в том что есть большое сомнение что вы запустили DSP, одна боллтовня

[mantech 132]

6 минут назад, sasamy сказал:

так при чём тут DSP и почему CM0 нельзя если речь про процессор rk3506 ? 

Кто сказал, что нельзя? Я привел типичную задачу для реалтайм ядра - рантайм ПЛК, с этим вы согласны? Теперь, про ДСП и СМ0, разница в частоте и доступной памяти, и первое и второе в пользу ДСП, согласны? Тогда в чем дело?

8 минут назад, sasamy сказал:

большое сомнение что вы запустили DSP, одна боллтовня

Запустил, но рантайм пока не доделал.