large microprocessors?

I notice that the ram capacity (ignore program flash for now, but it tends to basically be proportionate) of microcontrollers seems to grow fairly continuously (say in 2x jumps) from very small (a dozen or so bytes in an 8 bitter, lots of MSP430's in the 128 to 1k byte range, Cortex M0's with 4k, etc.), up to about 32k (Cortex M4). Above that there are a few chips with 64k or 128k, that are quite expensive, and above that not much is available til you get to external DRAM which on ready-made boards usually starts at 32 meg or even 64 meg (Olimex Olinuxino) or 512 meg (Raspberry Pi). So there is a big jump from 32k to 32 meg. It would be nice to have a low cost, single chip, 256k or 1 megabyte device but this doesn't seem to exist.

Is there some technical reason for this, or is it just a market-determined thing? I know that desktop cpu's often have megabytes of sram cache, so it's certainly technologically feasible to do something similar with a smaller cpu.

Thanks.

Reply to
Paul Rubin
Loading thread data ...

On-chip ran is usually SRAM, and that's usually at least a factor of six time less dense than DRAM, so large on-chip memories usually require fairly large dies. And it's worse in practice since most microcontrollers are not implemented in the latest processes, and DRAM process are highly optimized for density, both of which multiply the overhead.

Things like eDRAM are possible, but require considerable extra processing in the fab, so are largely impossible from a cost perspective for low cost devices.

Since external DRAMs are (mostly) commodity items, the price pressure on the manufacturers are severe, leading to excellent price per bit.

Smaller external DRAMs are certainly possible, but there's not much of a price break below 32MB or so.

I suspect we'll see stacked dies before too long, which would provide the large capacity without the hassle of an external DRAM.

Reply to
Robert Wessel

Nope. Renesas SH7262 1024k. A very nice toy. Very powerful. .-)

It is existing. You did not search good enough.

But it is only need for a few application and so it is expensive. (arround 10Euro for high volume, 20Euro if you buy a few) This is my prototypboard:

formatting link

You see the advantage? The huge internal sram made it possible to use this kind of controller on a selfmade twoside PCB.

Play some music:

formatting link

Good enought for playing 320kbit MP3 with libmad.

Olaf

Reply to
Olaf Kaluza

Thanks. This appears to be an older and rather expensive part with a not-so-common architecture (Hitachi SH2) but it's good to know about.

Reply to
Paul Rubin

Hi Paul

The newest (for me) is ARM with PoP memory with higher RAM/flash is needed. But they might be a nightmare minimize solder ball defects. But alternative to let the package sit beside the microprocessor is worse because then more PCB copper layers are needed:

formatting link
Quote: "... Two or more packages are installed atop each other, i.e. stacked, with a standard interface to route signals between them. This allows higher component density in devices, such as mobile phones, personal digital assistants (PDA), and digital cameras. ..."

Example of PoP usage - only possible because ARM are so low-power:

formatting link

GTA04 GTA04A5 with 1GiB flash and 1GHz ARM:

formatting link
formatting link

Manual and schematic for GTA04 revision A3...A5:

formatting link

Glenn

Reply to
Glenn

Thanks, I remember seeing that on the original Beagleboard but I was more interested in what was around on single chips.

Wow, cool, though too expensive for me to think about ;-). I like that the Open Moko concept is still alive but I think it's better to have a data-only device and a separate phone.

Reply to
Paul Rubin

Putting DRAM on chip would have some interesting architectural features. Assuming 2 MiB DRAM = 16 Mib organized as 4096x4096 bits. The 12 high order bit will activate a row and all the 4096 bits in the column go through the column amplifiers back to the original cells. As a side product, all the 4096 column bits (512 bytes) could be latched in parallel, while a typical external DRAM uses a data selector to select a few bits or few bytes before latched out to external pins.

With all column bits latched on-chip, this would act also as a cache for "free", as long as the access is within the same 512 byte column. To significantly reduce miss rates, use separate 512 byte latches for data and instructions.

Reply to
upsidedown

It is an SH2A. This has some advantage over the old SH2. For example

16 register bank for a fast IRQ.

Olaf

Reply to
Olaf Kaluza

You're basically describing fast-page-mode DRAM. The problem of integrating DRAM onto a logic process remains, however.

OTOH, you could do the exactly same thing on an SRAM array if you wanted.

Reply to
Robert Wessel

STM32F4xx have 192kb or 256kb RAM and 1Mb or more of Flash. These are excellent Cortex-M4 devices.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

Thanks! I think I saw these before, but forgot about them. The STM32F4 Discovery board uses the STM32F407VGT6 which has 192kb of ram and a lot of other cool stuff too. I just spent a while looking at the data sheet. Memory protection, peripheral interfaces galore, 4k of ultra-low-power backup SRAM, realtime clock, hardware RNG, what's not to like? Wow! This thing can reach into areas where I had been thinking of using a Linux board with DRAM.

I remember having some issue with the Discovery board, probably about the toolchain, but as pure hardware goes it's pretty impressive.

