Why we need SOC (Procesor + FPGA), if we can do our all work with FPGA???

[Arjun]

Hello everyone, from long time i was thinking and searching about why we need processor and fpga on a single chip, why we need HW/SW co design, but i am not getting any satisfactory answers.

I utilize both ZYNQ and Artix 7 fpga separately, by using Basys3 and ZYBO board. and i found if we combine both the chips on single package then we can to do HW/SW co-design.

we can use only fpga, we dont need to create sw for that, we can use processor in this case we dont need to create HW for that, ultimately i just want to know what are the majors applications which we can do only by using SOC, in terms of Power, speed and area.

i accept one thing when we we want to use Ethernet then we need to create Ethernet controller inside the fpga, if we are not working with SOC, but it is also true if we are utilizing Ethernet controller of zynq ps, then we need to write  sw application which also very complex. if someone is good in verilog or vhdl, then he/she can prefer FPGA, instead of writing sw application for Ethernet controller.

also i want to discuss one case, in one of my project i utilize BRAM for giving data to custom IP, now in this design i used zynq ps, three bram , matrix multiplication IP (IP creating by using HLS tool)

again we need to write SW application, firstly the DDR will store our data which we want to store inside the BRAM, then through ethernet data will send to BRAM, then custom IP perform whatever operation we want.  so my question is what is benefit  of BRAM , firstly data is already stored inside the DDR then BRAM will store the data,???? i am confused with this things, i utilize this things, , but getting more  understanding, i need your support.

 

please give me valid reason why we use SOC ZYNQ, instead of FPGA (Artix7)

 

thanks and regared

Arjun

[xc6lx45]

Hi,

learning a new language well is a major investment => constant cost. Picking an inadequate language / technology / platform is a cost multiplier.

Which one hurts more? For a small project the learning effort dominates so you tend to stick with the tools you've got. Try this in a large project and the words "uphill battle" or "deathmarch" will come to life...

There's a human component to this question: Say, my local expert has decades of experience with FORTH coding on relay logic - you bet what his recommendation will be, backed by some very quick prototyping within a day or two.

And if you have ...

>> someone good in verilog or vhdl,

... who is opposed to learning C, you have interesting days ahead...

Ultimately, implementing non-critical, sequential functionality in FPGA fabric is a dead end for several reasons. Start with cost - a  LUT is much, much more expensive than its functional equivalent in RAM on a processor. Build time is another. The "dead end" may well stretch all the way to success but don't lose sight of it. You will see it clearly when it's right in front of your nose.

Now this is highly subjective, but my first guess (knowing nothing about the job, assuming it's not small and not geared towards either side by e.g. performance requirements), I'd predict that implementation on Zynq would take me 3..10x less effort than using HDL only. This may be even worse when requirements change mid-project (again, this is highly subjective but you have considerably more freedom in C to keep things "simple and stupid", use floats where it's not critical,  direct access to debug UART, ...).

On the other hand, Zynq is a very complex platform and someone needs to act as architect - it may well be that the "someone good in verilog" will get it right first time in a HDL-only design but need architectural iterations on Zynq because the first design round was mainly for learning. Take your pick.

Most likely, Zynq is the best choice if you plan medium-/long term, and the (low-volume!) pricing seems quite attractive compared to Artix.

 

[xc6lx45]

... some numbers. Yes, apples are not oranges , this is about orders-of-magnitude, not at all a scientific analysis and maybe slightly biased.

Take the Zynq 7010. It has 17600 LUTs. Let's count each as 64 bits => 1.1 MBit for the logic functions of my application (if you like, add 2.1 MBit BRAM => 3.2 MBit).

Now the ARM processor: While it's probably only a small add-on in terms of silicon area / cost (compare with the equivalent Artix - it's even cheaper - weird world...) it includes
256 kB on-chip memory
512 kB on-chip L2 cache
which is 6.1 MBit

So we've got already several times the amount of "on-chip floorspace" for the application logic and it'll probably run faster than FPGA logic as it's ASIC technology not reprogrammable logic, typically clocks at 666 MHz (-1) where a non-tuned-/pipelined design on the PL side will probably end up between 100 and 200 MHz.

Needless to say, offloading application logic to DRAM or FLASH is trivial where a RTL-only implementation hits the end of the road, somewhat stretchable by buying a bigger chip, maybe partial reconfiguration or biting the bullet and adding a softcore CPU which will be so pathetically slow that the ARM will hop circles around it on one leg. Right, I forgot, the above-mentioned 7010 actually has two of them

[zygot]

22 hours ago, Arjun said:

Hello everyone, from long time i was thinking and searching about why we need processor and fpga on a single chip, why we need HW/SW co design, but i am not getting any satisfactory answers.

There is no satisfactory answer because there is no we, and there is no one type of problem to solve. As @xc6lx45has pointed out, in a way, field programmable devices can't compete with non-programmable device in certain areas. Processors, even multi-core ones, have there own limitations and certainly don't come with an infinite variety of external interfaces supporting every possible application. So,  typically a product solution is a combination of processor and programmable logic for connecting that processor to the real world. Sometimes programmable logic isn't needed al all. Sometimes a processor isn't needed. Most often a combination is the best choice; and in that case one device with a hard logic processor, like the ARM, make good sense. Occasionally, the case for implementing a soft-processor in logic is compelling, if done correctly, and you can choose your own software development tools.

Developing and maintaining software has always been difficult for product manufacturers. Developing and maintaining programmable logic designs are even more difficult as products mature. As you have not doubt observed, the HW/SW co design flow is more complicated than than an all HDL flow. A lot of the reason for this has to do with the vendors releasing tool versions that are not backward compatible with previous tool versions. Some of this is unavoidable, some is not. We all out up with nonsense from vendors that seem to them to be good business. Is there really a good reason why I need to run WinXP in a VM on WIN10 to run an older program? Only because customers who are happy with what they have aren't spending money on new stuff and our society's use of capital requires ever increasing customer spending to sustain itself.

As someone trying to hone my FPGA development chops I find that an all HDL flow works best most of the time. But then I'm not so concerned with cost, development hours, power dissipation, thermal budgets, and long term customer support. Sometimes a ZYNQ make the most sense in order to accomplish a task and then I have to put up with the extra headaches involved. If I were making a product then I'd design a platform that makes the most sense from a large variety of considerations.

Unfortunately, there are times when vendors foist the FPGA with hard processor platform upon us for reasons that aren't in our best interests. Will programmable logic only devices disappear altogether some day? Perhaps. Might this ever be a good thing? I don't know.

[xc6lx45]

48 minutes ago, zygot said:

Unfortunately, there are times when vendors foist the FPGA with hard processor platform upon us for reasons that aren't in our best interests. Will programmable logic only devices disappear altogether some day? Perhaps. Might this ever be a good thing? I don't know.

This is really something to consider in the long term. X and A have a strong interest to make us use their respective processor offerings. Nothing ever is for free and we may pay the price later when e.g. some third-party vendor (think China) shows up with more competitive FPGA silicon but I'd need a year for migrating my CPU-centric design.

For industrial project reality, accepting vendor lock-in may be the smaller evil but if you have the freedom to look ahead strategically (personal competence development is maybe the most obvious reason for doing so, maybe also government funding) there may be wiser options.

This is at least what keeps me interested in soft-core CPUs even though its absolute KPIs are abysmally bad.