[jcxz 184]

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

STM32F407

Up to 192+4 Kbytes of SRAM including 64- Kbyte of CCM (core coupled memory) data RAM

И какое отношение эта картинка имеет к частоте RAM?

Попробуйте всё же прочитать этот даташит. Раз уж сумели его скачать.

Тогда может найдёте в нём:

Цитата

2.2.6  Embedded SRAM
All STM32F40xxx products embed:
• Up to 192 Kbytes of system SRAM including 64 Kbytes of CCM (core coupled memory) data RAM
RAM memory is accessed (read/write) at CPU clock speed with 0 wait states.

[mantech 35]

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

Тогда может найдёте в нём:

Может тогда и объясните дремучему, зачем ее сделали, присоединили напрямую к процессорной шине, без всяких шинных переключателей и пр.. ? Думаю не просто по глупости)))

Перепутал, кортекс М4 с М7)))

И как видно тут скорость памяти и проца явно не одна и та же, правда?

Ну и еще вопрос на засыпку, объясните, коль память в кортекс М работает со скоростью проца, по вашему, следовательно зачем в М7 поставили кэш в ядро? Смысл-то какой, скорости одинаковые же?)))

Изменено 18 января пользователем mantech

[tegumay 4]

по уму они должны делать завершенные наборы микросхем, а не разовые поделки. 
зачем ОДНА отечественная микросхема, если вокруг нее приходится ставить 10 импортных.
а если вспомнить про сроки и гарантии поставок xD

[makc 192]

12 минут назад, tegumay сказал:

по уму они должны делать завершенные наборы микросхем, а не разовые поделки. 
зачем ОДНА отечественная микросхема, если вокруг нее приходится ставить 10 импортных.
а если вспомнить про сроки и гарантии поставок xD

Вот и я о том же. Причём ладно бы можно было рядом с Амуром поставить отечественную QSPI флешку, так ведь нет таких. Вот и получается колосс на глиняных ногах, хотя скорее всё-таки геракл засушенный. 😉

[mantech 35]

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

по уму они должны делать завершенные наборы микросхем

Именно, тогда будет смысл в импортозамещении, как это было в СССР, тогда например был полный комплект К580 и др серий...

[kan35 7]

On 1/18/2024 at 4:08 PM, makc said:

Давайте посчитаем вместе требуемую скорость работы с памятью для используемого ядра SCR1 https://github.com/syntacore/scr1 . На частоте 16 МГц при compressed-командах (2 байта на команду) ПСП памяти для исполнения без циклов ожидания (одна команда на такт, конвейер) получается приблизительно 32 МБ/с при условии выполнения линейного участка кода, но т.к. команды идут смешанные, то можно оценить потребную ПСП процентов на 50 больше, т.е. 48 МБ/с. ПСП QSPI, о которой вы пишете, получается в шесть раз меньше требуемой. Хм... Это разве не медленно? Или я заблуждаюсь?

В других МК для решения проблем со скоростью внешней памяти есть кэши данных и команд. Здесь этого нет

 

Амур работает на 32МГц, при этом QSPI - на 16МГц, соотвественно, требуется 64мб/с, а есть 8, но хорошая новость в том, что кэш таки есть, он не в процессоре, а не блоке QSPI, его объем составляет 1кБ.

Кстати, на STM32 флэш весьма медленная, около 30МГц, соответственно какой-нибудь STM32F4 на 180МГц будет иметь 6 циклов ожидания, а ведь у него ART акселератор - тот же кэш - составляет тот же 1кБ. Но считается, что флэш на нем не сильно его тормозит. А ведь это почти как в Амуре по количеству циклов ожидания. Хотя на QSPI еще и команды, протокол передачи... тут нужно просто замерять на самом деле.

На счет TCM памяти - это память, которая не имеет задержек доступа из за загрузки матрицы шин, для сигнальных вычислений или чего то максимально реалтаймового. Но минус - не доступна для DMA.

[makc 192]

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

