The Hype of SoC's

[Altera_Forum]

Hi, I started this post because I wanted to hear what people thought concerning the hype over FPGAs with embedded ARM processors. I have been following the news of these devices over the past years and have been very anxious to start implementing one in my hardware designs. I've been checking the Altera web site every day for news on the new Stratix 10 with its four ARM cores each running at 1Ghz. I see lots of possibilities of these new devices. My co-worker is using the Cyclone 5 with its two ARM cores and I'm always asking him how are things going? He has had the Altera training on the ARM development so he very familiar with the environment. His biggest complaints are the lack of documentation and the complexity of the tools.  

 My enthusiasm has waned after my conversations with him. With every new release of Quartus I'm hoping that the tools are getting easier to use with these new ARM devices. I think to myself that these tools must get easier to use when the Stratix 10 is released because I'm guessing they won't be cheap and program managers won't want to spend a bundle on these devices and then spend 8 months of FPGA/ARM development. So, the tools must get easier. With all this being said I'm very reluctant to jump on the bandwagon of FPGA's with embedded processors.   To me it is like climbing Mt. Everest in terms of complexity and cost. I'd rather climb Mt. Whitney. By that I mean find a powerful processor like the TMS320C6678 DSP from TI with 8 Cores and then connect the DSP to your FPGA over one of the common high-speed serial links such as PCIe, Rapid Serial I/O, or Gigabit Ethernet. Then only implement that serial link in your FPGA design not using QSys.   So, what are your thoughts? Please let share them.

[Altera_Forum]

For small things I use NIOS II, easier to use. When I use ARM SOC of Cyclone V I start from a Linux OS, not from baremetal programming.

[Altera_Forum]

Thanks for the comment. Do you think the ARM SOC can handle number crunching tasks like RADAR image processing? What kinds of applications do you see is a best fit for these ARM SOCs by Altera? Do you see a lot of vendors using these ARM SOC's from Altera on their new designs?

[Altera_Forum]

I am currently working on a project of real-time multi channel audio processing. Initially this was intended as a pure FPGA-based design, but by mere coincidence I got a Cyclone V eval kit with two ARM cores. Although being early in the process, I gotta tell you that I love this! The power of combining the fast, streamlined, parallel capacity of the FPGA combined with the flexibility and well-known system of Linux SW is just brilliant. In fact, with the combination of the two, the device offers a very simple customer product configuration scheme, using a standard web server running on the Linux part of the device. The SW engineer feels very at home with this. 

 That being said, I can relate to your co-workers concerns. Getting the FPGA system up and running is pretty straight forward, but getting the SoC HPS system up and running has proven to be far more work than I anticipated. The learning curve is very steep, and there is a lot of do's and don'ts to be learned about this. I have to admit that I also expected the system tools to be slightly more mature. Especially with relationship to software and the process of booting. There exists a number of resources for describing how the configuration and software for boot can be made, but it's a lot of steps and there isn't any ready made automated tools for this (that I know of), so I had to make a custom build framework for this.  I am very positive towards Qsys thou. Doing a system design with a lot of modules, and in my case, IPs that handles streams of data, is extremely tedious and error prone to knit together manually. Qsys makes this process much simpler, and e.g. by adoping the (simple) Avalon-ST interface to your IP, it very easy to do the block-to-block connection configuration in Qsys. You don't have to instantiate any hard or soft CPU in Qsys if its not needed.  I have been working with both dedicated ARM + FPGA solutions in the past and now the SoC FPGA solution. The advantage with the HPS solutions is the ease of interfacing between the CPU and the FPGA. E.g. you don't have to bother with PCIe. The downside is that very much is configurable, which requires both the FPGA engineer and the SW-engineer to work in a completely new way of thinking. It's no longer "what can we do with the peripherals we have", but rather "what do we need". And that is were it gets complicated. You need to know how you want to build your system, including the SoC system parts. And that can be a lot to absorb.  All in all, I expect to end up with slightly more engineering hours on FPGA and HW, but I'm hoping it will be shaved off from SW as standardized interfaces/drivers can be used. We'll see, the project is far from complete...  Well, these are my thoughts. Hope it helps your considerations.

[Altera_Forum]

Handling ethernet is faster with Linux on ARM but to do fast image processing you need hardware accelerators on FPGA side.

[Altera_Forum]

