Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
888 Views

Beginner lost

Hi, my name is Onofre Garrido and I'm currently working for a company called MECWINS. We have developed some prototype devices to test biological parameters. So far since we are on prototype stage we have built our devices around daq cards from N.I,, labview software and dedicated PC to manage all the components. Our last device uses a matlab software running on several pc cores in order to process images. 

 

My current work focus is on exploring the possibility for using fpga's instead of dedicated pc's for instance in our last device. My knowledge about fpga’s is quite limited so now I think I need some support in order to go in the proper direction. 

 

I have seen for example that there are several softwares to convert matlab code to vhdl that could be potentially implemented on a fpga, but many doubts come up to my mid. How would be the interface for the fpga to be connected to the external world, for example to open a file in any kind of data format? What kind of fpga do I need for processing images? how to interface with the daq world, for example to receive signals from a PSD ...? 

 

May be we need a development card that surround a fpga with kind of peripheral hardware such memory, A/D converters, etc.. 

 

I've got a DEO-nano board that I am currently testing in order to get into the fpga world, but I need some support for sure. 

 

 

 

I know that perhaps this mail is a crazy mix of probably not well digested ideas. Sorry for that. 

 

Thank you in advance for your support.i
0 Kudos
15 Replies
Altera_Forum
Honored Contributor I
85 Views

You need to know that FPGAs are blank canvases for you to add your own IP in to. They can do everything you describe, but YOU need to provide all of the code, connectivity etc. They are also NOTHING like writing software. 

If you have little experience with FPGAs, you are going to struggle with what you describe as they can be fairly advanced projects to generate, debug and integrate and are not going to be turned around quick.  

 

So you know what you're getting into.
Altera_Forum
Honored Contributor I
85 Views

Let's simplify the thing. A good way to start would be just reading an image file from an input , make some calculations and just provide a numeric output. 

 

How could I do just this as a starting point? 

 

kind regards
Altera_Forum
Honored Contributor I
85 Views

You will need to write a design that contains some form of input, the processing and then output it somewhere. 

You do not transfer the data as a file, you transfer it as raw bytes. The FPGA has no knowledge of a file system or files, just pure binary data.
Altera_Forum
Honored Contributor I
85 Views

Ok understood.  

 

Correct me if I am wrong but my assumption was that there should be any kind of card or development board which have already implemented such interface in order to simplify this job and get focused on the core of the question , that in this case is just the calculations required for processing the image.. 

 

Am I right???
Altera_Forum
Honored Contributor I
85 Views

There may be reference designs with some interfaces, and IP cores are available for common ones (ethernet, PCI, PCIe, RS232) from altera that you can import into your design. Then its a case of connecting it all up to your custom logic. 

Remember, writing logic for the FPGA is not like software programming.
Altera_Forum
Honored Contributor I
85 Views

And what about a FPGA SoC? would it be easier going on that direction? 

 

thank you so much for your answers. It helps so much..
Altera_Forum
Honored Contributor I
85 Views

The SoC gives you a hard ARM processor on the chip. You still need to set it up yourself, put an OS on it etc. You can put a processor on a normal FPGA too, but a NIOS core instead of an ARM. Either way, it will still take some set up and configuration by you.

Altera_Forum
Honored Contributor I
85 Views

Yes , I see your point. My question about the SoC option was in the following reason. Having an already configured ARm processor running for example a Linux OS, the basic functions for accessing files, reading its content are already in place. This way the focus will be on setting up the communication betwen the FPGA and the ARM processor and the calculations on the FPGA. The objective is avoid the aditional work on designing staff like handling files with an FPGA. 

 

Does it make sense???
Altera_Forum
Honored Contributor I
85 Views

This does make sense, but you can easily just send data to the FPGA from an fpga and send it back to to the PC quite easily without an ARM/another CPU. The easily option is RS232 communication. Other methods are possible. The good thing about a CPU is that communcation is easier to set up, but it takes up a lot of resources just for coms.

Altera_Forum
Honored Contributor I
85 Views

If you don't have FPGA experience in house, it can be quite a significant cost to build it up / learning curve.  

 

In broad strokes, what you're describing (your background, what you are doing) might be a good fit for OpenCL. 

https://www.altera.com/products/design-software/embedded-software-developers/opencl/overview.html 

 

And your development might go like: cleanup Matlab and translate to OpenCL entirely on PC, figure out what OpenCL functions you want pushed into the FPGA vs. kept in software on the ARM side of your SoC. 

 

In general for some of your questions: 

a) yes, using a SoC with hard ARM with Linux will absolutely make your life easier especially if you are coming from software background. 

 

b) anything which is non-realtime related, think about doing it in software and not FPGA. if you aren't doing (continuous) Video processing and are instead only doing (single frame) Image processing, you can limit yourself to just creating "accelerator" IP blocks in the FPGA side of an SoC, where software drives the algorithm and does all the I/O and can easily fill in missing functionality that is outside your reach to develop the FPGA version of. Continuous real-time processing of video, you may need to do all of it in the FPGA with software limited to control activity. 

 

