Startup Combines CPU and DRAM

MojoKid writes "CPU design firm Venray Technology announced a new product design this week that it claims can deliver enormous performance benefits by combining CPU and DRAM on to a single piece of silicon. Venray's TOMI (Thread Optimized Multiprocessor) attempts to redefine the problem by building a very different type of microprocessor. The TOMI Borealis is built using the same transistor structures as conventional DRAM; the chip trades clock speed and performance for ultra-low low leakage. Its design is, by necessity, extremely simple. Not counting the cache, TOMI is a 22,000 transistor design. Instead of surrounding a CPU core with L2 and L3 cache, Venray inserted a CPU core directly into a DRAM design. A TOMI Borealis core connects eight TOMI cores to a 1Gbit DRAM with a total of 16 ICs per 2GB DIMM. This works out to a total of 128 processor cores per DIMM. That said, when your CPU has fewer transistors than an architecture that debuted in 1986, there is a good chance that you left a few things out--like an FPU, branch prediction, pipelining, or any form of speculative execution. Venray may have created a chip with power consumption an order of magnitude lower than anything ARM builds and more memory bandwidth than Intel's highest-end Xeons, but it's an ultra-specialized, ultra-lightweight core that trades 25 years of flexibility and performance for scads of memory bandwidth."

Comments

but...

[Anonymous Coward]

does it run GNU/Linux?

Re:but...

[robthebloke]

Multiple, low power, semi useless processor cores? Sounds like sony has just found the silicon to power the Playstation 4! :p

Either/or?

[Gwala]

Does it have to be a either-or suggestion?

I could see this being useful as an accelerator - in the same way that GPUs can accellerate vector operations. E.g. memory that can calculate a hash table index by itself. Stuffed in as a component of a larger system it could be a really clever breakthrough for incremental performance improvements.

Re:Either/or?

[Anonymous Coward]

Like Mitsubishi 3D RAM

They put the logic ops and blend on the RAM

The 3D-RAM is based on the Mitsubishi Cache DRAM (CDRAM (Cached DRAM) A high-speed DRAM memory chip developed by Mitsubishi that includes a small SRAM cache. ) architecture that integrates DRAM memory and SRAM cache on a single chip. The CDRAM was then optimized for 3-D graphics rendering and further enhanced by adding an on-chip arithmetic logic unit See ALU. (ALU (Arithmetic Logic Unit) The high-speed CPU circuit that does calculating and comparing. Numbers are transferred from memory into the ALU for calculation, and the results are sent back into memory. Alphanumeric data are sent from memory into the ALU for comparing. ) and video buffer.

performance vs. memory bandwidth

[Anonymous Coward]

> "that trades 25 years of flexibility and performance for scads of memory bandwidth"

Right... because memory bandwidth isn't one of the greatest bottlenecks in current designs...

Re:performance vs. memory bandwidth

[hattig]

And how much performance per clock are you going to get out of a 22,000 transistor chip, with what looks like 3 registers (and 3 shadow registers)?

One of the issues they had to deal with was that DRAM is usually made on a 3 metal layer process, whereas CPUs usually take a lot more layers due to their complexity.

This will have to compete with TSV connected DRAM, which will be a major bandwidth and power aid to conventional SoCs.

Re:performance vs. memory bandwidth

[tibit]

Perfect for networking -- switching, routing, ... Think of content addressable memory, etc.

Re:performance vs. memory bandwidth

[K. S. Kyosuke]

And how much performance per clock are you going to get out of a 22,000 transistor chip, with what looks like 3 registers (and 3 shadow registers)?

Quite a lot, I would guess. A stack-based design would give you 1 instruction per cycle with a compact opcode format capable of packing multiple instructions into a single machine word, which means a single instruction fetch for multiple actual instructions executed. Oh, and make it word addressed, that simplifies things a bit as well. In the end, you'll have a core that does perhaps 50%-100% as much clock cycles per second on a given manufacturing technology level (say, 60 nm), with just a single thread of execution, but with a negligible transistor budget and power consumption. The resulting effective computational performance per energy consumed will be at least one OOM better than the current offerings by Intel and AMD, although you first have to learn how to program it.

Map Reduce?

[complete loony]

So you could implement some simple map reduce operations and run them directly in RAM?

Re:Map Reduce?

[lkcl]