Reply to
Paul Rubin

32-bit microcontrollers usually have significantly more ram than 8/16-bit microcontrollers in the same price class. But I haven't seen many with more than 128 KB (Freescale's M4 series stops there) - Freescale's MPC56xx PPC-based chips are the only ones I've used, and they don't count as small or low-cost.

It's not actually a question of the "latest" processes, but the "optimised" process. When making a chip design, you have a lot of factors to consider - then number of layers, the types of layers, the size of the geometry, etc. The layer stackups suited for DRAM, SRAM, Flash, and low-power digital, high-speed digital, high accuracy analogue, and low-power analogue are all different. So when a designer wants to combine a large SRAM with a fast microcontroller on the same die, he must choose between having the SRAM larger, slower, and more expensive per bit - or having the microcontroller larger, slower, and more power-consuming.

Stacked dies do exist, as do side-by-side multi-die chips. But they are a lot more expensive to manufacture and test, and introduce big challenges for power distribution on the die, and heat dissipation. It is certainly a technology that is up-and-coming for memories (DRAM and Flash), but in these chips you have multiple identical dies which makes it much easier. I've seen articles about I/O standards and drivers aimed at in-chip inter-die buses, but I won't hold my breath waiting for them to appear in low-cost microcontrollers.

Reply to
David Brown

Sounds like a PDP-11/34 on chip :-).

192 KiB might be on the low side for Linux, but some older RSX-11 or early Unixes style OSes would run fine in this amount of RAM. Of course, these OSes were disk based, i.e. programs (and overlay segments) were loaded from disk into core/RAM, thus some (shared) Flash or even rotating disks might be needed for program storage.

But still it might be interesting to develop processor arrays, in which tasks to be reconfigured much faster than burning Flash.

Reply to
upsidedown

In the small processors the amount of RAM requirements for code compiled with a good compiler is typically 16% of ROM and for assembler typically 20%. When we were doing studies on this a few years ago these numbers were remarkably constant.

(Before someone says it is application dependent, it is but so is the selection of the processor application dependent) On the larger processors these numbers don't hold as well.

w..

Reply to
Walter Banks

I think you addressed the caution I'd add. I'd just word it differently.

When you go to a doctor because you are sick, it's not appropriate for the doctor to immediately start out telling you what the most likely cause of your illness is based upon what is more likely based on everyone else who gets sick. The doctor should listen to the symptoms (details) of your situation. Even then, statistics don't help decide what you have. It's always in the details. After the doctor determines what you have, then your illness becomes part of the statistics.

The only thing reason a doctor should be thinking about "most probable" in your case should be about saving money in tests, not in determining what you have. And statistics are most useful when allocating annual budgets. Financial stuff. Not in deciding cases. That should be based on the individual facts of the situation.

Same thing with processor choices.

So 16%/20% is great information for those making business decisions about product placement and features. But not so great when you face a task at hand.

Different things.

Jon

Reply to
Jon Kirwan

Those numbers sound high for 8 bit micros ?

The mainstream 8051 families, come in around 3~6% of Max Code, at the Intel choices of 128:4096 and 256:8192 and the more modern 4096:65536

Or, are you saying the chips were only 33% code-full,(but used all RAM) and so lifted the RAM:code ratio ? ;)

32 bit micros tend to have larger RAM numbers, as they get quite lazy with bits and bytes. Thus we see the NXP small 32 bit offerings with 25% ratio of RAM:CODE

The new Infineon variants have 16kB of RAM, which varies from 25% to 200%(!) of code.

Reply to
j.m.granville

If you want something newer, then Nuvoton has a series of Stacked-die parts, they call ARM Video SoC, come in gull wing LQFP-128 / LQFP-64 parts. See:

formatting link

Choice of 16MB or 32MB Stacked RAM. Some upcoming ones, even have ethernet MAC... (as well as USB).

-jg

Reply to
j.m.granville

choices of 128:4096 and 256:8192 and the more modern 4096:65536

lifted the RAM:code ratio ? ;)

bits and bytes.

of code.

The numbers came from a study we did of several hundred embed applications and reference designs. They are the used ram and rom in the application. The applications we looked at were specifically 8 bit data path processors. ROM was normalized to bytes (Microchip PIC 14 bit mid range for example)

w..

Reply to
Walter Banks

I agree that the ratio is application dependent, but in the study we did the standard deviation of ram rom ratios used was surprisingly small. This was specifically for processors with 8 bit data paths.

w..

Reply to
Walter Banks

I can believe programs on those small micros tend to use a few static storage areas for parameters, buffers, etc. but not tend to have concurrent tasks created on the fly, lookup structures of significant size built at runtime, languages with garbage collection, etc.: typical things done in programs on larger cpu's. Small cpu's constrain the programs and programming styles that can run in them. It's not that the algorithms with bottomless memory appetites have to curb their desires on those cpu's--it's that they normally aren't used on those cpus at all.

Reply to
Paul Rubin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.