06-24-2016 01:20 PM
Hi, This thread might be because I'm new to FPGAs and all over internet, there are just so many unusable general solutions by professionals that us newbies can't seem to understand. Here's my problem.
For an image processing project, which needs to be implemented on FPGA, I got a this Development Board (called ESPIER III) from a company called "zr tech". This is the best thing I could get with the budget and board availability in my country, and don't bother searching for datasheets or stuff (But if you did, I would be genuinely grateful). there are 3 DVDs bundled with the board which have almost everything, though they are in Chinese and I had to use google translate on literally everything (even the file names) and even spend some time to realize that what google translates as "Digital Tubes" are actually 7-segments!
anyways, this board has a Load Flash with 32Mbits capacity by the model name W25Q32BV, and a SDRAM with 64MBits capacity from winbond (Part No w9864g6kh-6). the FPGA is Spartan-6 XC6SLX9N3TQG 144 pins and pretty much every usual stuff dev board peripherals. The thing is it does not have good and comprehensive examples for different peripherals and so I'm lost. Plus the project due date is killing me. also, I use ISE 14.7.
What I need to do is to implement an algorithm on a grayscale image of my own choice (I currently use standard Lena picture which is a 512X512, 8 bit grayscale picture), and send the result back to PC to Matlab. what I figured until now is that I could store the picture on the board memory, do the algorithm on it and send the result back to PC with a UART to USB interface. The UART interface is somehow taken care of, but my problems come prior to that.
First of all, I don't know if this is actually the best course of action. this is what I thought of, but I'm not sure. The Board does not have an ethernet port or bluetooth, so I'm guessing UART is good. but the rest?
Second of all, I don't know which of the 2 external memories I can use. in iMPACT, I can build a SPI Flash that matches W25Q32BV, and this is working fine for storing configuration file. But when I store the picture in it (I converted the picture to .bin format using matlab), it takes 1.2Mbits of the space (with Data Width of 1, which I'm pretty sure should be 8, but this SPI Flash does not have this option), and when I try to implement it in my program as a Distributed Memory IP Core, I can't have 32Mbits address. I know I'm doing something horribly wrong in here, I just can't figure out what.
also, if I want to build a BPI Flash, then It's possible to choose Data Width of 8, but I don't know which BPI PROM is my model. it can't be W25Q32BV (because it is not on the list), and if it's that 64MBit SDRAM, I don't know which one to choose.
or maybe I can use IP Core gen to make a memory of 512X512 data width and store my picture as COE format in it (I actually didn't do it yet, so if anyone has a suggestion, thanks). But if I do this, then wouldn't Ibe needing to do SPI/BPI PROM in iMPACT?
As it's obvious, I'm lost. so if anyone can help me, that would be great.
06-24-2016 07:04 PM
Your plan to use the UART for data transfer seems reasonable. The other option would be to use the built-in VGA port to display data directly, but that makes comparing the results to known-good ones from Matlab much harder.
Would you mind sharing your Matlab code for converting the image to BIN format? 1.2MB for an image where all dimensions are powers of 2 does not seem right, but it'll be a whole lot easier to debug if we can see the code. The most common issue I've found is that you've opened the file with option "w" (write), whereas for binary mode you need to use "wb" (this stops fwrite helpfully inserting text-style escape characters). An alternative is to open the image in Irfanview and save as raw; this produces a .RAW file which is exactly what you need.
Regarding storage: what sort of algorithm is this? Is it a streaming or near-streaming one (eg. like convolution, where you buffer a few lines and then produce one pixel of output per pixel of input) or does it require repeated access to the whole image (eg. blob analysis)? If it's a streaming algorithm, I suspect that the easiest option is to not store the image at all; have Matlab send the image one pixel at a time over the UART, process it on-the-fly, and send the result back out of the UART.
If you do need to store the whole image, then that makes things harder. You can't store it on-chip using the distributed memory or block RAM; the image size is 2Mbit and even if you use the entire FPGA as memory you'll only get about 650Kbit of space. This will mean that you have to use off-chip memory, either the flash or RAM, which then requires you to know how those chips are actually wired up to the FPGA. With no datasheet or schematic for the board, this will be difficult. Of course, you need to know how the UART is wired to the FPGA too, but at least that's only two pins.
06-25-2016 12:12 AM
Thank you, yes showing on VGA port is not an option. I need to compare the results with simulation results.
for converting algorithm, I'm using the matlab function attached. this actually uses 'wb', but also adds an enter after each byte of data. I got this idea from somewhere that it said it was better for FPGA. if not, please correct me. also, is RAW format really better for what I want to do?
my matlab algorithm is resizing. the image should be resized using this algorithm which is not finalized yet. so I'm guessing it's more like a streaming algorithm. about processing on-the-fly, do you think this is a good idea? because UART supports up to 115 Kbits, and I think it's slow. but actually I came up with the storing idea to avoid these delays.
finally, for wirings, I have the datasheet and pinouts for the board. I attach them for you here, some words are in chinese but they are not important. can you help me with that? I would appreciate it if I can store the picture in off-chip memories.
06-25-2016 08:36 PM
Storing the image in SPI flash makes sense to me. First, you don't really need a schematic for that because the SPI must be hooked up to specific pins in order to work correctly for configuration (see the Spartan 6 Configuration user guide). Second, it's fairly easy to use Impact to add the image file to the .mcs prepared for your bitstream. Without a schematic or at least a guide or UCF for the board, I don't see how you would use the external RAM.
I'm assuming the algorithm for image scaling should only need to buffer a few lines. Usually image scaling consists of filtering and resampling. For a filter with an N x N kernel, you can usually get away with buffering N-1 lines on-chip. On the other hand you can also access the SPI flash randomly if you don't care how slow the performance is. Then you shouldn't need much buffering at all.
06-25-2016 10:26 PM
you're right gszakacs. I can store image in SPI with iMPACT. I already stored configuration in it and it also has enough space for the image. but how can I use it in my program? I know that my processor type does not support MIG (it's 144 format pin), and I've heard that I can also do this in Core Generator. can you help me with that?
plus, I attached the schematics and pinout just to make sure that we have everything we need for the procedure. currently I'm working on doing the scaling on the fly. I found This UART core and it's working fine in my hardware. What I'm trying to do is transmit the file to my FPGA, do the scaling, and send it back to PC.
06-26-2016 02:10 AM
Regarding the Matlab: I see what you're doing now. The newline won't bother the FPGA at all, but for opening an image in a text editor it'll help (most text editors do not appreciate lines 1,000,000 characters long).
However, I would strongly recommend going to a raw format for the FPGA. Printing the values out in ASCII (base-10) means that the FPGA is going to have to do a base-10 to base-2 conversion, and each value takes between 3 and 5 bytes. This means that if you want pixel (123,456) in the image you have to count through the pixels until you find the 233595th one. If you do it in binary, then there's no conversion (it's base-2 all the way) and since every pixel occupies exactly one byte you can go to location (123,456) simply by jumping to the 233595th byte. Obviously it's also a lot smaller; a 512*512 8-bit raw image occupies 256KB (2Mbit), by definition.
Regarding streaming over the UART: well, the image is going to have to go over the UART at some point. 256KB at 115.2Kbit/s with eight bits from every ten usable (since the UART has stop and start bits) will take about 22.2 seconds at full-speed. With a streaming algorithm (adding a few lines of delay) it might take 23 seconds total (since data going to the chip and data coming back from the chip happen simultaneously).
If you do want to use the off-chip memory, it sounds like the SPI flash will be much easier. It'll be much faster than the UART, although much slower than SDRAM. The big advantage is that you can access it with an SPI controller, which is basically a clock and a shift register with a total of only four pins used. The pins you need are MOSI (65), MISO (64), CCLK (70), and CSO_B (38). Xilinx provides suitable SPI IP cores for free.
06-28-2016 11:26 PM
OK, so far I tested sending the image using UART and sending back the processed image to PC. although I didn't do everything, things seem to work fine. but still I'm left with the question of how to use the stored image on SPI memory in my code. My processor does not support MIG cores, and I can't find a suitable way to add it to my project. any suggestions how to do this?
06-29-2016 04:02 AM
No need for a MIG to access the SPI memory; the MIG is for accessing high-bandwidth external RAM.
For SPI you just need an SPI controller. Either you can write this yourself (SPI is just a shift register and a clock; not exactly complex) or you can use the free LogiCORE AXI SPI core.