Aspex Semiconductors took this a lot further. they did content-addressable-memory. ok, they did a hell of a lot more than that. they created a massively-parallel deep SIMD architecture with a 2-bit CPU (early versions were 1 bit), with each CPU having something like 256 bits of memory to play with. ok, early versions had 128-bits of "straight" RAM and 256 bits of content-addressable RAM. when i was working for them they were planning the VASP-G architecture which would have 65536 such 2-bit CPUs on a single die. it was the 10th largest CPU being designed, in the world, at the time.

programming such CPUs was - is - a complete f*****g nightmare. you not only have the parallelism of the CPU to deal with but you have the I/O handling to deal with. do you try to fit the data 1-bit-wide per CPU and process it serially? or... do you try to fit the data across 32 CPUs and process it in parallel? (each CPU was connected to its 2 neighbours so you could do this sort of thing). or... do you do anything in between, because if you have only 1-bit-wide that means that the I/O is held up, but if you do 32-bits across 32 CPUs you process it so quick that you're now I/O bound.

much of the work in fitting algorithms onto ASPs involved having to write bloody spreadsheets in Excel to analyse whether it was best to use 1, 2, 4 .... 32 CPUs just to process the bloody data! 6 weeks of analysis to write 30 lines of code for god's sake!

it gets worse: you can't even go read a book on algorithms for hardware because that doesn't apply; you can't go read a book on algorithms for software because _that_ doesn't apply. working out how to fit AES onto the Aspex Semi CPU took me about... i think it was 6 weeks, to even _remotely_ make it optimal. i had to read up on the design of the 2-bit Galois Field theory behind the S-Boxes, because although you could do 8-bit S-Box substitution by running 256 "compare" instructions, one per substitution, in parallel across all 4096 CPUs, it turned out that if you actually implemented the *original* 2-bit Galois Field mathematical operations in each of the 2-bit CPUs you could get it down to 40 instructions, not 256.

and that was just for _one_ part of the Rijndael algorithm: i had to do a comprehensive detailed analysis of _every_ aspect of the algorithm.

in other words, everything that you _think_ you know about optimising software and algorithm design for either hardware or for software is completely and utterly wrong, for these types of massively-parallel map-reduce and content-addressable-memory CPUs.

that leaves them somewhere in the very very specialist dept, and even there, they have problems, because it takes so long to verify and design a new CPU. when the Aspex VASP-F architecture was being planned, it was AMAZING! wow! 100x faster than the best Pentium-III processor! of course, within 18 months it was only 20x better than the top-of-the-line Pentium that was available, and by the time it _actually_ came out, it was only 5x better than a bunch of x86 CPUs, which are a hell of a lot easier to program.

it was the same story for the next version of the CPU, even though that promised to have 64k processing elements...

Re:Map Reduce?

[Pieroxy]

Why in the world is people always saying the word Map Reduce nowerdays, I hear it every week atleast. Like it would be the solution to world war 3.

Since WWIII hasn't happened yet, you cannot rule out the fact that it *might* be the solution.

Re:Map Reduce?

[Andy_R]

I know this is probably going to sound flippant, but I'm sure there is a genuine reason and I'd be interested to hear it... Why not just write it both ways and test?

Better yet, why not get the compiler to try different parallelisations and use a genetic algorithm to optimise automatically?

Re:Map Reduce?

[PiMuNu]

Why in the world is people always saying the word Map Reduce nowerdays.

Distributed computing...

Processing In Memory

[Anonymous Coward]

This isn't new. The MIT Terasys platform did the same in 1995, and many have since. Nobody has yet come up with a viable programming model for such processors.

I'm expecting AMD's Fusion platform to move in the same direction (interleaved memory and shader banks), and they already have a usable MIMD model (basically OpenCL).

Re:Processing In Memory

[Omnifarious]

*nod* I'm not surprised it isn't new.

I've noticed that locality has become more and more important as speeds have gone up. I kind of wonder if something like this isn't the future.

I'm noticing, for example, that programming models involving channels and lots of threads have shown up and seem like a viable model for something like this. Erlang and Go are the two languages that do this that I can think of right offhand.

Re:Processing In Memory

[master_p]

Nobody has yet come up with a viable programming model for such processors.

The Actor model fits well to this type of CPU. Each CPU could be considered an actor.

