--- Quote Start ---
1) Instead of having 8 ouput PIOs of 8 bits each, can I have 2 ouput PIO of 32 bits? If yes, how do I modify the C code to reference the right address? For example, suppose I have my 32-bit PIO data_out_32bit_ptr at address 0x08208090. In the C code for-loop, I am not sure how to reference the correct data. Is something like below correct?
*(data_out_32bit_ptr)= line1;
*(data_out_32bit_ptr + 0x8)= line1;
*(data_out_32bit_ptr + 0x10)= line1;
*(data_out_32bit_ptr + 0x18)= line2;
But I see the End address as being 0x0820809f in SOPC Builder when I include such a 32-bit ouput PIO.
--- Quote End ---
Yes, you can have 2 32-bit PIOs. I can't answer your C coding question, but it sounds like you'll need some type casting. If your data is stored as sequential bytes, then accessing line1[i] as a 32-bit element should return a 32-bit number. You can check this with a printf("%x").
--- Quote Start ---
2) I suppose I can make the most of FPGA parallelism by getting rid of this for-loop. But how do I send the data then?
--- Quote End ---
Before getting into this, you should ask the question "do you NEED to?" If you're system is operating in real-time with enough headroom for anything else required then your job is done. Honestly, though, if using PIOs on a 50-300MHz processor is sufficient, then you don't need an FPGA. It could probably be done on a PC-104 stack or other single-board uC. You could also take advantage of floating point ops on a Power PC or PDSP without much difficulty.
If the answer is yes, then you have options. Refer to my original response. Since you have 2 32-bit inputs and 1 8-bit output to your module, this would be a good candidate of a custom instruction and you'd save 2 of the 3 cycles required for PIOs. But to utilize the FPGA resources and gain serious speedup, you would add a wrapper module that replicates the Sobel module. The Nios in this case would probably be doing some DMA transfer or providing the Avalon-MM address to a memory location (if you give your module an Avalon-MM master & slave port and connect it in SOPC builder). The wrapper module would retrieve a large block of pixels and perform the Sobel operation N times.
For a simple example, the wrapper module gathers a 4x4 pixel grid. With this data, you could instantiate 4 Sobel submodules and return 4 resulting pixels. The wrapper simply maps the correct pixels to the corresponding submodule(s). It would also be responsible for handshaking with other Avalon components and the Avalon-MM clock interface. Note that your submodules need not be clocked, only that you latch the data when it's guaranteed to be available. There are several examples of creating Avalon-MM components on Altera's website.
--- Quote Start ---
3) Also, the results contain 98 values which I can print on the console window. But I need to store the values. I tried the altera_hostfs and I managed to send the data to a text file on my computer (after 3 days of fighting ;)!) But this works only when I choose Debug As -> NIOS II Hardware and it seems to run slower than when I choose Run As -> NIOS II Hardware. What is the best way to get those values?
--- Quote End ---
I haven't used this method, so I can't comment on why Run is slower than Debug. Debug allows you to step through the Nios instructions with breakpoints. If Run mode isn't working then there's probably a timing issue.
Storing data is a problem in and of itself. Why not just copy/paste from the console after your image is complete? Does it need to operate untethered from your PC?
I frequently copy from the console and paste into MATLAB/Octave to verify the results. For something more automated, or if you're using this system iteratively, you'll need to store results in non-volatile memory like onboard flash or an SD card. Sending over USB to a harddrive works too, but is more complicated. What components are available on your eval board? Better yet, what eval board are you using?
Honored Contributor