c) video in / video out if not on your development kit can often be added with a daughter card. Terasic is one vendor (http://www.terasic.com.tw/cgi-bin/page/archive.pl?language=english&categoryno=65#category68). Sometimes pairing daughter cards with a compatible development kit can be challenging, so before you buy, contact them. 

 

You've been mentioning SoC, but also mentioned you have DE0-NANO which isn't an SoC (Cyclone IV, 22KLE, no ARM). There is also the DE0-NANO-SOC aka Atlas-SoC (Cylclone V SoC, Ethernet, etc.). 

 

Getting started with a Cyclone IV, I'd recommend doing all your software / I/O on the PC and communicate with your hardware over JTAG using System Console. 

Getting started with a Cyclone V SoC, you can just get Linux up and running and communicate with your hardware directly on your board.
Altera_Forum
Honored Contributor I
85 Views

your answer is really helpful, as well as the previous one. 

 

what do you think would be a good test bed set up for a starting point? Let's say that the starting point would be just receive a image file as an input and producing as an output any kind of basic calculation based on the image data. No real time. Just one single static image processing. 

 

I assume that using the DE0 nano ( no Soc) would entail the design of the comms with the pc and the file reading from scratch, so Deo-nano-Soc would be a better choice, isn't it? Would be OPenCl aplicable as well to simplify this ? 

 

kind regards and thank you again
Altera_Forum
Honored Contributor I
85 Views

With hardware you already have, you have a couple different ways you can go. 

 

1) NIOS + C software in board + your custom IP component doing your math. See: https://www.altera.com/support/support-resources/design-examples/intellectual-property/embedded/nios... 

Your NIOS C software can include the "Host Based Filesystem" so your C code can use <stdio.h> to open your file, read some binary data, write it to your custom IP component math block, read the result back, write the result to binary file. 

If you are OK with C on an embedded processor, this path works fine and the FPGA on your board has enough resources to go down this road at least for beginnings. 

 

2) TCL script + Altera System Console + your custom IP component doing your math. See this user contributed tutorial: http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial 

If you aren't OK with C on an embedded processor, you can use TCL on the PC to read your binary file, write the inputs, read the results, write the results to binary file. 

You have almost all the FPGA resources available for your processing and you don't have to familiarize yourself with NIOS IDE for software development. 

 

 

I do not believe OpenCL is supported targetting the board you already have. See this document for supported development boards: https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/products/software/opencl/opencl-dev-... 

 

Creating your own IP component, there are several tutorials. Here is one video: https://www.youtube.com/watch?v=v6rhbvablo8 

 

Another thing you can do, if you go the NIOS route, is work with Custom Instructions instead of Avalon-MM Slave based peripheral components. Either way is fine for getting started, but Custom Instructions aren't really applicable going forward to a ARM SoC future. 

Custom Instructions are a good fit sometimes if you have a body of C/C++ code which compiles and runs fine on the NIOS - depending on what you're doing you can then get huge gains in performance by pushing kernels of your image processing down to hardware. 

Coming from Matlab though and not having a background in FPGA development, you will probably get better trade off [more automation/tool support] investing in the OpenCL route. 

 

 

 

Finally: Altera has some good online [free] training videos that if nothing else will walk you through the basics of many things. 

https://www.altera.com/support/training/overview.html 

https://www.altera.com/support/training/course.html?coursecode=odswbecome 

https://www.altera.com/support/training/course.html?coursecode=oqsys3000
Altera_Forum
Honored Contributor I
85 Views

Really appreciate your answers. I'm learning actually more in several answers than struggling looking into the documentation I have. 

 

I'll study your answer in detail. Now is too late in Spain to be at work.I'll be back tomorrow. 

 

Thank you again
Altera_Forum
Honored Contributor I
85 Views

HI again,,focusing on the OpenCl and trying to figure out your statement: 

 

And your development might go like: cleanup Matlab and translate to OpenCL entirely on PC, figure out what OpenCL functions you want pushed into the FPGA vs. kept in software on the ARM side of your SoC. 

 

 

 

I'm trying to understand how would be the way to start with just a very basic example ( as I said , open a file , read its content in a sort of array, proceed with simple calculations and return a value) : 

 

 

 

If I understood properly the approach would be something like this. 

 

Getting an OpenCl compatible fpga develompent Board with SoC. 

Install this OpenCL software on the Pc 

An then.... 

would be the section of the code for handling the file written in the OpenCl too? 

Would OpenCl handle as well the control of what will be executed on the ARM and what in the FPGA? 

 

a bit confused on the way to proceed for going on thath direction. 

 

Thank you in advance again
Altera_Forum
Honored Contributor I
85 Views

https://www.altera.com/products/design-software/embedded-software-developers/opencl/developer-zone.h... 

 

In the left margin, click on "Design Examples" and pick one that looks relevant (Vector Add ?) and skim through it. 

 

OpenCL applications have two parts: the host (ARM SoC Linux application) and the device (FPGA logic). 

 

The general idea is your host side Linux application would load and prepare buffers from files, ship them to the FPGA kernel for execution, receive the result, and store the buffer back in files.
Reply