Getting started with FPGA

[hamster_nz]

Find a friend/buddy/contact/mentor who can program an FPGA to do something, and use the same language that they do.

This is far more important than using the same FPGA vendor or Dev kit as them. Get an entry-level Dev kit, or the one that will let you do the project you are interested in (be that audio, video, robotics, power electronics, networking, CPU design...) -

If your friend is very experienced it might even be better to do pick a different FPGA vendor and/or Dev board. That way your friend will find your projects more interesting, as you will both be learning new stuff.

[rstofer]

Get an LED to blink.  This is the "Hello World!" program for FPGAs.

A lot of things have to work for the LED to blink.  The toolchain needs to be installed, the toolchain has to recognize and program the board, the pin configuration has to be correct for both the Clock input and the LED output and, finally, the program needs to be correct.  This is really the most difficult step.  Just getting SOMETHING to work.

You can fool around with some combinatorial logic.  Use switch inputs and LED outputs.  Then move up to a simple state machine.  Advance the state based on a switch input for the clock.  You need to build a component to make a one-shot out of the switch input.  Base the FSA on defined constants for the state numbers - like 0, 1, 2, 3...  Then send the std_logic_vector equivalent of the state number to some output pins.  Hang some LEDs out there and watch the state machine run.  Obviously, you will want some other inputs to make the state machine dance.

Once you get a state machine running, you are on your way.  Everything else is just details.

[Sal Ammoniac]

I find a lot of VHDL examples use an extremely long winded way of writing and they could easely be replaced with something shorter and scalable as a bonus. Sure if you need speed then go bare metal but it is similar to C versus assembly. 99% of the FPGA designs don't need speed. Overall I have the feeling a lot of FPGA designers are still in the 'assembler' stage and not confident enough to let the synthesizer do the work for them.

I agree. Lots of people tend to over complicate simple tasks.

Here's an example of a very tightly written (by Niklaus Wirth) UART receiver.

Code: [Select]

`timescale 1ns / 1ps  // NW 4.5.09 / 15.8.10 / 15.11.10

// RS232 receiver for 19200 bps, 8 bit data
// clock is 25 MHz; 25000 / 1302 = 19.2 KHz
// clock is 35 MHz; 35000 / 1823 = 19.2 KHz

module RS232R(
    input clk, rst,
    input done,   // "byte has been read"
    input RxD,
    output rdy,
    output [7:0] data);

wire endtick, midtick;
reg run, stat;
reg [11:0] tick;
reg [3:0] bitcnt;
reg [7:0] shreg;

assign endtick = tick == 1302;
assign midtick = tick == 651;
assign endbit = bitcnt == 8;
assign data = shreg;
assign rdy = stat;

always @ (posedge clk) begin
  run <= (~RxD) ? 1 : (~rst | endtick & endbit) ? 0 : run;
  tick <= (run & ~endtick) ? tick + 1 : 0;
  bitcnt <= (endtick & ~endbit) ? bitcnt + 1 :
    (endtick & endbit) ? 0 : bitcnt;
  shreg <= midtick ? {RxD, shreg[7:1]} : shreg;
  stat <= (endtick & endbit) ? 1 : (~rst | done) ? 0 : stat;
end
endmodule


[hamster_nz]

I agree. Lots of people tend to over complicate simple tasks.

It is only when you fully understand the problem you are solving, and you have tried solving it from a few different perspectives the "obvious" and "simple" becomes apparent.

It is next to impossible that a beginner writing a UART would stumble onto a nice solution, as there are too many complicating issues that are distractions. For this example...
- start bits
- stop bits
- baud rate errors
- framing errors
- line noise
- detecting the start of bits
- synchronizing of RxD - is it actually needed in this case? (yes, because 'run' could go metastable otherwise)
- resets - why does 'tick' and 'shreg' not get reset by 'rst'?
- clock rates
- bit clock vs system clocks
- supporting different baud rates
- implementing by oversampling, like micros do.
- Order of bits on the wire
- software / hardware flow control
- subtle timing issues
- keeping track of signal edges vs signal levels - edges hold the timing info (i.e. when to capture bits), but the signal levels hold the data bits.
- size (in bits) of 'tick', 'bitcount' and 'shreg' required to hold the range of counter values - e.g. running on a 100MHz clock this would break because 'tick' is too small.

These all these have to be discovered and thought about, hence the ugly FSM with a huge number of states, assigning individual bits and checking everything. It isn't really surprising that beginners write terrible UARTs, in any language. The 10th UART you write will be 10x better than the first, but only 0.1x as satisfying.

I am pretty sure that a less complex, more understandable UART could be written (in any HDL language) that that one. shifting into a shift register and detecting the start bit, avoiding all the complexity of things like "run <= (~RxD) ? 1 : (~rst | endtick & endbit) ? 0 : run;".

It isn't a language thing, it is the design that you are trying to express that makes the biggest difference, and that is mostly shaped by how familiar you are with the problem, and not the HDL being used. Switching language won't help this much.