Entering The World Of FPGA's with a DEO-NANO P0082 - Part 1

You haven't got it quite right re. the boot up process:

Your board has  a small (2k) I2C EEPROM but this is far too tiny to store the boot up image for the FPGA - it has as an ECPS64 8Mbyte Flash chip for that. You are right that this FPGA (like many others) is RAM based so needs to copy the image from somewhere non volatile on power up. I don't know what to call the code like thing that FPGAs have so I call it an image so as not to mix it up with programmes for micros.

I try not to talk about writing software for FPGAs  - after all VHDL and Verilog are both officially hardware description languages but it does sound a bit pompous to say I spent my morning describing hardware !

Do you have a project in mind for the Nano ?

MK

Thanks! Yes I just found out this morning that the "image" was stored on an EPCS device when I was trying to find the driver to connect it to the computer and came across the technical docs for it!!

The quick start guide says that the board comes pre-loaded with a bit stream to demonstrate the board but I'll probably stick to calling the result of the compiler an image like you, it sounds right.

I'm gonna spend some time trying to get a basic working knowledge of the board first and then move onto using it to drive a 32x32 rgb led matrix as a first main project. Ive just tested out some of the demo's which install by running a batch file, I supposed its time to have a read of the full user manual and see if I can move forwards from there!

I'd call it a 'bitstream' too (I've worked with Xilinx FPGAs in the past). 'Image' is ok in my book as well - it describes what is going on much better than the word program.

Bit stream is good because it's a stream of bits being loaded into shift registers on the device. When all the bits are in the correct place, they get latched into place, taking over from the default settings and controlling the various elements of the FPGA (routing connections, etc).

One thing that's useful to remember, if you're designing hardware to go around an FPGA, is that that process takes time [a considerable time, in electronic terms, if you're used to logic that just starts instantly] and until the bits get latched the FPGA will hold the I/O pins in a high impedance state. If you use the FPGA to generate chip selects to external devices, or that kind of thing, you may need to consider carefully what happens before the FPGA gets going to avoid conflicts [usually just a few carefully placed pull-ups or pull-downs will do].

I can remember one design that I did that incorporated registers that an external processor could write to in order to set up various parameters. It didn't work when I tried it with a simple test program to load the registers, even though I could see on a 'scope the right data being written across. After spending a while looking at all the wrong things, in the way that you do sometimes, I thought to look at the signal that showed when the configuration was complete and realised that the processor was pushing the data across a couple of hundred milliseconds before the FPGA was finished with its configuration.

An LED tile is a good project. LED displays lend themselves well to debugging designs - it makes for fast progress being able to see the mistakes in front of your face. Do you have an oscilloscope to look at waveforms?

Thanks, theres some great advice there!

Yes I have an oscilloscope to check things out with, one of the things I'll probably need advice with is how to get the image data into the fpga.

There is a programmer inside the Quartus software. After compiling your code, you can upload image (SRAM Object File (.sof)) to FPGA via that tool.

Mehmet

There is a programmer inside the Quartus software. After compiling your code, you can upload image (SRAM Object File (.sof)) to FPGA via that tool.

Mehmet

Hi Mehmet,

Yes Ive used the programmer already, what Im talking about here is my eventual project where I intend to take some image data (from a picture) and use the fpga to display that onto an LED matrix display. My question was how to get the image data from the picture into the fpga, Im sure there are plenty of ways that will become apparent but Im interested in other peoples ideas

I use mainly SPI or UART style interfaces to get control data in and out of FPGAs. For fast data transfer it's Gbit Ethernet or worse.

If you are going from PC to FPGA it's easy to get up to about 1Mbit/s down an FTDI USB/uart lead and it appears to the PC like a com port. Then you can use the same port for debug and control, initially using a standard terminal programme on the PC. Later you can use VB, C, Python or whatever - and of course you can use any computer with a logic level UART interface.

SPI is capable of going a good 20x faster but needs more work at the control end.

UART or SPI are easy at the FPGA end.

With only 1024 pixels you data rates won't be too demanding  - 50 frames per second would work on a 115200 baud UART connection.

MK

Ohh sorry

I got it wrong. If you want to load an image like a picture, I think you can use I2C EEPROM. If you will show a frame, you can convert an image to a hex file and then upload to EEPROM. It is tiny but I think it may be enough to fit something for LED matrix.

Mehmet