Thanks for adding your comments. I'm not familiar with hardware accelerators on the FPGA side. Would that be FFT megafunctions running on the FPGA side? I've heard the term hardware accelerators when reading about OpenCL but am still in the dark on the topic. Can you explain a little? Also, would you think this would apply to the Stratix 10 when it released? Also, can you share you experience developing ARM applications, has it been painful or painless? Thanks a bunch!

[Altera_Forum]

The soc thing is nothing new. People have been using processors (power pc, arms, x86 etc) alongside fpgas since the start of fpgas. Xilinx have had hard core cpus in their fpgas for at least 10 years (power pc, now arm), so altera are only now just catching up with Xilinx (10 year lag). Altera have really missed the boat on this, and the fact they farm Linux support off to rocketboards is quite telling (ie. Altera don't care much about the soc market). 

 Fpgas are good at number crunching, cpus good at control.

[Altera_Forum]

Thanks Tricky! I'm so thankful for all the comments. I'm taking the Qsys and ARM training classes from Altera this June and I'll ask the instructor these questions and comments.

[Altera_Forum]

--- Quote Start ---  The soc thing is nothing new. People have been using processors (power pc, arms, x86 etc) alongside fpgas since the start of fpgas. Xilinx have had hard core cpus in their fpgas for at least 10 years (power pc, now arm), so altera are only now just catching up with Xilinx (10 year lag). Altera have really missed the boat on this, and the fact they farm Linux support off to rocketboards is quite telling (ie. Altera don't care much about the soc market).  Fpgas are good at number crunching, cpus good at control.  --- Quote End ---    I've noticed that the activities both here on this forum, as well as on rocketboards, is far less then what I'm used to with other development communities. I have a handful of unanswered posts both here and on rocketboards, which I find unfortunate. For this type of development and you're stuck, this community might not be the place to go to if you're in a hurry.  I'm not particular familiar with Xilinx, but do they have a better development community? Since "Altera lags 10 years behind Xilinx", is the development tool for this more mature on Xilinx? From other experience in our company, Xilinx and Altera has constantly been leaping over each other. One year Altera is better, Xilinx the next. In the big picture is really does not matter which you choose.    --- Quote Start ---  Thanks Tricky! I'm so thankful for all the comments. I'm taking the Qsys and ARM training classes from Altera this June and I'll ask the instructor these questions and comments.  --- Quote End ---    There are free online training that you can sign up for. I had good experience taking a few of those and browsing through them to aquire some basic understanding before heading into the training classes. Helps to ask the productive questions to the instructor when he's there.

[Altera_Forum]

I don't really have much experience when it comes to the embedded side, but week it comes to the fpga side, altera have always had a better set of tools over Xilinx. That is changing with vivado, but it is only just catching up with the quartus toolset.

[Altera_Forum]

Thanks for responding to this post. All is very useful information. I posted these questions on this topic on the SOC forum but had very little response. I wonder if the Xilinx tools are better than Altera when trying to debug the FPGA side and the HPS side at the same time. My co-worker is doing an HPS application on a Cyclone V and he demonstrated how one must debug the FPGA and the HPS together. We joked that soon he will need three or four monitors to see all the debug windows.

[Altera_Forum]

I come from the software side and I think it is awesome to have the arm processors.  

 It provides me with an entry point and a path to upgrade the performance of my system. It is starting off with minimal signal processing done on the fpga and as I get more demand I'll try to offload more to the fpga.

[Altera_Forum]

titantomorrow 

 Thanks for responding to my post. Do you have any experience with Altera's ARM+FPGA devices? Have you developed any applications? I'd like to know if you found it "painful" or "painless"? I agree with your observations on the possibilities of these devices but the complexity of the tools and the inadequate documentation I have a hard time believing any designer will quickly choose these devices in the designs. It would be less risky to keep these two worlds (ARM,FPGA) separate and spend your energies getting a high-speed serial link working between the two devices to pass critical data. As I said in the start of this post I'm enthusiastic about these devices but after seeing my co-working spend months only on the FPGA development I can't see any program manager supporting such an endeavor. That's why I really believe that Altera must have something better waiting in the wings when the Stratix 10 is released. However, the more I hear from others in the communities the more informed I'll be and my change my opinions, so please share your thoughts.

[Altera_Forum]

I have a long history with both Quartus and ISE. Between those two tools I agree that I much preferred Quartus. Better integrated, easier to use. SignalTap was a big part of that. Much easier to use than ChipScope. 

 About a year ago we started a new platform targeting a Zynq device with Vivado. Got pretty far down the development path on a ZC706 dev kit, but due to some pricing issues and limitations of the Zynq silicon (no DDR4, no PCIe gen 3, etc) we jumped ship over to Arria 10 SoC and Quartus Prime. Compared to Vivado, Quartus Prime feels quite outdated and cobbled together. I found Vivado's IP Integrator vastly superior to Qsys, which is a pretty primitive tool by comparison. And the way Vivado handles IP is consistent and very well thought out. Quartus is way behind in that regard. Xilinx is also light years ahead of Altera in terms of documentation (quantity, quality, ease of management with DocNav) and in the availabiliy and quality of reference designs.  As for development communities, as mentioned by sveinse above, this forum is a ghost town compared to Xilinx'x user forum. Especially for SoC designs. I've posted a few Arria 10 SoC questions here and don't think I've ever gotten a response. Xilinx staffs their user forum with a whole team of employees who monitor the forums and answer questions quickly. On this forum there is very little company support. We knew we were early adopters with Arria 10 SoC, but it really feels like we're flying solo. So far the Arria 10 silicon looks awesome vs. Zynq. But tools and support are critical and Altera is way behind Xilinx in those areas. It's not even close.  Back to the title of this thread, there is a lot of hype with SoCs. Both Altera and Xilinx are pushing hard on the idea that any old software dude with no FPGA experience can describe a system in C code, push a few buttons, and voila! Well, it's never going to be that simple. If all you need is a processor and a few peripherals then no problem. But integrating a hard processor with a complex FPGA design on an SoC is not much different than it was with a separate processor and FPGA. In fact in some ways it's harder because the tools and methodology are geared toward the Qsys/IP Integrator approach. That's where hype meets reality.

[Altera_Forum]

thanks, rsefton, very informative. One small follow up question given your experience on the topic: Would you consider it unwise to design custom IPs with Avalon? Avalon is conveniently simple to use, yet the design will have a lock-in to Altera.

[Altera_Forum]

I think you have answered your own question: If you need the IP to work across vendors, dont use Avalon. Annoyingly though, if you want to connect to any Altera IP, it will have Avalon interfaces. 

Luckily, Altera provides AXI->Avalon converters for everything except streaming (which isnt that difficult to do yourself - its just a FIFO with some extra control logic).  So - always going to use altera - use avalon. Using anything else - go with AXI.

[Altera_Forum]

Thanks everyone to responding to this post!

[Altera_Forum]

sveinse - If you're designing custom IP for your own use then I would probably not use Avalon, but it depends on what you're doing. I understand the benefits of AXI and Avalon as standard interfaces, but I would never design an entire system around either bus. It may seem convenient to stitch a bunch of blocks together in Qsys or IP Integrator (Vivado) and not have to think about the details, but have you ever looked at how much logic gets consumed uunder the covers as the tools do the stitching? Width conversions, protocol conversions, clock domain crossing, muxing/demuxing, etc. I prefer to have more control over my designs and not have so much crap inserted by the tools that I have little or no control over. And it's not just the extra logic. The inserted logic doesn't always give you the best performance. 

 I typically only use Qsys or IP Intergator to instantiate and configure the HPS and whatver blocks need to interface directly to the HPS. I export the AXI or Avalon interfaces I need to connect to the rest of the FPGA design and I'm then done with that part of the system. The rest is normal HDL design (verilog in my case). I then create a top-level verilog wrapper that instantiates my logic and the HPS/Qsys wad and hooks everything up. I'm not saying that's the only way or the right way to do things but it works for me. As I said above, it's a control thing. The more you depend on the tools the less able you are to debug and fix things when they go wrong.

[Altera_Forum]

Hi Joe, I've new to this world of FPGA and have not done much at all. 

 I come from a software development background (although I have a computer systems engineering degree), but I do know a bit about F# (declarative language) so it is actually not too different to HDL. After going through many of the tutorials and training videos, I think I am getting a handle on FPGA. However, it seems closing timing is a bit of black art.  At the moment, I'm not suffering too much from lack of documentation. But then again, I'm yet to find anything that is well documented. In a strange way I think the lack of documentation forces us to figure stuff out so in the long term it is good. Learning is quite steep and painful, but I'm focusing on the rewards.  I know what you mean, it requires a leap of faith. Having the two technologies closely coupled benefits me trying to do it all and not worrying about the best way to connect the two devices. Although there is a clear line of separation in the soc-fpga devices, I can just see the politics between the software and hardware developers emerging.