A Jump instruction to a memory bank of another CPU could be translated as an Actor call to be executed in parallel with the caller.

A call instruction to a memory bank of another CPU could be translated as a parallel call and wait instruction.

A load/store instruction could be translated as a queued request for retrieving/updating data.

This provides a very natural multitasking solution, that provides good expandability both in memory and processing power by adding more memory/CPU chips.

An object-oriented programming language could spread out parallel objects into as many CPUs as possible.

Re:Processing In Memory

[Anne Thwacks]

C++ is your problem. Algol68 dealt with these issues over 40 years ago.There were two problems with Algol68:

It was not American (NIH)

The best training manual for it was called "Algol68 with fewer tears"

Other than that, it was able to handle parallelism, and most everything else, in a relatively painless manner.

For those who actually LIKE pain, there is always Occam.

Just a first step...

[bradley13]

Really, this was inevitable, and this first implementation is just a first step. Future versions will undoubtedly include more functionality.

Current processors are ridiculously complicated. If you can knock out the entire cache with all of its logic, give the processor direct access to memory, and stick to a RISC design, you can get a very nice processor in under a million transistors.

Re:Just a first step...

[lkcl]

the cache is there because the speed of DRAM, regardless of how fast you can communicate with it, still has latency issues on addressing.

to do the "routing" to address a 4-bit bus, you need 1/2 the number of transistors than if you addressed a 2-bit bus. each time you add another bit to the address range, you have increased the latency of access.

if you were to provide entirely random-access to an entire 32-bit range you would absolutely kill performance. so, what RAM IC designers do is they go "ok, you're not going to get 32-bit addressing, you're going to get 14-bit addressing, you're going to have to read an entire page of 1k or 2kbits, and you're going to have to have parallel ICs, the first IC does bits 0 to 1 of the data, the second IC does bits 2 and 3 etc."

this relies on the design of the processor having a VM architecture - paging.

but the same principle applies *inside* the processor: even just decoding the addressing, in the MMU, it's *still* too much latency involved.

so this is why you end up with hierarchical cacheing - 1st level is tiny, 2nd level is huge.

