FPGAs and CPUs ??

[Altera_Forum]

Ok i know that an FPGA is way faster in comparison to a cpu or a microprocessor but I'd like to know why? and giving the fact that FPGAs are faster than CPUs what are the advantages and disadvantages of each one? 

 ps: if anyone got a link about the topic i'll be very thankful ... 10x all :)

[Altera_Forum]

'Faster' is a relative term. It depends what you are trying to do. 

 If you have an application that requires lots of conditional logic (if-then-else) and general purpose computing with double-precision floating-point numbers, then its likely you can get your algorithms 'working' faster (i.e., elapsed time) using CPUs. Consider that the 'supercomputers' generally discussed are CPU or GPU based, and you can program using optimized libraries of code.  If you have a highly parallel system where lots of the same operations are required, and those operations are 'simple' eg., a multiply-accumulate (MAC), then using DSPs or CPUs or GPUs to implement a system can be less efficient than an FPGA. An FPGA allows you to implement only the logic needed for the application.   If a CPU or DSP can meet your requirements, and you know how to program it, then it is 'faster' to use that technology.  If the performance characteristics required by a system design are; implement the algorithm, take no more than XX Watts of power, and fit into YY space. Then you need to meet all the requirements, so what is 'faster' in this context.  Take for example the power trade-off. Comparing generic power parameters does not help, eg. which is better, a CPU with a maximum power dissipation of 10W or an FPGA with a maximum power dissipation of 20W? If your algorithm can be described as requiring 10 multiply-accumulates per 1GHz clock, then you need 10 GMAC/s of processing power. If the CPU runs at 1GHz and can perform 4 MACs per clock cycle, then its can process 4 GMAC/s, so you need 2.5 CPUs, i.e., 30Ws of CPUs. If your FPGA can process 4000 MACs at 500MHz, then it can process 2000 GMAC/s. The extra processing power of the FPGA can then be traded-off by running the FPGA at a lower clock-rate, or using a smaller device, or processing more data.  Signal processing systems are generally built using a combination of CPUs, DSP, and FPGAs. Using each type of logic where they perform 'optimally'.  Don't buy into marketing PR where a softcore CPU on an FPGA is the solution to all of your problems. It is the solution to some problems, but not necessarily the one you are currently faced with :)  Cheers, Dave

[Altera_Forum]

If you mean by why? in the sense of low level difference then obviously a processor runs fetch-execute cycles per instruction. FPGA or ASIC is direct logic implementation that does not have any such cycles.  

 If a processor system can run parallel channels to offset the cycle overheads then it approaches an FPGA.  remember also that fpga can be used to design dedicated processors to implement the instructions set directly hardwired without much cycles

[Altera_Forum]

10x guys this this very interesting ... i still have so much to learn i know that but this is for a small research I'm doing in one of my classes and i must say it's a very interesting subject but sadly i don't know where to find the needed information 

so in general everyone has it's pros and cons can you give me a quick recap or comparison between the two ? 10x a lot I really appreciate your help :)

[Altera_Forum]

--- Quote Start ---   this is for a small research I'm doing in one of my classes   --- Quote End ---  What is the question you have been asked? If the question is to compare external processors to soft-core processors in FPGAs, then that is a very specific question which can be more easily answered. If the question is to compare CPUs to FPGAs, then its a very open-ended question.    --- Quote Start ---   i don't know where to find the needed information   --- Quote End ---  The 'needed information' is very application specific, so you will not find one source of information.    --- Quote Start ---    can you give me a quick recap or comparison between the two ?   --- Quote End ---  There is no 'quick recap'. For example, what sort of CPU are you being asked to compare? An ARM core, an ARM microcontroller, an ARM processor, an x86 processor, an AVR microcontroller, a GPU, etc?  Try to narrow the question, and you'll be able to answer it easier.  Cheers, Dave

[Altera_Forum]

ok here's the thing as a project i had to make pwm which consisted of 4 inputs to select the time base 4 inputs to select the duty cycle a clk input and one output connected to a led . i made a model using hardware implementation via QuartusII and VHDL and a model using software implementation in the Cyclone II processor on the FPGA board using SOPC Builder , Nios II and C code. 

After performing the timing analysis for the SOPC model and the Hardware model the results were very in favor of the hardware model ... So i'm trying to understand why ? and if an FPGA was better than a cpu in this specific case in what case it could be the other way around?

[Altera_Forum]

How was your software model implemented? I assume you were toggling I/O pins. 

 When you toggle I/O pins from a CPU, you are subject to whatever else is going on on the processor, eg. RTOS interrupts, or on the bus, eg. DMA going on in parallel with your attempts to access the I/O registers. There is no way you can guarantee consistent timing when toggling an I/O.  An alternative implementation would be to create a PWM controller peripheral. This is how most microcontrollers work. In your case, you would implement the PWM controller to have just the features you wanted. Your software would program control registers and then enable the PWM controller. From that point on, the PWM waveform timing would be exactly as you coded the hardware.  Note that a TimeQuest timing analysis is only as good as the SDC constraints you provide, and it only tells you about timing relative to clocks, not relative to your software. I doubt you could infer anything useful between the timequest timing of an I/O pin relative to a PWM controller output pin. Both pins can be made to meet timing constraints (clock-to-output), but that will tell you nothing about the jitter (in units of whole clocks) in your software-generated PWM output.  Cheers, Dave

[Altera_Forum]

yeah i assume if we took the SOPC timing with consideration of the actual programs executing the software implemented pwm, the results will be even slower since the instructions won't be executed in parallel like the case of the programmed logic ...

[Altera_Forum]

--- Quote Start ---  yeah i assume if we took the SOPC timing with consideration of the actual programs executing the software implemented pwm, the results will be even slower since the instructions won't be executed in parallel like the case of the programmed logic ...  --- Quote End ---    Right. The key is to understand is what you are analyzing. If you really wanted to analyze the timing of the PWM signals, you could run a Modelsim simulation and observe the PWM waveforms (generated by your toggling I/O software, or by a hardware PWM controller).  If your PWM waveforms were pulses to a stepper motor, and that motor expects slow pulses (Hz to kHz) and does not care about sloppy timing, then a software solution would work just fine.  If however, your PWM waveforms were to a digitally controlled power supply, where the PWM duty cycle affects the output voltage and current, then you would not want that control loop implemented in software alone.  Once you understand your system design requirements, and you understand the strengths and weakness of your CPU and/or FPGA, you can partition the design to the strengths of each. (FPGAs of course have no weaknesses ...)  Cheers, Dave