08-04-2016 09:53 AM
I am a little bit confused how and if I should use SDSoC. I've written a hardware accelerator and added it to my vivado project, did all the connections via axi-lite and was able to run it on my zedboard as "bare metal application". Everything works as expected :)
I'd like to run the accelerator on some data from another server, which uses HTTPS / SSL. Therefore, I'd like to use some external SSL lib to automatically download to data and then do the processing. Since I think reimplementing SSL or even recompiling it as bare metal application on ARM is tough work, I thought linux might be the way to go here. But since I dont want to write my own hardware kernel driver, I thought SDSoC might be helpful here.
But I have some questions:
1) What actually does "OS" mean when I create a new SDSoC project? Specifically, where is the difference between Linux / RTOS / Bare Metal? Will the option "Linux" offer me a full posix implementation with bash, so I can compile nearly every linux application against it? (Specifically a ssl library)
Or does that "just" generate the necessary files to be copied on my SDCard with some minimal linux kernel / bash / serial support?
2) UG1027 (chapter 10) mentions a way how to generate a library from hardware accelerated code. How is this intended to be used? SDSoC creates a library for me and I develop the remaining part of my application against the generated library and then just compile it on the (generated) linux?
3) Given I have the source code of a small SSL library (which is not optimized towards FPGAS or even embedded systems, but just plain C/C++, like e.g. openssl [even though thats probably not small]) and my hardware accelerator was generated by vivado HLS (so I've C code there as well). Is it now possible to "just" import all the *.c/*.h files into SDSoC and compile it from there? Isnt this kind of the idea behind SDSoC?
As you can see, I'm a little bit confused on who to use this tool and what actually happens in the background. I've some experience with vivado,vivado HLS and vivado SDK. But usually I programmed the zedboard as bare metal applications with lwIP. Never really needed a full linux.
08-04-2016 12:45 PM
1- Choosing linux as your "OS" literally means you'll get a SD-card with a linux kernel on it. When you try to boot the board, it'll boot linux. It's actually linux, rather than being linux-like, or a thin emulated environment. It also means your application will be compiled against linux runtimes/libraries/etc. The generated SD-card will contain a full linux kernel, ramdisk image, and your application. You can also compile anything else you want and stick it on the SD-card, such as libraries/executables/an ssl library/whatever.
2-This flow is very similar to the process of creating a normal library for use by a normal software program. The only difference is that the library encapsulates inside of itself enough information to make use of accelerators existing in the PL. You'd link against it using sds++/sdscc in a fashion very similar to how you would link against a normal library with g++/gcc. With that said, just like in the case of g++/gcc, you don't have to use libraries if it doesn't benefit you to do so.
3- Including those in your project will allow you to compile them as normal. They won't run on the FPGA without added effort, but they will run as normal software on the arm cores. The code you write will then end up being the glue between the openssl libs you included and the accelerator you want to use. Pretty much anything you could normally shove through GCC can be shoved through sdsoc as well.
06-06-2019 02:58 AM