even with RISC designs you _still_ have to have 1st and 2nd level caches in order to remain competitive. if you've ever seen a picture of a RISC CPU, it's astounding: the actual CPU is like 1% of the total area; caches are huuuge by comparison, crossbar routing takes up 50% of the chip and the I/O pads, required to be massive in order to handle the current, can take up something like 5% of the chip (guessing here, it's been a while since i looked at an annotated example CPU).

Why not a hexagonal design?

[G3ckoG33k]

Speaking of unconventional design, why don't we see hexagonal or triangular CPU-designs? All I have seen are the Manhattan-like designs. Are these really the best? Embedding the CPU inside a hexagonal/triangular DRAM design should be possible too. What would be the trade-offs?

Re:Why not a hexagonal design?

[PSVMOrnot]

It probably boils down to ease and efficiency of manufacture. Certainly for the core of the cpu I would imagine it's because squares tesselate nicely on the silicon wafer.

Re:Why not a hexagonal design?

[mdenham]

Ease, yes. Efficiency, especially the amount of the wafer that's wasted due to it being circular initially, not so much.

A triangular layout probably would be ideal - you could (or at least, should be able to) adapt existing equipment (instead of two cuts at right angles, you make three cuts at 60-degree angles - hexagonal layouts would require either piecing together triangles produced this way, casting much smaller ingots such that it's one chip per wafer, or stamping out the hexagons), and you reduce waste somewhat (depending on the size of the chip and the size of the initial wafer).

However, the problem with triangular layouts (and hexagonal, for that matter) is that it involves cutting along planes the original ingot (which is a single huge silicon crystal) won't naturally fracture in.

So... unfortunately, we're stuck with square chips (if we start building up 3D chips, we'll have the option of cubes and octahedra) because of nature.

Re:Why not a hexagonal design?

[dkf]

hexagons would probably tessellate even better, with less waste.

Ease of manufacture is still the case though. Cutting them out would be a bitch though.

That's why triangles would be good; they can act as parts of hexagons, and yet you can cut them out with straight cuts. OTOH, you'll have to deal with acute angles in the result, which might have its own set of problems. Squares are likely a reasonable compromise, all things considered.

Re:Why not a hexagonal design?

[TechnoCore]

Guess it is because the silicon wafers that a CPU's are made from must be cut along the atomic layers of silicon. Silicon in solid form at room temperature crystalizes into a diamond cubic crystal structure. It is very strong, but also very brittle. It is easy to cut along stright lines, following the faces of an octahedron. To cut at any other angle would propably be very difficult and risky. Maybe it would therefore be hard to cut a wafer it trianglular shapes?

Their money isn't old enough.

[Anonymous Coward]

They're innovating?

T-minus two days until they've been hit with 13 different patent lawsuits by companies that don't even produce anything similar.

Sorry about your luck!

All on one chip

[jaweekes]

I'm just wondering and maybe it exists already, but why not make everything on one chip? The CPU, memory, GPU, etc? Most people don't mess with the insides of their computer, and I'm guessing that it will speed up the computer as a whole. You won't even need to make it high-performance. Just do a I3 core with the associated chipset (or equivalent), maybe 4GB of RAM, some connectivity (USB 2, DVI, SATA, Wi-Fi and 1000Base-T) and you have it all. The power savings should be huge as everything internally should be low voltage. The die will be huge but we are heading that way anyway.
Am I talking bollocks?

Re:All on one chip

[BeardedChimp]

You are basically describing a system on chip. You have one in your phone.

Re:All on one chip

[stevelinton]

There are basically two problems:

1. The external connectivity -- SATA, USB, ethernet, etc. needs too much power to easily move or handle on a chip (and the radio stuff needs radio power). You can do the protocol work on the main chip if you like, but you'll need amplifiers, and possibly sensors off chip.

2. DRAM and CPUs are made in quite different processes, optimised for different purposes. Cache is memory made using CPU processes (so it's expensive and not very dense). These guys are trying to make CPUs using DRAM processes, which are slow.

Re:All on one chip

[tibit]

It's not about how much die area the microcode takes, it's about how much die area everything else needed to run this microcode efficiently is taking! Properly designed opcodes would obviate trace generator, branch predictor, register reallocator, parts of northbridge, etc. Now that takes a lot of space. In case of x86 ISA it's not about legacy opcodes really, it's about all the missing opcodes (and registers) that a well performing architecture should have. That's what I mean by it being 30 years behind. Even fairly aged DSPs like 2100 architecture from Analog Devices have dedicated address generators and loop generators that are fully controlled by the code -- this alone means you don't need prediction logic, and this could be exploited by the northridge (were it in a general purpose CPU) to optimally schedule DRAM cycles.

synthesis

[lkcl]

there's a problem with doing designs like this. the tooling for CPUs is very very specific: 28nm, 32nm, 45nm - all those companies that do the simulations where they charge something like $USD 250,000 per week to license their tools like mentor do - have written the tools SPECIFICALLY for those geometries.

if you wander randomly outside of those geometries you are either on your own or you are into some unbelievably-high development costs.

why is this relevant?

it's because the DRAM manufacturers do *not* stick to the well-known geometries: they vary the geometry in order to get the absolute best performance because the cell layout is absolutely identical for DRAM ICs. and, because those cells _are_ identical, the verification process is much simpler than is required for a complex CPU.

in other words, this company is trying to mix-and-match two wildly different approaches. in other words, what he's doing is either incredibly expensive or is sub-optimal. which begs the question: what's it _for_?

Re:So, is it a CAM or a DRPU?

[somersault]

Missed a D - better make that DUM-CRAP*.

I wonder, how much DUM-CRAP could we fit into a single PC?

* this name is by no means a reflection on what I think of the tech - it sounds like a pretty cool idea.

Don't count this out yet

[fyngyrz]

Useless? My key question would be does it have decent speed integer multiply and perhaps even divide instructions. A whole heck of a lot can be achieved if you have, say, the basic instruction set of a 6809, but fast and wide (and it didn't even have a divide... so we built multiply-by-reciprocal macros to substitute, that works too.)

I know everyone's used to having FP right at hand, but I'm telling you, fast integer code and table tricks can cover a lot more bases than one might initially think. A lot of my high performance stuff -- which is primarily image processing and software defined radio -- is currently limited considerably more by how fast I can move data in and out of main memory than it is by actually needing FP operations. On a dual 4-core machine, I can saturate the memory bus without half trying with code that would otherwise be considerably more efficient, if it could actually get to the memory when it needs to.

Another thing... when you're coding with C, for instance, the various FP ops can just as easily be buried in a library, then who cares why or how they get done anyway, as long as they are? With lots-o-RAM, you can write whatever you need to and it'd be the same code you'd write for another platform. Just mostly faster, because for many things, FP just isn't required, or critical. Fixed point isn't very bard to build either and can cover a wide range of needs (and then there's BCD code... better than FP for accounting, for instance.)

Signed, old assembly language programmer guy who actually admits he likes asm...

Re:Don't count this out yet

[ByOhTek]

pfft. floating point sucks anyway.

typedef struct FRACTION_STRUCT
{ //numerator/denominator * 10^exponent
    int numerator;
    unsigned int denominator;
    int exponent;
} Fraction;

Re:Don't count this out yet

[buglista]

Exactly. ARM2 didn't have FP, people still wrote some extremely good stuff for it. (You can always approximate it by pretending that the last 10 bits are 2^-1, 2^-2, ... 2^10 and multiplying out - in fact shifting - when you need the answer. I've written graphics demos like that.)

Re:Don't count this out yet

[smi.james.th]

You're assuming a rational number there.

Wait. Hang on. Forget that I pointed that out... :P

Re:Don't count this out yet

[walshy007]

Exactly. ARM2 didn't have FP, people still wrote some extremely good stuff for it.

Nintendo DS doesn't have an fpu on either cpu.

Re:Don't count this out yet

[ByOhTek]

it still manages a few cases classic floating point would miss. However, if you give me an infinitely wide register, I would happily work on something that would handle irrational numbers :-)

