Multicore Philosophy: Convenient Concurrency versus Embarrassingly Parallel

handicapped sharable minority oppi blogs neighbors response chaithanya costa oscilloscope discoveries

Hi Steve, Excellent article! I think you''ve hit the nail on the head about such architectures (hereogeneous multicore) being the obvious wave of the future in embedded SoC design. As you and Tracy mention, the compositional and pipeline parallelism is obvious to hardware designers, but what is less obvious to hardware folks is that you can get very impressive efficiencies in a programmable solution (performance/$/microwatt). It is true that engineers from the SW and HW realms are increasingly driving toward this common SoC architectural view, but for different reasons. The SW folks are moving this way for the power, efficiency, and simplicity reasons that you state so eloquently. The HW folks are moving in this direction as they realize the benefits of a programmable approach to their design cycle (faster to market, less risk), and the fact that, for many (not all) blocks, a finely tuned ASIP can meet their performance, gate count, and power requirements. Keep it comin''!

Tracy Hall, I don't take your comment as snarky. It simply means I didn't explain myself well enough. In the PVR and 3G phone block diagrams, I wrote that each gray box represents the opportunity for a processor. It's also an opportunity to use a non-programmable hardware block if that makes more sense. However, in my experience, designers steeped in a "computer-science" frame of mind rarely think of using a processor simply as a replacement for a complex state machine. Yet processors indeed make very good state-machine implementations with firmware upgradeability. And you're right that I'm defining my way out of a problem that's been imporperly characterized as difficult to parallelize. People with hardware-design backgrounds immediately see the problem as concurrent. People with a CS background immediately think mutitasking or multithreading. There lies madness.

Tom, Cisco's implementation of the Xtensa core supports multithreading. Cisco has an architectural license. There are 192 cores on the SPP chip, four of which are spares and are used to improve manufacturing yields. The software assumes there are 188 operating processor cores on the chip.

Two questions, Steve: 1. Which Xtensa processor core supports multithreading? 2. Does the SPP chip in the Cisco CRS-1 router have 188 or 192 Xtensa cores? If you Google "cisco crs-1 router xtensa site:tensilica.com" you will get two different answers from Tensilica's website.

Forgive what may apprear to be a snarky commnet, but the "problem" (3G) shown is only a problem if you start with a processor bias - i.e. *assume* a processor to do the work. From a hardware geek's perspective, the modular approach is "intuitively obvious"; an insight that leads closer to your model is to use processor cores for these modules to allow for design/application flexibility. Hardware/Hardwired solutions are inherently "parallel" in that sense; it feels to me like you are simply defining your way out of the "parallel" problem - of course a homogeneous array of cores may be best suited to "trivial" (no denigration intended) problems - but a heterogeneous array is simply solving the problem as given, rather than fitting the problem to a given solution of parallel cores...

Dave, sorry I misunderstood. I believe the shared on-chip memory provides the sort of global biew you're referring to. It directly ties into the QoS function that's part of this router. The ASR 1000 series is designed to be an edge router, so you're right, it does need to know about packet streams and not just about each packet.

Steve, I was alluding to the fact that for some kinds of packet processing, the packets are related to each other. For example, under TCP the packets can arrive out of order, and if you want to do anything intelligent with their contents, such as screen for viruses, you need to potentially buffer and reorder them. Therefore, one packet one processor is fine, but the next packet that is *of the same flow* of the first one needs to be routed to the same processor as well, or at least a processor that can access the shared state. This itself requires access to all the potential processors, or at least some shared state that maps flows to processors. This is principally a problem for networking equipment on the edge or near-edge of the network, that need to terminate the protocol. Not relevant for the CRS-1, but I don't know anything about the QuantumFlow or its purpose, hence the question.

Dave, from an IP packet's perspective inside of a Cisco QuantumFlow Processor, there's no evident parallelism. The packet lives in the realm of one processor from the start of processing to the completion. In this sort of problem, one packet --> one processor (or more accurately, one packet --> one processor thread) makes perfect sense because there are so many packets to deal with.

Let's not let the supercomputer people get us down. They have to achieve massive parallelism, or else there's not much sense to running their code on thousand-of-processor machines. Also, I have a feeling that most scientific codes are quite a bit different than the lot running on, say, a multimedia chip. Inverting lots of fantastically large matrices and other "mesh" stuff is harder on the processor(s) than it is on the programmer(s). There is also typically no real-time component to manage whatsoever. On another topic, can the new Cisco parts manage "flow" based protocols like TCP? The inter-packet state associated with managing such protocols seems to be a major fly in the ointment of such parallel architectures. Not insurmountable, but a headache, making the parallelism a bit less convenient.

Thanks for the great comments, Louis. One thing to note: Cisco's SPP and QuantumFlow Processor use MIMD processor arrays.

Nice article. I also like the informal, easy to read style. And congratulations to Tensilica for its technology being used in Cisco''s awesome new dataflow multicore processor. Convenient concurrency may be pervasive but if you want to implement a web server with millions of clients, you''re out of luck if all you''ve got is a bunch of SIMD cores to play with. You gotta use MIMD cores for some situations. But the problem with pratically all MIMD multicore CPUs though, is that they use coarse-grain, thread-based parallelism. I understand the rationale behind the latest trend toward heterogeneous multicore processors but wouldn''t it be nice if we had a multicore chip that used a universal computing model that combined the qualities of both MIMD and SIMD without the faults? How come nobody in the industry is pursuing the road to universality? Those hybrid monsters are going to be a pain in the ass to write code for, you know. BTW, did you know that it cost Cisco $250 million, 100 engineers and five years to develop their new router? Wow! Not that it matters much. At $35,000 a pop, I''m sure they''ll recoup their investment in no time. :-) Louis Savain