[Fpga-synth] Starting points?

[Magnus Danielson]

Dear Byron,

Byron G. Jacquot skrev:
> Howdy everyone,
> 
> Some of you may recognize my name from SDIY - I've been lurking for
> about a year, hoping to get my feet wet at some point.  That point
> seems to have come - I was just laid off.  Rather than scurrying to
> hunt for a new job, I'm going to learn some new skills - FPGA
> programming being near the top of the list.

Sorry to hear that you lost your job. Learning new skills is indeed a 
good thing to do. Learning and understanding FPGAs is certainly among 
those things I encourage people to do.

> A little bit about my background: I've been a firmware developer for
> 12 years, working very close to the hardware.  I'm good with
> C/C++/assembly, and can read schematics.  My last position involved
> writing device drivers and exercising a batch of FPGA peripherals...
> but the FPGA work was done by another engineer.  I'd like to be able
> to fill that gap myself.

Not a bad background.

> I've got some questions about a starting point.
> 
> I know a while back the Spartan 3E was fairly popular.  Is that
> still the best bet for getting started?

It is a good board. There is always a development and you might find 
something newer which is hotter. But it is not a bad board to play 
around with. I've got two of them now.

> What are the best books?  In C there's K&R, in C++ there's Stroutrup,
> in electronics there are Horowitz & Hill and Pease...what are the
> equivalent books for Verilog & VHDL?

"VHDL for designers" by Stefan Sjoholm and Lennart Lind is the closest I 
come I think. That and the VHDL LRM forms a good foundation IMHO.

> What other good references are there?  Is there a good mailing list, newsgroup, website, etc?

Yes. There is. Google and you will find. IEEE put the standards there, 
and as you find opencores.org, etc. etc. you will find loads of information.

> Any other references, recommendations, etc?

Start of with downloading and installing WebPACK.

Have a look at Peter Ashenden "The VHDL Cookbook":
http://tams-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

The first thing to learn is about the hierarchy of design, being built 
by entity (interface description) and architecture (content inside the 
black box of the entity description). Then learn about processes. VHDL 
being an ADA decendent has typing being HARD. This can be a bit annoying 
for a C programmer like yourself, but eventually you pick up on it.

The comes the process descriptions and the tricky part to learn there is 
what the hell the sensitivity list is and how it affect things, well if 
a signal on the sensitivity list is changed, the sequential part of the 
process code is executed from begin. This is odd for synthesis but makes 
perfectly sense to simulations which VHDL was originally designed for.

Oh, synchronous designs rules and you learn that "latch" and "flip-flip" 
is two distinct things and a sloppy assumption of "latching it in a 
latch" is the same as clocking it into a flip-flip is out the window. 
Latches remains open until closed and can't be used for pipeline designs 
and thus is forbiden. Flip-flops is where you hold your state.

Another beginners mistake is to use tri-state too often. Some but not 
all FPGAs support it and it is tricky to pin-point which driver was 
driving incorrectly when. Designing by muxes is what you should do.

Back to VHDL you can then learn various forms of parallel descriptions 
which can be done in addition to process-descriptions.

Using parameters (called generics) is recommended. You should also learn 
to number your buses downwards:
signal data : std_logic_vector(31 downto 0)
or by using the generic N:
signal data : std_logic_vector(N-1 downto 0)

You will also have to learn to instantiate components. This can be a 
good thing when you know what standard piece you want, or to put your 
own works at some place. Standard components can be instantiated 
indirectly through inference, but sometimes you want that extra control 
signal or configuration aspect and you need to go for direct instantiation.

You will also have to learn to build testbenches. I cannot stress the 
importance of that to aid towards your sucsess. A good testbench 
generates a bunch of signals and confirms the responses from the DUT.
The use of assert with severity error can make you stop as soon as you 
have a fault and bring your attention to that detail. You want that.
Never trust manual verification. I just found a bug I have had creeping 
along after separatly testbenching some small piece of code I did manual 
verification of when designing it. *DARN*

Ah... some random thoughts in the middle of the night, but hopefully a 
start and getting you in somewhat the right direction.

Cheers,
Magnus