Амур работает на 32МГц, при этом QSPI - на 16МГц, соотвественно, требуется 64мб/с, а есть 8, но хорошая новость в том, что кэш таки есть, он не в процессоре, а не блоке QSPI, его объем составляет 1кБ.

Т.е. задержки при работе с этим кэшем для флеша априори выше, чем если бы он был в ядре. Так получается? Если так, то это отличный пример того, как делать не стоит? 🤔

38 минут назад, kan35 сказал:

Кстати, на STM32 флэш весьма медленная, около 30МГц, соответственно какой-нибудь STM32F4 на 180МГц будет иметь 6 циклов ожидания, а ведь у него ART акселератор - тот же кэш - составляет тот же 1кБ

Только, ЕМНИП, там ширина шины флеша 128 бит и за один такт выбираются четыре 32-битных слова, т.е. получается как раз около двух с лишним байт на такт при частоте 180 МГц, чего более чем достаточно для работы без ожидания в случае использования системы команд Thumb2. Или я что-нибудь упустил? 

Кстати, К1921ВГ015 от НИИЭТ использует тот же трюк с шириной шины флеша. Никакой магии, трезвый расчёт.

49 минут назад, kan35 сказал:

А ведь это почти как в Амуре по количеству циклов ожидания. Хотя на QSPI еще и команды, протокол передачи... тут нужно просто замерять на самом деле.

Вы уверены, что это почти как в Амуре получается? 😅 По-моему это сравнение несравнимого, особенно с учётом накладных расходов на работу QSPI, о которых вы сами и пишете. Команду и адрес бесплатно передать не получится, на всё нужно время.

И вот еще вопрос: как будет себя вести вышеупомянутый кэш в блоке SPIFI Амура на реальных задачах с циклами и вызовами функций? По-моему очень интересный вопрос.

46 минут назад, kan35 сказал:

На счет TCM памяти - это память, которая не имеет задержек доступа из за загрузки матрицы шин, для сигнальных вычислений или чего то максимально реалтаймового. Но минус - не доступна для DMA.

Да, всё так. И кэши данных/команд должны быть где-то в районе TCM, а не в периферийных блоках, которые далече от ядра МК. Не особливо эффективное решение получается...

 

[kan35 7]

8 hours ago, makc said:

Т.е. задержки при работе с этим кэшем для флеша априори выше, чем если бы он был в ядре. Так получается? Если так, то это отличный пример того, как делать не стоит? 🤔

Только, ЕМНИП, там ширина шины флеша 128 бит и за один такт выбираются четыре 32-битных слова, т.е. получается как раз около двух с лишним байт на такт при частоте 180 МГц, чего более чем достаточно для работы без ожидания в случае использования системы команд Thumb2. Или я что-нибудь упустил? 

Кстати, К1921ВГ015 от НИИЭТ использует тот же трюк с шириной шины флеша. Никакой магии, трезвый расчёт.

Вы уверены, что это почти как в Амуре получается? 😅 По-моему это сравнение несравнимого, особенно с учётом накладных расходов на работу QSPI, о которых вы сами и пишете. Команду и адрес бесплатно передать не получится, на всё нужно время.

И вот еще вопрос: как будет себя вести вышеупомянутый кэш в блоке SPIFI Амура на реальных задачах с циклами и вызовами функций? По-моему очень интересный вопрос.

Да, всё так. И кэши данных/команд должны быть где-то в районе TCM, а не в периферийных блоках, которые далече от ядра МК. Не особливо эффективное решение получается...

 

Согласен на счет ширины шины между кэш и память, этого я не учел. Но какая эффективность у этого решения на реальных задачах - нужно хотя бы уметь оценить (так как ширину этой шины нельзя регулировать как правило - понять пользу от нее на реальных приложениях будет не так то просто - лучше на %% или в разы).

 У STM32 кэш так же находится за шинной матрицей, поэтому ваша претензия не обоснована.

И опять же - есть предварительные замеры производительности: https://wiki.mik32.ru/CoreMark_Test и по этим данным кэш QSPI достаточно эффективен на задачах, близких к реальным.