Re:Don't count this out yet

[tibit]

Agreed. I'm working on a digital oscilloscope display system and that thing might be very useful in this application -- where you need lots of bandwith, but also plenty of storage. Say, zooming, filtering, scaling of one second long acquisition done at 2Gs/s, using a 12 bit digitizer. You tweak the knobs, it updates, all in real time. In the worst case, you need about 120 Gbytes/s memory bandwidth to make it real time on a 30FPS display. And that's assuming the filter coefficients don't take up any bandwidth, because if they do you've just upped the bandwidth to terabytes/s.

Re:Don't count this out yet

[TeknoHog]

Signed, old assembly language programmer guy

I see what you did there.

Re:Don't count this out yet

[fyngyrz]

That's a bit shifty, don't you think? I don't mean to negate your point, but too, it's beyond my power to complement you -- I'm somewhat over a barrel. Perhaps if you add one to your argument, we'd have something else. Logically speaking. HCF.

Re:Don't count this out yet

[wik]

You must be thinking of some other processor. The first released Alpha silicon, Alpha 21064, had a pipelined FPU for adds/subtracts/multiplies and a non-pipelined floating-point divide unit.

Re:Don't count this out yet

[raynet]

I raise my carry to you, sir.

Humm, IBM did it first.

[JimCanuck]

IBM sells CPU's that have DRAM onboard for quite a while, IBM developed it, patented it, and sells it as "eDRAM" aka "embeddedDRAM".

I guess IBM's POWER7 processor family powering such things like, Sony's PlayStation 2, Sony's PlayStation Portable, Nintendo's GameCube, Nintendo's Wii, and Microsoft's Xbox 360. All have eDRAM.

Maybe news articles should be checked to see if they are really news or not before posting?

Caches

[unixisc]

Normally, in any CPU, you have 1, 2 or even 3 levels of cache - level one being the fastest accessed from the CPU, and higher numbers involving more latency. The whole idea being that data that is frequently accessed should be either within the CPU's register files, or within the level 1 cache. Failing that, the level 2 cache, failing that, level 3 cache or main memory. So for this CPU, the DRAM can be considered an L4 cache?

Incidentally, is it an SoC? Does all the support circuitry - to the South Bridge, PCIx, USB, 802.11 and other peripheral interfaces - get included here? And can someone attach a few extra GB externally to give what's effectively an L5 cache?

I can't say I like this approach - I'd prefer it if the CPU and interface logic was on 1 chip, and the memory on another.

Re:Caches

[cbhacking]

Umm... no. You've apparently completely failed to notice the part where this CPU *has* no cache, at least certainly no L2 or L3. Instead, it talks directly to main memory (which it's embedded in, at least in a portion of, and has extremely fast access to). More accurately, any given gigabit (128MB of RAM) is the cache for one of these CPUs.

