Hi,all We know there are one ARM core and C64x core in DaVinci from TI. The ARM core is for OS and C64x is for DSP. Is it possible to merge two cores into one? This idea is crazy? It makes me think of XScale core which is a ARM core with wireMMX coprocessor. Blackfin from ADI can run ucLinux and do DSP at the same time. Thanks in advance. Jogging
Why not the two cores in DaVinci are merged into one core?
Started by ●December 10, 2007
Reply by ●December 10, 20072007-12-10
joggingsong@gmail.com wrote:> Hi,all > We know there are one ARM core and C64x core in DaVinci from TI. > The ARM core is for OS and C64x is for DSP. Is it possible to merge > two cores into one? This idea is crazy? It makes me think of XScale > core which is a ARM core with wireMMX coprocessor. Blackfin from ADI > can run ucLinux and do DSP at the same time. > > Thanks in advance. > JoggingPeople have been trying for many years to achieve a core which does both DSP and more general purpose MCU work well. The Blackfin is probably the most successful attempt to do this. The XScale is a disaster. Even the Blackfin has problems, though. Anything big will be running mostly from the outside, and this is rather slow. This would typically be the MCU type code. It can quickly chew up lots of processing time, restricting the DSP that is possible. The DaVinci approach is much messier from the developers pint of view, but it does keep the work in the places where it can be done well. The ARM may look pretty slow compared to the DSP core, but its usually fast enough for the MCU type code, and avoids cache thrashing and other performance drains on the DSP core. The Blackfin is nice, but it is no magic cure. Steve
Reply by ●December 10, 20072007-12-10
joggingsong@gmail.com schrieb:> Hi,all > We know there are one ARM core and C64x core in DaVinci from TI. > The ARM core is for OS and C64x is for DSP. Is it possible to merge > two cores into one?Everything that the ARM can do on the instruction level is alredy present in the C64+ DSP. Ok - the MMU stuff and maybe some other less important things are missing, but all the ALU, logic and branching, can be done on the DSP as well. The reason I think TI put a helper CPU along the DSP is, that the C64+ DSP rocks at crunching numbers in tight loops, but does not perform that well for control code (lots of if-else, branches, switch stuff). The ARM otoh is good at this control code job. Imho it's a good team, The ARM is doing the control job, doing managment stuff, running the applications, waiting lazy in semaphores while the DSP does not has to care about that stuff and do the dirty work. There are other good reasons as well: Embedded programmers are used to the ARM (mainstream!) and can start using the CPU side of the DaVinci right away. If they want MPEG playback or other stuff that preforms better on the DSP they can go out and buy a DSP-codec. No need to learn the details and how to write efficient code for the C64+. Trust me - linking these DSP codecs alone is not a job for the faint heart. > Blackfin from ADI can run ucLinux and do DSP at the same time. So could you if you would port linux on the C64+. There is nothing that would prevent the DSP from booting a OS. It's just a waste of DSP cycles to do so. Nils
Reply by ●December 10, 20072007-12-10
Steve Underwood wrote:> People have been trying for many years to achieve a core which does both > DSP and more general purpose MCU work well. The Blackfin is probably the > most successful attempt to do this.P4 is probably the most successfull attempt to do this; BlackFin is probably the most successfull attempt to do this for cheap. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●December 10, 20072007-12-10
On Mon, 10 Dec 2007 17:47:43 +0800, Steve Underwood <steveu@dis.org> wrote:>joggingsong@gmail.com wrote: >> Hi,all >> We know there are one ARM core and C64x core in DaVinci from TI. >> The ARM core is for OS and C64x is for DSP. Is it possible to merge >> two cores into one? This idea is crazy? It makes me think of XScale >> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI >> can run ucLinux and do DSP at the same time. >> >> Thanks in advance. >> Jogging > >People have been trying for many years to achieve a core which does both >DSP and more general purpose MCU work well. The Blackfin is probably the >most successful attempt to do this. The XScale is a disaster.It's funny that you say that. Intel's approach was to put a Blackfin and an XScale on the same die, so that the Blackfin did the DSP for the phone (that had to be qualified), and the XScale could run applications. It wasn't a successful product. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●December 10, 20072007-12-10
On Dec 10, 5:47 pm, Steve Underwood <ste...@dis.org> wrote:> joggings...@gmail.com wrote: > > Hi,all > > We know there are one ARM core and C64x core in DaVinci from TI. > > The ARM core is for OS and C64x is for DSP. Is it possible to merge > > two cores into one? This idea is crazy? It makes me think of XScale > > core which is a ARM core with wireMMX coprocessor. Blackfin from ADI > > can run ucLinux and do DSP at the same time. > > > Thanks in advance. > > Jogging > > People have been trying for many years to achieve a core which does both > DSP and more general purpose MCU work well. The Blackfin is probably the > most successful attempt to do this. The XScale is a disaster. Even the > Blackfin has problems, though. Anything big will be running mostly from > the outside, and this is rather slow. This would typically be the MCU > type code. It can quickly chew up lots of processing time, restrictingMCU type code? Can you give a clear definition? If the size of application code is larger than the size of cache and SRAM, it is necessary to put some of the code on SDRAM whatever it is a MCU or DSP. Jogging> the DSP that is possible. The DaVinci approach is much messier from the > developers pint of view, but it does keep the work in the places where > it can be done well. The ARM may look pretty slow compared to the DSP > core, but its usually fast enough for the MCU type code, and avoids > cache thrashing and other performance drains on the DSP core. > > The Blackfin is nice, but it is no magic cure. > > Steve
Reply by ●December 10, 20072007-12-10
On Dec 11, 1:57 am, Eric Jacobsen <eric.jacob...@ieee.org> wrote:> On Mon, 10 Dec 2007 17:47:43 +0800, Steve Underwood <ste...@dis.org> > wrote: > > >joggings...@gmail.com wrote: > >> Hi,all > >> We know there are one ARM core and C64x core in DaVinci from TI. > >> The ARM core is for OS and C64x is for DSP. Is it possible to merge > >> two cores into one? This idea is crazy? It makes me think of XScale > >> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI > >> can run ucLinux and do DSP at the same time. > > >> Thanks in advance. > >> Jogging > > >People have been trying for many years to achieve a core which does both > >DSP and more general purpose MCU work well. The Blackfin is probably the > >most successful attempt to do this. The XScale is a disaster. > > It's funny that you say that. Intel's approach was to put a Blackfin > and an XScale on the same die, so that the Blackfin did the DSP for > the phone (that had to be qualified), and the XScale could run > applications. > > It wasn't a successful product. > > Eric Jacobsen > Minister of Algorithms > Abineau Communicationshttp://www.ericjacobsen.orgSomeone says that blackfin is a successful product, and other says it is not. I think people draw different conclusions based on their experiences. For different applications, blackfin is not the best choice. I think we shoud give some reason why blaickfin is successful or not. jogging
Reply by ●December 10, 20072007-12-10
joggingsong@gmail.com wrote: ...> I think we shoud give some reason why blaickfin is successful or not.Why? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●December 11, 20072007-12-11
On Dec 10, 1:25 am, joggings...@gmail.com wrote:> Hi,all > We know there are one ARM core and C64x core in DaVinci from TI. > The ARM core is for OS and C64x is for DSP. Is it possible to merge > two cores into one?Why? From video games to supercomputers, the trend looks more like going to more cores, not less. And the more specialized a core's function, the less compromises that likely have to be made in its implementation.
Reply by ●December 11, 20072007-12-11
On Dec 10, 9:25 am, joggings...@gmail.com wrote:> Hi,all > We know there are one ARM core and C64x core in DaVinci from TI. > The ARM core is for OS and C64x is for DSP. Is it possible to merge > two cores into one? This idea is crazy? It makes me think of XScale > core which is a ARM core with wireMMX coprocessor. Blackfin from ADI > can run ucLinux and do DSP at the same time. > > Thanks in advance. > JoggingThere are several reasons that two different cores may be an advantage: 1) there is a clear separation of OS and infrastructure from DSP. That is, a Linux programmer can work on the ARM (or other general purpose CPU) without knowing anything about the special SP core. And the DSP programmer can work on the DSP without knowing anything about the general purpose CPU. This sort of separation can be valuable when you are developing with large software teams, or allocating aspects of design work to different groups or vendors. 2) For a 'DSP' manufacturer it can be hard to continue to support a general purpose OS on their core long term. Whereas ARM, for instance, are totally focussed on this OS/infrastructure side of things and so can develop their core optimised for that purpose. 3) It takes a lot of work to design a core, and it has proven very hard to in fact design cores that suit both OS/infrastrcuture and DSP. One solution is to combine two cores, each optimised for their own domain of application. For instance TI can benefot from allof ARM's expertise and experience in the general purpose domain, and add to that their own unique experience and expertise in DSP. Focus like this can prove more valuable in practice than diversifying - 'jack of all trades, master of none' is the saying. 4) the inter-processor boundary can possibly also be a legal one. A DSP vendor puts an enormous amount of investment into highly optimised codecs and so on. There is a fear (justified or not, but real) that these may become polluted by open licences if combined with Linux. Having these specialised applications run on a second core can be argued to separate them clearly from the open source software and so protect them from becoming open source. 5) Having two cores can separate the customer (Linux programmer, customer) from the vendor in terms of expertise. If you have one core then the customer must learn how to use it, which means their expertise now overlaps that of the third party DSP software vendor. The argument can be made: 'since I know how to program the DSP, why do I not write my own DSP codecs?'.If the two wocres are different then the customer's skills do not overlap those of the DSP third party - so the customer does not compete so easily with third party products. This can help encourage a market in thrid party software, which is undermined when customers have the option of in-house development. 6) A DSP core typically runs loaded at very high levels - 80% or 90% of peak on avarega is not unusual. General purpose CPUs tend to run with much lower loadings, to allow them more overhead for peak performance. The issues in sharing resources in a lump-demand OS with a continuously-high demand DSP are not that easy to solve, so it can be easier to separate them. 7) Experience suggests that, with several generations of 'do- everything' DSP-and-OS cores from various vendors, in practice they are not optimal at either task, and the OS software gets out of date. 8) Increasing number of transistors in single core devices becomes increasoingly difficult. So multi-core designs may become more popular in future, and if you have multi-core then why not tune each core to its specific domain of application? Chris ================================= Chris Bore BORES Signal Processing www.bores.com