И немного лирики. Я встречался со случаями, когда производительности 500МГц не хватало для автосигнализации и разработчик требовал 1ГГц минимум, начинали разбираться в чем дело - машина состояний - он по очереди опрашивает разные датчики и у него всё по микросекундам уже. Говорю - применяй RTOS  и будет тебе достаточно 10МГц, в ответ - "нет, мы боимся, мы не умеем, мы не хотим, дайте 1ГГц".

 

Изменено 20 января пользователем kan35

[mantech 35]

1 час назад, kan35 сказал:

У STM32 кэш так же находится за шинной матрицей, поэтому ваша претензия не обоснована.

Какой кэш? Флешевый, так да, но шины там на частоте ядра работают, и флеш хоть немного, но будет уступать по скорости, т.к. шина у него широкая, но если идет ветвление то упс, непопали с вероятностью 50%. Поэтому и рекомендуют "быстрые" данные держать в ССМ, чтоб во флеш только за командами лазить)))

10 часов назад, makc сказал:

И кэши данных/команд должны быть где-то в районе TCM, а не в периферийных блоках, которые далече от ядра МК.

Ну в М7 так и сделали...

10 часов назад, kan35 сказал:

что кэш таки есть, он не в процессоре, а не блоке QSPI, его объем составляет 1кБ.

Ну это уже неплохо, ибо почти во всех процах, где нет кэша ядра, есть кэш на флеш. 1к маловато конечно, только для какой-то небольшой проги, но при таком быстродействии проца особо-то рассчитывать и не на что...

Изменено 20 января пользователем mantech

[kan35 7]

Не совсем так, матрица шин, хоть и работает на частоте ядра, но она делится между многими мастерами, например DMA, у которого есть пачковый burst доступ, плюс время на захват шины и будет процессор M7 сидеть без данных или без кода многие десятки циклов. Только не говорите "а можно не использовать DMA" 🙂 , но кстати за счет деления SRAM банки в STM32 - там можно распределить нагрузку на матрицу шин, но все же . В общем и целом у CM0-CM4 всё те же слабые точки, что и у других архитектур того же уровня интеграции.

Кстати, TCM на некоторых контроллерах может быть использована для кода тоже.

Конечно же лучше, когда кэш находится и в самом процессоре.  Ну и опять мы внезапно пришли к сравнению SCR1 с CM7...  Все таки, более честно будет сравнивать с СM0 или хотя бы с СM3, так как у SCR1 есть аппаратное умножение, но точно не с CM7.

Изменено 20 января пользователем kan35

[makc 192]

2 часа назад, kan35 сказал:

Согласен на счет ширины шины между кэш и память, этого я не учел. Но какая эффективность у этого решения на реальных задачах - нужно хотя бы уметь оценить (так как ширину этой шины нельзя регулировать как правило - понять пользу от нее на реальных приложениях будет не так то просто - лучше на %% или в разы).

Даже приведённые вами же коремарки показывают качественную разницу между внутренним флешом с широкой шиной и внешним QSPI Амура. Разница от полутора до двух раз. И это на синтетических тестах, а если попробовать там что-то посчитать типа подписи ЭЦП на эллиптических кривых, где много математики? Боюсь, что разница будет буквально в разы, извините за тавтологию. Ещё одна потенциальная проблема QSPI, с точки зрения выполнения из неё кода, это оптимизация интерфейса под блочный доступ. Случайный доступ малыми блоками оказывается крайне неэффективен (получаются высокие накладные расходы на адресацию и команды), а у встроенного флеша такой проблемы априори нет. Поэтому размер кэша в случае использования QSPI для хранения программ/данных нужно кратно увеличивать и делать интеллектуальнее. В общем ничего бесплатного нет. Поставили бы килобайта четыре с более сложной организацией - было бы заметно лучше. Кстати, в этом плане мне понравился подход у китайского BL702, который тоже на ядре RISC-V и использует "внешнюю" QSPI флешку для прошивки, хотя она и корпусируется в тот же корпус (SIP): они дают возможность использовать внутреннюю память (ITCM) в качестве кэша требуемого размера (настраивается) вплоть до 16 кБайт:

