Honored ContributorOk 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 :)
Honored Contributor'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, DaveHonored ContributorIf 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 cyclesHonored Contributor10x 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 :)Honored ContributorHonored Contributorok 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?Honored ContributorHow 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, DaveHonored Contributoryeah 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 ...
Honored Contributor
