>> ST can run up to 24 MHz with zero waitstates. >> At 72 MHz, they need to run with two waitstates so any load from flash >> will be slow. The preliminary datasheet does not mentions any >> memory accelerator, so max bandwidth to flash is in this case >> (24 MHz * 4 bytes) = 96 MB/s. > > You mean 192MBytes/s as the flash is 64-bit wide. Ie. similar to the > 200MBytes/s of the Luminary parts.As I said, the (brief) datasheet did not make it obvious that there was a 64 bit memory.> >> I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth, >> so either the datasheet brief is not telling the complete story, >> or the 90 MIPS is only when executing from SRAM > > Running from flash is typically slower than running from SRAM (Luminary > parts being the exception). But this is not due to bandwidth limitations. > 192MBytes/s provides more than enough bandwidth for running a 16/32-bit > instruction set at 72MHz. An average instruction is ~2.7 bytes and takes > ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required. > > So bandwidth is not an issue. The real issue with waitstates is that > branches > become more expensive.And fetching data from flash will also be more expensive.> > Wilco-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
New Cortex-M3 parts - This time CAN and Ethernet
Started by ●September 18, 2007
Reply by ●September 21, 20072007-09-21
Reply by ●September 21, 20072007-09-21
"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes: [...]> Running from flash is typically slower than running from SRAM (Luminary > parts being the exception). But this is not due to bandwidth limitations. > 192MBytes/s provides more than enough bandwidth for running a 16/32-bit > instruction set at 72MHz. An average instruction is ~2.7 bytes and takes > ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required. > > So bandwidth is not an issue. The real issue with waitstates is that branches > become more expensive.The ST product page says that the M3 (and the STM32) is a Harvard architecture. Does anyone know if this fact is "transparent" to code? Or do you need different instructions to access code and data spaces? On the AVR, for example, this causes a *lot* of problems when keeping constant data in flash. -- John Devereux
Reply by ●September 21, 20072007-09-21
"John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message news:87k5qjhgc2.fsf@cordelia.devereux.me.uk...> "Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes: > > [...] > >> Running from flash is typically slower than running from SRAM (Luminary >> parts being the exception). But this is not due to bandwidth limitations. >> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit >> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes >> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required. >> >> So bandwidth is not an issue. The real issue with waitstates is that branches >> become more expensive. > > The ST product page says that the M3 (and the STM32) is a Harvard > architecture. > > Does anyone know if this fact is "transparent" to code? Or do you need > different instructions to access code and data spaces? On the AVR, for > example, this causes a *lot* of problems when keeping constant data in > flash.Most Harvards use a unified address space and so don't have any issues with accessing code as data. The term is used when there are instruction and data buses that can be used in parallel. Pure Harvards that also have separate address spaces are rare. Wilco
Reply by ●September 21, 20072007-09-21
"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:> "John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message news:87k5qjhgc2.fsf@cordelia.devereux.me.uk... >> "Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes: >> >> [...] >> >>> Running from flash is typically slower than running from SRAM (Luminary >>> parts being the exception). But this is not due to bandwidth limitations. >>> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit >>> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes >>> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required. >>> >>> So bandwidth is not an issue. The real issue with waitstates is that branches >>> become more expensive. >> >> The ST product page says that the M3 (and the STM32) is a Harvard >> architecture. >> >> Does anyone know if this fact is "transparent" to code? Or do you need >> different instructions to access code and data spaces? On the AVR, for >> example, this causes a *lot* of problems when keeping constant data in >> flash. > > Most Harvards use a unified address space and so don't have any issues > with accessing code as data. The term is used when there are instruction > and data buses that can be used in parallel.Thanks Wilco, that's what I hoped for.> Pure Harvards that also have separate address spaces are rare.Well they are not *that* rare in microcontrollers - I thought it was worth checking (and couldn't tell for sure by skimming the documentation). -- John Devereux
Reply by ●September 22, 20072007-09-22
On Sep 21, 4:04 pm, John Devereux <jdREM...@THISdevereux.me.uk> wrote:> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes: > > "John Devereux" <jdREM...@THISdevereux.me.uk> wrote in messagenews:87k5qjhgc2.fsf@cordelia.devereux.me.uk... > >> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes: > > >> [...] > > >>> Running from flash is typically slower than running from SRAM (Luminary > >>> parts being the exception). But this is not due to bandwidth limitations. > >>> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit > >>> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes > >>> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required. > > >>> So bandwidth is not an issue. The real issue with waitstates is that branches > >>> become more expensive. > > >> The ST product page says that the M3 (and the STM32) is a Harvard > >> architecture. > > >> Does anyone know if this fact is "transparent" to code? Or do you need > >> different instructions to access code and data spaces? On the AVR, for > >> example, this causes a *lot* of problems when keeping constant data in > >> flash. > > > Most Harvards use a unified address space and so don't have any issues > > with accessing code as data. The term is used when there are instruction > > and data buses that can be used in parallel. > > Thanks Wilco, that's what I hoped for. > > > Pure Harvards that also have separate address spaces are rare. > > Well they are not *that* rare in microcontrollers - I thought it was > worth checking (and couldn't tell for sure by skimming the > documentation).Linear uniform address space for sure. In fact, you can run from flash to write new codes on sram, jump to run from sram and rewrite the flash. Flash, sram and I/O are all memory addresses. We have the LMI Cortex M3 for months, the STM32 is very similar, except for better low power modes. Power consumption is the major reason holding us back on using the LMI.> > -- > > John Devereux
Reply by ●September 23, 20072007-09-23
linnix <me@linnix.info-for.us> writes:> On Sep 21, 4:04 pm, John Devereux <jdREM...@THISdevereux.me.uk> wrote: >> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes: >> > "John Devereux" <jdREM...@THISdevereux.me.uk> wrote in messagenews:87k5qjhgc2.fsf@cordelia.devereux.me.uk... >> >> The ST product page says that the M3 (and the STM32) is a Harvard >> >> architecture. >> >> >> Does anyone know if this fact is "transparent" to code? Or do you need >> >> different instructions to access code and data spaces? On the AVR, for >> >> example, this causes a *lot* of problems when keeping constant data in >> >> flash. >> >> > Most Harvards use a unified address space and so don't have any issues >> > with accessing code as data. The term is used when there are instruction >> > and data buses that can be used in parallel. >> >> Thanks Wilco, that's what I hoped for. >> >> > Pure Harvards that also have separate address spaces are rare. >> >> Well they are not *that* rare in microcontrollers - I thought it was >> worth checking (and couldn't tell for sure by skimming the >> documentation). > > Linear uniform address space for sure. In fact, you can run from > flash to write new codes on sram, jump to run from sram and rewrite > the flash. Flash, sram and I/O are all memory addresses. > > We have the LMI Cortex M3 for months, the STM32 is very similar, > except for better low power modes. Power consumption is the major > reason holding us back on using the LMI.The STM32 does look really good. Although there are none at Digikey yet - and I would need new debugger hardware I guess. -- John Devereux