Причём кэш расположен очень близко к ядру и поэтому имеет минимальную латентность + максимальную ПСП шины. Благодаря этому контроллер может эффективно работать на частотах до 144 Мгц и имеет показатель ~3.1 CoreMark/MHz. Как говорится, почувствуйте разницу с Амуром (~ 1.16 CoreMark/MHz) при всём их поверхностном сходстве.

2 часа назад, kan35 сказал:

И опять же - есть предварительные замеры производительности: https://wiki.mik32.ru/CoreMark_Test и по этим данным кэш QSPI достаточно эффективен на задачах, близких к реальным.

 

CoreMark ни разу не близок к реальным задачам. Это просто ещё одни попугаи, но даже в них Амур оказывается в два раза ниже по частоте и почти полтора раза по коремаркам на мегагерц, если сравнивать его с допотопным копеечным STM32F103RB. 😞

 

[jcxz 184]

В 18.01.2024 в 21:12, mantech сказал:

Может тогда и объясните дремучему, зачем ее сделали, присоединили напрямую к процессорной шине, без всяких шинных переключателей и пр.. ? Думаю не просто по глупости)))

Очевидно для того, чтобы ускорить доступ CPU к ней. Так как только CPU будет иметь к ней доступ, а следовательно ему не нужно будет делить её с другими bus-master-ами. А также сам CPU сможет распараллелить обращение к CCM/TCM с обращением к другому региону ОЗУ. Что тоже увеличивает скорость выполнения, даже если вся ОЗУ работает на одной частоте.

В 18.01.2024 в 21:12, mantech сказал:

Перепутал, кортекс М4 с М7)))

У вас показания постоянно меняются... То пишете, что у всех STM ОЗУ работает не на частоте ядра (видимо даже у тех, у которых и TCM нету   )

В 18.01.2024 в 15:47, mantech сказал:

Не у всех. В СТМах там только TCM память на частоте ядра, а она далеко не все ОЗУ.

То уже на только некоторые M7 перескочили. Причём - опять неизвестно какие.

Так пойдёт - и ещё через сообщение вообще на x86 перескочите.... 

В 18.01.2024 в 21:12, mantech сказал:

И как видно тут скорость памяти и проца явно не одна и та же, правда?

Не умею угадывать по картинке - о каком МК идёт речь? И откуда выдрана эта картинка. Но есть подозрение, что вы опять не сумели прочитать даташит, кроме этой картинки.

В 18.01.2024 в 21:12, mantech сказал:

Ну и еще вопрос на засыпку, объясните, коль память в кортекс М работает со скоростью проца, по вашему, следовательно зачем в М7 поставили кэш в ядро?

Причин может быть куча:

И более широкая шина доступа к кешу;

И наличие множества других bus-master-ов в сложном МК (коими как правило являются МК с ядром M7), с которыми ядру нужно конкурировать за доступ к памяти;

И наличие в составе МК разной памяти, разной производительности (flash, внешней памяти разного рода и т.д.), чтобы не делать отдельные кеши для каждой такой памяти - уже есть общий кеш.

[kan35 7]

43 minutes ago, makc said:

Даже приведённые вами же коремарки показывают качественную разницу между внутренним флешом с широкой шиной и внешним QSPI Амура. Разница от полутора до двух раз. И это на синтетических тестах, а если попробовать там что-то посчитать типа подписи ЭЦП на эллиптических кривых, где много математики? Боюсь, что разница будет буквально в разы, извините за тавтологию. Ещё одна потенциальная проблема QSPI, с точки зрения выполнения из неё кода, это оптимизация интерфейса под блочный доступ. Случайный доступ малыми блоками оказывается крайне неэффективен (получаются высокие накладные расходы на адресацию и команды), а у встроенного флеша такой проблемы априори нет. Поэтому размер кэша в случае использования QSPI для хранения программ/данных нужно кратно увеличивать и делать интеллектуальнее. В общем ничего бесплатного нет. Поставили бы килобайта четыре с более сложной организацией - было бы заметно лучше. Кстати, в этом плане мне понравился подход у китайского BL702, который тоже на ядре RISC-V и использует "внешнюю" QSPI флешку для прошивки, хотя она и корпусируется в тот же корпус (SIP): они дают возможность использовать внутреннюю память (ITCM) в качестве кэша требуемого размера (настраивается) вплоть до 16 кБайт:

