Custom Processor Core Vs Hardware IP
This article talks about the pros and cons of using a custom processor core instead of a hardware IP (Please do not confuse with Hard-IP).
VLSI Designers know well about a Hardware IP. They view it as a hardware block that can do a specific job. A designer working on a SoC Chip view it as a black box and only concern about the interface to the block. An IP designer focus on building architecture for the box writes HDL code to implement the box and will provide a generic bus interface it. The gates in the realized IP that was designed to do a specific job will do only that job. They were Hardwired!!! Example, A Video Decoder IP designed for a standard can decode only that standard. Tomorrow a new standard emerge, the IP has to be modified or even completely re designed which involves the design cost and long time to market.
So, will custom processor core solve this problem ? Answer is Yes!!! Of course with some limitations as described later in this article.
How it will solve the issue. Answer is obvious, after all it's a processor core so it's programmable you write the new software code for new standard and port it onto the core, it works for new standard. Then why we, the IP designers are coding in verilog from so many years why don't we take a processor from
TI/CEVA/ARM/MIPS and port software on it, then we are not hardware engineers anymore but software guys!!! Following data shows why this methodology fails.
http://www.bdti.com/bdtimark/vedb.htm
From the data given by BDTI (Berkeley Design Technology, Inc- widely recognized for benchmarks ), for ARM Cortex-A8 to decode HD (1920X1080) @30 fps it has to run at 3.078 GHz.Where as a Hardware IP for video decoder is able to decode HD @30 fps at much low frequency.
http://www.chipsnmedia.com/product/bodahx_series.htm
Why a processor is unable to do what an hardware IP is doing. The processor has limited hardware it has to use the same hardware again and again to perform a task. Its like an FSM controlling a small hardware unit which is nothing but ALU.
Then how a Custom Processor could be able to perform like a Hardware IP ? If we overcome the limitation that a processor has only one (Usual case with RISC) computing unit (ALU). We add more hardware units into the processor's pipeline and more instructions (so called custom instructions) to control those computing units [Note:1]. By keeping these added computing units as generic as possible programmability of the core will be preserved. Even DSP processors can be think of RISC processors customized to DSP applications by adding DSP specific computing units like MAC (Multiply And Accumulate : Typical hardware unit used to implement an FIR Filter),ABS(Absolute Value Computation) Unit, SAT(Saturation Unit). Following figures shows the datapaths of two processor's pipelines. The processor in the first figure is a Generic RISC Processor with ALU as the only computational unit. The processor in the second figure is Custom Processor with N-computational units.
Figure-1: Click on the image to see full image
Figure-2: Click on the image to see full image
So, for a new standard emerged needs in software updation. Avoiding re design of the Hardware IP. So, it's one time effort to design the processor core. Another advantage is verification of the designed Hardware IP involves much effort and bugs in Software can be fixed easily compared to the bugs in Hardware. Disadvantage of the Custom Processor Core is though the added computing units to the core may improve the performance considerably, it may not be comparable with Hardware IP. Because, "Hardware Is Hardware"
Notes :
1. Adding computing/functional units to the processor core's pipeline is Fine-grained methodology to improve the performance for an application. Coarse-grained methodology to accelerate the application is adding (Interfacing through a Co-Processor Bus as Co-Processor will be outside the core) a Co-Processor to the processor core.
VLSI Designers know well about a Hardware IP. They view it as a hardware block that can do a specific job. A designer working on a SoC Chip view it as a black box and only concern about the interface to the block. An IP designer focus on building architecture for the box writes HDL code to implement the box and will provide a generic bus interface it. The gates in the realized IP that was designed to do a specific job will do only that job. They were Hardwired!!! Example, A Video Decoder IP designed for a standard can decode only that standard. Tomorrow a new standard emerge, the IP has to be modified or even completely re designed which involves the design cost and long time to market.
So, will custom processor core solve this problem ? Answer is Yes!!! Of course with some limitations as described later in this article.
How it will solve the issue. Answer is obvious, after all it's a processor core so it's programmable you write the new software code for new standard and port it onto the core, it works for new standard. Then why we, the IP designers are coding in verilog from so many years why don't we take a processor from
TI/CEVA/ARM/MIPS and port software on it, then we are not hardware engineers anymore but software guys!!! Following data shows why this methodology fails.
http://www.bdti.com/bdtimark/vedb.htm
From the data given by BDTI (Berkeley Design Technology, Inc- widely recognized for benchmarks ), for ARM Cortex-A8 to decode HD (1920X1080) @30 fps it has to run at 3.078 GHz.Where as a Hardware IP for video decoder is able to decode HD @30 fps at much low frequency.
http://www.chipsnmedia.com/product/bodahx_series.htm
Why a processor is unable to do what an hardware IP is doing. The processor has limited hardware it has to use the same hardware again and again to perform a task. Its like an FSM controlling a small hardware unit which is nothing but ALU.
Then how a Custom Processor could be able to perform like a Hardware IP ? If we overcome the limitation that a processor has only one (Usual case with RISC) computing unit (ALU). We add more hardware units into the processor's pipeline and more instructions (so called custom instructions) to control those computing units [Note:1]. By keeping these added computing units as generic as possible programmability of the core will be preserved. Even DSP processors can be think of RISC processors customized to DSP applications by adding DSP specific computing units like MAC (Multiply And Accumulate : Typical hardware unit used to implement an FIR Filter),ABS(Absolute Value Computation) Unit, SAT(Saturation Unit). Following figures shows the datapaths of two processor's pipelines. The processor in the first figure is a Generic RISC Processor with ALU as the only computational unit. The processor in the second figure is Custom Processor with N-computational units.
Figure-1: Click on the image to see full image
Figure-2: Click on the image to see full image
So, for a new standard emerged needs in software updation. Avoiding re design of the Hardware IP. So, it's one time effort to design the processor core. Another advantage is verification of the designed Hardware IP involves much effort and bugs in Software can be fixed easily compared to the bugs in Hardware. Disadvantage of the Custom Processor Core is though the added computing units to the core may improve the performance considerably, it may not be comparable with Hardware IP. Because, "Hardware Is Hardware"Notes :
1. Adding computing/functional units to the processor core's pipeline is Fine-grained methodology to improve the performance for an application. Coarse-grained methodology to accelerate the application is adding (Interfacing through a Co-Processor Bus as Co-Processor will be outside the core) a Co-Processor to the processor core.
Comments
Post a Comment