Deutsch   English   Français   Italiano  
<vbn376$2empp$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 17:11:34 +0200
Organization: A noiseless patient Spider
Lines: 146
Message-ID: <vbn376$2empp$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <vak6f8$2tsqj$2@dont-email.me>
 <vak7c0$2ufit$1@raubtier-asyl.eternal-september.org>
 <vaki4u$303sg$1@dont-email.me>
 <vakjff$30c4f$1@raubtier-asyl.eternal-september.org>
 <val7d6$33e83$1@dont-email.me>
 <vamb0t$3btll$2@raubtier-asyl.eternal-september.org>
 <vamqfc$3e42u$1@dont-email.me> <20240828134956.00006aa3@yahoo.com>
 <van4v1$3fgjj$1@dont-email.me> <vbl591$286j0$1@paganini.bofh.team>
 <vbmfee$2bn2v$3@dont-email.me> <vbn15a$2fvl0$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 17:11:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="245842e44c78e95d3bc5cb773286c128";
	logging-data="2579257"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180dZo+fCMaj6+VBFtyOnZuu/lOwXpnmkM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:PD3e7lxqf2NwqHjKlV7BlHostqw=
In-Reply-To: <vbn15a$2fvl0$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 8356

On 09/09/2024 16:36, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 08/09/2024 23:34, Waldek Hebisch wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> And while microcontrollers sometimes have a limited form of branch
>>>> prediction (such as prefetching the target from cache), the more
>>>> numerous and smaller devices don't even have instruction caches.
>>>> Certainly none of them have register renaming or speculative execution.
>>>
>>> IIUC STM4 series has cache, and some of them are not so big.  There
>>> are now several chinese variants of STM32F103 and some of them have
>>> caches (some very small like 32 words, IIRC one has 8 words and it
>>> is hard to decide if this very small cache or big prefetch buffer).
>>
>> There are different kinds of cache here.  Some of the Cortex-M cores
>> have optional caches (i.e., the microcontroller manufacturer can choose
>> to have them or not).
>>
>> <https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization>
> 
> I do not see relevent information at that link.

There is a table of the Cortex-M cores, with the sizes of the optional 
caches.

>   
>> Flash memory, flash controller peripherals, external memory interfaces
>> (including things like QSPI) are all specific to the manufacturer,
>> rather than part of the Cortex M cores from ARM.  Manufacturers can do
>> whatever they want there.
> 
> AFAIK typical Cortex-M design has core connected to "bus matrix".
> It is up to chip vendor to decide what else is connected to bus matrix.

Yes.

However, there are other things connected before these crossbar 
switches, such as tightly-coupled memory (if any).  And the cpu caches 
(if any) are on the cpu side of the switches.  Manufacturers also have a 
certain amount of freedom of the TCMs and caches, depending on which 
core they are using and which licenses they have.

There is a convenient diagram here:

<https://www.electronicdesign.com/technologies/embedded/digital-ics/processors/microcontrollers/article/21800516/cortex-m7-contains-configurable-tightly-coupled-memory>

> For me it does not matter if it is ARM design or vendor specific.
> Normal internal RAM is accessed via bus matrix, and in MCU-s that
> I know about is fast enough so that cache is not needed.  So caches
> come into play only for flash (and possibly external memory, but
> design with external memory probably will be rather large).
> 

Typically you see data caches on faster Cortex-M4 microcontrollers with 
external DRAM, and it is also standard on Cortex-M7 devices.  For the 
faster chips, internal SRAM on the AXI bus is not fast enough.  For 
example, the NXP i.mx RT106x family typically run at 528 MHz core clock, 
but the AXI bus and cross-switch are at 133 MHz (a quarter of the 
speed).  The tightly-coupled memories and the caches run at full core speed.

> It seems that vendor do not like to say that they use cache, instead
> that use misleading terms like "flash accelerator".

That all depends on the vendor, and on how the flash interface 
controller.  Vendors do like to use terms that sound good, of course!

> 
>> So a "cache" of 32 words is going to be part of the flash interface, not
>> a cpu cache
> 
> Well, caches never were part of CPU proper, they were part of
> memory interface.  They could act for whole memory or only for part
> that need it (like flash).  So I do not understand what "not a cpu
> cache" is supposed to mean.  More relevant is if such thing act
> as a cache, 32 word things almost surely will act as a cache,
> 8 word thing may be a simple FIFO buffer (or may act smarter
> showing behaviour typical of caches).
> 

Look at the diagram in the link I gave above, as an example.  CPU caches 
are part of the block provided by ARM and are tightly connected to the 
processor.  Control of the caches (such as for enabling them) is done by 
hardware registers provided by ARM, alongside the NVIC interrupt 
controller, SysTick, MPU, and other units (depending on the exact 
Cortex-M model).

This is completely different from the small buffers that are often 
included in flash controllers or external memory interfaces as 
read-ahead buffers or write queues (for RAM), which are as external the 
processor core as SPI, UART, PWM, ADC, and other common blocks provided 
by the microcontroller manufacturer.

>> (which are typically 16KB - 64KB,
> 
> I wonder where you found this figure.  Such size is typical for
> systems bigger than MCU-s.  It could be useful for MCU-s with
> flash a on separate die, but with flash on the same die as CPU
> much smaller cache is adequate.

Look at the Wikipedia link I gave.  Those are common sizes for the 
Cortex-M7 (which is pretty high-end), and for the newer generation of 
Cortex-M35 and Cortex-M5x parts.  I have on my desk an RTO1062 with a 
600 MHz Cortex-M7, 1 MB internal SRAM, 32 KB I and D caches, and 
external QSPI flash.

> 
>> and only found on bigger
>> microcontrollers with speeds of perhaps 120 MHz or above).  And yes, it
>> is often fair to call these flash caches "prefetch buffers" or
>> read-ahead buffers.
> 
> Typical code has enough branches that simple read-ahead beyond 8
> words is unlikely to give good results.  OTOH delivering things
> that were accessed in the past and still present in the cache
> gives good results even with very small caches.

There are no processors with caches smaller than perhaps 4 KB - it is 
simply not worth it.  Read-ahead buffers on flash accesses are helpful, 
however, because most code is sequential most of the time.  It is common 
for such buffers to be two-way, and to have between 16 and 64 bytes per 
way.  These make a very big difference, especially with external memory. 
  They are attached to the flash interface or other external memory 
interface, rather than the processor.

> 
>> (You also sometimes see small caches for external
>> ram or dram interfaces.)
>>
>>
>>> A notable example is MH32F103.  Base model officially has 64kB RAM and
>>> 256KB flash.  AFAIK this flash is rather slow SPI flash.  It also
>>> has 16kB cache which probably is 4-way set associative with few
>>> extra lines (probably 4) to increase apparent associativity.
>>> I write probably because this is result of reasoning based on
>>> several time measurements.  If you hit cache it runs nicely at
>>> 216 MHz.  Cache miss costs around 100 clocks (varies depending on
>>> exact setting of timing parameters and form of access).
>>>
>>> Similar technology seem to be popular among chines chip makers,
>>> especially for "bigger" chips.  But IIUC GD use is for chips
>>> of size of STM32F103C8T6.
>>>
>>
>