comment on this article

Two cores into an SOC?

Processors receive a fundamental rethink. By Philip Ling.

The trend towards adding extensions to existing processor cores to handle signal processing has been challenged by Siroyan, the silicon IP company based in Reading. It believed the whole approach towards digital signal processing was due for an overhaul and went about designing what it believes is something that will solve the problem of coupling a traditional risc processor to a dsp whilst boosting overall performance.

It is an open secret that, in the majority of mobile handsets, there are two processors: a dsp, often supplied by either Texas Instruments or Motorola; and a 'conventional' processor, normally in the form of an ARM core. As higher levels of integration have emerged, these two discrete devices have been merged in a single system on chip design. But Siroyan (http://www.siroyan.com) believes there is an easier way, which could reduce cost and design effort and improve throughput.

The benefit of integrating two cores on a single chip is primarily the speed with which the two processors can talk to each other – removing the bottleneck of a 16/32bit wide memory interface with a direct connection. However, as Adrian Wise, chief technical officer for Siroyan pointed out, there is still the overhead of an infrastructure, such as shared program memory, when using two cores from different vendors, as well as software partitioning that comes with using more than one processor.

The emergence of instruction set extensions is a fairly recent phenomenon, adopted by soft core specialists such as ARM, ARC and MIPS. As such, it presents a relatively painless way of extending an architecture whilst maintaining software compatibility. And software compatibility is important; it relies on using the same underlying architecture in much the same way that Pentiums today still support code written for a 386.

If a totally new hardware approach is to be used, it almost certainly means new software too. If not, it means creating an interpreter to offer compatibility. In the example of the x86 compatibility, for instance, Transmeta has had recent success with its hardware/software approach using a process it calls code morphing.

In the dsp world, however, performance is the goal. And if code compatibility must be sacrificed for higher throughput, chances are it will be. Better still, if the solution arrives at the right time for new applications – where legacy code isn't a consideration – the chances of its success must be increased.

Click here to request this article by email

Author
Graham Pitcher

Comment on this article


This material is protected by MA Business copyright See Terms and Conditions. One-off usage is permitted but bulk copying is not. For multiple copies contact the sales team.

What you think about this article:


Add your comments

Name
 
Email
 
Comments
 

Your comments/feedback may be edited prior to publishing. Not all entries will be published.
Please view our Terms and Conditions before leaving a comment.

Related Articles