I don't know how quickly they can communicate across the DIMM (each 2GB has 16 CPUs, so some intercommunication is critical) - maybe that's more akin to traditional memory access speed - but it's still a ludicrous amount of "cache" and eliminating the multiple levels of caching greatly simplifies the memory controller logic.

That said, I wonder how useful a CPU core with so few transistors (and apparently a low clock speed) will be. It's certainly not going to have all the peripheral interfaces you mention - not even close.

cray3/super scalar system

[Rachael]

cray where heading that way also in the 90ish with their sss system, they where just adding many 2048 cpus per block.

http://en.wikipedia.org/wiki/Cray-3/SSS
http://www.thefreelibrary.com/CRAY+COMPUTER+CORP.+COMPLETES+INITIAL+DEMONSTRATION+OF+THE+CRAY-3...-a016628331

Reinvention from 1984

[AlecC]

Looks like they have reinvented the inmos Transputer, from about 1984. http://en.wikipedia.org/wiki/Transputer . They alwaysintended to take that multicore, but never got that far. But it looks remarkably similar in intention.

Re:So, is it a CAM or a DRPU?

[Anonymous Coward]

The idea is not new and lots of products having a CPU on the RAM die exist. Sun had this on graphic cards for example.
The missing FP is not a great deal since FP can be calculated with ints if needed - but it shall get an FP in the follow up products to stop the rants.
The dirty secrect of the computer industrie is that the CPU has to wait "lots" of cycles to go to memory and back since the CPUs are much higher clocked that RAM plus there are other chips in between...
RAM can be added in system designs here - but you simply get more CPUs as well ;-)
I guess market acceptance is always a matter of integration effort so Linux it shall run and have broad IO chipsets available.
Well done - hope it succeedes

Old idea, but better than you expect

[Theovon]

My research area is computer architecture.

This idea of moving compute into the RAM has been around a long time. Papers have proposed everything from adding simple ALUs to the DRAMs to fully functional microprocessors. Most assume that these are "accelerators" for common vector operations and such, while the heavy lifting is done by beefier cores, but the idea if doing all the compute embedded in a DRAM has been proposed and evaluated before.

One thing we've learned in the past few decades is that modern processors are limited by memory latency and bandwidth. A Sun engineer (talking about Rock) pointed out that a modern out-of-order processor performs a race between last-level cache misses. When you have to go out to DRAM, the CPU instruction window fills up with as much dependent work as possible, before it completely stalls because everything is dependent on that one miss. When that data finally arrives, the CPU blasts through that work really fact, and then soon stalls out again on another miss. OOO processors resolve this (somewhat) by the instruction window, while Rock solved it by speculative execution. One of the reasons for Sandy Bridge's excellent performance is the very large instruction window that can absorb more of the LLC miss stall time.