Причём кэш расположен очень близко к ядру и поэтому имеет минимальную латентность + максимальную ПСП шины. Благодаря этому контроллер может эффективно работать на частотах до 144 Мгц и имеет показатель ~3.1 CoreMark/MHz. Как говорится, почувствуйте разницу с Амуром (~ 1.16 CoreMark/MHz) при всём их поверхностном сходстве.

CoreMark ни разу не близок к реальным задачам. Это просто ещё одни попугаи, но даже в них Амур оказывается в два раза ниже по частоте и почти полтора раза по коремаркам на мегагерц, если сравнивать его с допотопным копеечным STM32F103RB. 😞

 

Ну опять 25, BL702 имеет ядро близкое к CM4-7.  Вы подбираете варианты, чтобы высказать негатив?

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

Эллиптические кривые - было бы интересно попробовать. Но задача, я бы сказал - специфическая, чтобы из результатов делать широкие выводы. Я кстати, недавно делал подсчет MD5 (где есть 64 битные аккумуляторы) на PIC18, вот там я мечтал об Амуре. Так что всё относительно 😉

Позволю выразить такое мнение: если бы Микрон начал массово выпускать продукты близкие по функционалу AVR или PIC18, то мы уже приобрели бы значительный технологический суверенитет. А производительности Амура достаточно для 99% задач для этого класса микроконтроллеров. Даже 16кБ ОЗУ это достойный объем.

[makc 192]

1 минуту назад, kan35 сказал:

Ну опять 25, BL702 имеет ядро близкое к CM4-7.  Вы подбираете варианты, чтобы высказать негатив?

Я бы не сказал, что оно близко к CM4-7. Скорее между М0 и М3 из-за особенностей системы команд RV32IMC и отсутствия регистра флагов в частности. И да, не я включил в таблицу https://wiki.mik32.ru/CoreMark_Test микроконтроллер STM32F103RB, который использует ядро Cortex-M3 и, формально, является аналогом ядер RV32IMC (Амур, MDR1206FI, BL702 etc).

Я не ищу негатив, т.к. стараюсь быть объективным.

5 минут назад, kan35 сказал:

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

Да не только мне, КМК. 😄

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

Эллиптические кривые - было бы интересно попробовать. Но задача, я бы сказал - специфическая, чтобы из результатов делать широкие выводы.

Это просто пример реализации математики с большими числами. Если кто-то делал другие тесты на реальных задачах, то было бы интересно увидеть их результаты. Coremark - это синтетические тесты, как бы они не были обоснованы.

7 минут назад, kan35 сказал:

Позволю выразить такое мнение: если бы Микрон начал массово выпускать продукты близкие по функционалу AVR или PIC18, то мы уже приобрели бы значительный технологический суверенитет. А производительности Амура достаточно для 99% задач для этого класса микроконтроллеров. Даже 16кБ ОЗУ это достойный объем.

Я согласен, что как замена AVR/PIC18 Амур вполне мог бы подойти, если бы у него была флешка внутри корпуса. Но её нет, поэтому увы и ах.

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

[mantech 35]

В 18.01.2024 в 15:47, jcxz сказал:

И зачем кеш для внутренней ОЗУ МК? Это ОЗУ во всех МК такого уровня и так работает на частоте ядра.

А не вы в показаниях путаетесь? Вот я привел пример, С М7 где ядро на 400, а ОЗУ на 200, что опять не так?

В 18.01.2024 в 17:01, jcxz сказал:

В первый раз слышу.   Которые на ядре Cortex-M? Уверены? Это в каких STM-ах? Назовите конкретные, в которых основное встроенное ОЗУ работает не на частоте ядра.

Кто виноват, что про М7 вы впервые слышите?))