And so, although these processors have other advantages, OOO processors dedicate a huge amount of logic just to dealing with the cache miss latency. If there were no such latency, then they could get the same performance with a hell of a lot less hardware. Although I haven't seen the figures, my suspicion is that for general computation, TOMI will blow the doors off of whatever else we've got in both performance AND energy efficiency. Only when you have a specialized compute kernel whose working data fits in the cache can you comparatively benefit from something like Sandy Bridge. (I realize that's an overly strong statement, because lots of general purpose workloads have good locality, but nevertheless main memory is a major bottleneck for most workloads.)

+FPGA FTW

[Doc Ruby]

left a few things out--like an FPU, branch prediction, pipelining, or any form of speculative execution [...] it's an ultra-specialized, ultra-lightweight core that trades 25 years of flexibility and performance for scads of memory bandwidth.

Embed a fat FPGA in this chip well-interconnected to DRAM and CPU, and you get all those things. You might even replace the current chip's buses with FPGA for both data distribution and inline logic. Or make a discrete (but well-interconnected) onchip FPGA able to power down when not in use, and keep the low power consumption except when it's necessary. Turn on the FPGA for speed, or when the FPGA logic is so efficient that it's lower power than doing it in the CPU.

For somewhat lower power consumption, and better performance in many tasks, but less flexibility, embed a DSP in the chip instead of the FPGA.

Or both: DSP as ALU, FPGA as CLU (and flexible ALU, and beyond), on the chip with a simple processor to run the OS and main app threads. Bringing all the ports and buses to RAM all on the chip makes it all wicked fast. De/selecting these modules for power on demand (or in thread init) saves energy.

Re:+FPGA FTW

[Doc Ruby]

Yes, I'm very excited about the Zynq, but it doesn't embed the RAM onchip, which is what's interesting about this new processor. The dual Cortex A9 is far more complex than the CPU on this new chip, in part to speed execution that's slowed by offchip RAM latency.

But indeed an FPGA and the AMBA bus into a simple chip with onboard RAM is interesting. Though for Xilinx's market for FPGA apps they'd be better with much more than 2GB onchip RAM; more like 128GB or a TB. And onboard optical Gbps ethernet, as long as I'm wishing for Xilinx.

Same old story...

[Baldrson]

Ever since Illiac IV its been the same story:

Can't really solve the mutex problem so pretend it doesn't exist and screw the programmers by pretending to solve the main memory latency problem with CPU-local memory.

The "innovation" over Illiac IV is to call it "multicore".

PS: There is a solution but since I can't afford the patent fees, its not going anywhere.

Combined CPU and DRAM

[rhfish]

Wow, we're on Slashdot......almost like being On The Cover of the Rolling Stone.

Answers to various questions and comments:
- We support the Linux toolchain; compilers, debuggers, etc., fortunate to have some of the original gcc team. Ported pieces of various kernels to TOMI Aurora to make certain we had not left anything out and to test the memory manager. Aurora was for use in a tablet type device.
- TOMI Borealis was optimized for Big Data and unstructured data apps like MapReduce that choke at the Memory Wall. Linux could probably be ported without too much difficulty. Most massively parallel installations will use something really light weight instead.
- Potential users said give them more integer cores instead of adding FPU. We gladly cede the FP world to Itanium.
- For raw FP horsepower within a reasonable power budget, its tough to beat Nvidia's GPU approach. That is probably why 3 of the top 10 supercomputers are GPU accelerated. http://www.top500.org/ GPU-type architectures will likely be the future of scientific computing. Venray is focused on Memory Wall limited areas such as Big Data.
- From the computer architecture perspective, the distinction between Big Data and Small Data is whether the datasets will primarily fit within the onboard caches. Video compression, graphics acceleration, encryption, and much of LINPAC (http://en.wikipedia.org/wiki/LINPACK) would be classed as Small Data since most of the computing can be done without leaving the caches (high locality). Legacy architectures choke on Big Data since the datasets overflow the caches and there is much much less data reuse.
- MapReduce is important because it is currently the most visible Big Data application thanks to Google. http://research.google.com/archive/mapreduce.html
- Venray believes Big Data applications are the future of computing. So does McKinsey Consulting. http://www.mckinsey.com/Insights/MGI/Research/Technology_and_Innovation/Big_data_The_next_frontier_for_innovation We leave it to others to accelerate MS Office and Call of Duty.
- The future of Big Data appears to be RAM resident, not disk, not even flash. (See Fred Ho's work at IBM.) https://www.ibm.com/developerworks/mydeveloperworks/blogs/fredho66/?lang=en_us
- re: Mitsubish 3DRAM and other similar ventures, iRAM, Exacute, Gilgamesh, etc....they embedded DRAM into logic. Contrast with TOMI that embeds CPU cores into DRAMs.....our benefits are performance and particularly cost: http://www.edn.com/photo/294/294788-microprocessor_vs_memory_transistors_graph.jpg
- We chose a modified RISC architecture rather than a special purpose one such as Gilgamesh in order to make programming simpler with well understood Linux tools such as gcc. Submit your gcc C, C++, or Fortran to http://www.venraytechnology.com./ Statistics are returned in standard dGen format.
- TSV (through silicon vias) and HMC (hybrid memory cube) are valid attempts to push back the Memory Wall. Discussed in Part 1 for EDN. http://www.edn.com/article/520059-The_future_of_computers_Part_1_Multicore_and_the_Memory_Wall.php Decision may be determined by cost.
- Would love to dispense with caches because they add transistors. 4K data and 4K instruction caches sped us up about 10x. Unlike legacy architectures, TOMI cache lines load in a single DRAM cycle.
- Yes love Raspberry Pi. http://www.raspberrypi.org/
- Quad-