Resources for learning FPGA

[aheid]

Hi,

Got myself interested in FPGAs, and picked up an iCE40 UltraPlus devboard. Got Radiant installed and been blinking my first LED, so far so good. I've been programming for 20+ years in various languages, and done a lot of heavy multithreaded code, so I feel comfortable with the idea that a lot of things are happening at once and the potential pitfalls that comes with that.

But, I'm new to Verilog, and could really do with a good online reference, as well as some sites describing the fundamentals which I can come back to.

For example, I mostly get the difference between a "register" and "wire", but yesterday I got confused as to why I couldn't use a register as output from a module, but had to use wire. I also didn't get why I couldn't cast a 32bit result to 24bit by simply slicing it or similar (ie "counter <= (counter + 1)[23:0]). So I clearly need to learn a bit more about the basic syntax, as well as get a firmer understanding of the various concepts.

I searched these forums and found https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-111-introductory-digital-systems-laboratory-spring-2006/ which looks good, but presentations can be a bit too distilled at times so I'd like something a bit more comprehensive to augment it.

I'm also interested in typical idioms, as well as things to avoid etc.

Anyone got some nice links handy?

[rstofer]

Google for 'verilog tutorial', they're all over the place.
I bought a book 'Verilog by Example' by Readler.  It's a place to start.

I use VHDL so I can't say very much about Verilog.  One day I will do a complete project using Verilog.  One day...

[aheid]

Yeah been trying but the issue is more information overload as there are just so many, so was looking for some suggestions for good ones. I'm not new to programming etc, "just" FPGA.

Stumbled over https://www.chipverify.com/verilog/verilog-introduction just now, looks good so far.

How did you find the book?

[rstofer]

I'm not really sure what to think of the book.  It has a lot of information but it doesn't seem to grab my interest but that's probably just me.  I have a hate-hate relationship with Verilog so I just don't put enough effort into learning it.  I keep telling myself I should learn it but when I compare it to VHDL, I find I prefer VHDL.  VHDL is like Pascal (which I love) and Verilog is like C (which I use).  One is elegant, the other gets the job done.  All of the ambivalence is my fault.  Verilog has been around a long time and will continue well into the future unless it is overtaken by System Verilog.  We'll see...

I could only see the Index of your linked site (unless I turn off my Ad Blocker) but it looks to be very complete.  It seems like a very good place to start.

And then comes Test Benches.  In the early years of my adventures with FPGAs, Xilinx didn't offer a free simulator so I never learned to use one.  Skipped the whole process and went straight to synthesis.  I'm still not convinced that simulation isn't more time consuming than just implementing the logic but, again, that's me and my projects.  So, I decided to learn about test benches in a rather expansive fashion.  It is VHDL specific and it costs money but this program is terrific: https://vhdlwhiz.teachable.com/p/dot-matrix

The test bench education was worth every dime.  The project itself is fairly trivial but I did learn different ways to code certain aspects.  My way would have worked, the author's way is probably better.  The test benches are truly educational.  I have never viewed education as 'free' so I didn't mind paying a bit for the course.

Just for giggles, I'm going to work through the DUAL 7-SEGMENT DISPLAY FPGA CONTROLLER course - see www.vhdlwhiz.com  I already know the parts, I already have the toolchain installed, as soon as I get my Digilent order, I'm off and running - $17 for the course.  About what we spend on a trip to Taco Bell for the two of us.

[rstofer]

I turned off my Ad Blocker and started looking through a few of the topics.  Be aware, there are typos in to code:  rsnt versus rstn in at least two topics.  I usually expect code to actually work as written but I understand how typos come about.  I make them all the time.

I browsed through the material without spending much time but I don't learn well from the approach.  It's a reference manual, not a tutorial.  Again, it's just me but I need a 'project'.  I'll search the material to find answers to questions about my project but I just don't pay attention to long presentations of topics that aren't directly in support of a project.  I want a tutorial to go somewhere.  I don't necessarily care where as in the case of the Dot Matrix project but it has to lead to something tangible.

My first FPGA project was blinking an LED, my second was adding a Compact Flash drive to the T80 Core (opencores.org) and bringing up CP/M 2.2 on the Z80 core.  Lots of work in that project but it kept my interest.  I never did mess around with the internals of the T80 core but I did play with the IO bus and the control signals.  Learned a lot!  You absolutely must terminate the NMI pin.

My third project was a complete emulation of the IBM 1130 minicomputer.  Card Reader, Printer, Typewriter, Keyboard, Disc, CPU and Plotter.  It runs the factory software unchanged including the 27 pass FORTRAN compiler.  I had a worthy project so I learned enough VHDL to get it done.  It's not always pretty but it works.  This is the way I learn!  Jump in and make mistakes.

Find a project and learn enough to build it.  If nothing else, research all you can find on the LC3 RISC CPU.  It is used in many universities as a design course.  It's a simple processor that the authors create using a microcode approach.  That's an interesting approach for an FPGA where we would tend to use a huge finite state machine.  I like microcode!  I didn't use it but I like it.  In any event, the state diagram is given as is the hardware block diagram.  It is sufficient.  There's a book: "Introduction To Computing Systems" by Patt and Patel.  The complete project includes an assembler.  By the time you finish this project, you will know a LOT about Verilog.  And computer design...

Given the book and all the reference material on the Internet, it is not a project too far to reach.  It'll take some time but if you create a lot of modules and tie them together, it will all work out.

[aheid]

Thanks a lot for the info, highly appreciated.

Since I'm brand new I haven't really spent much thought on Verilog vs VHDL. The examples I started with were Verilog. I've spent most of my life programming Pascal dialects, but most of the rest reading and writing C/C++, I love and dislike aspects of both. I taught myself programming using F1 in QBasic, so I guess that's why I'm used to learning from reference manuals and such. But sometimes it's nice to get a higher view.

I've got a few projects I'd like to complete, nothing overly ambitious I think, but taking an existing core and adding something to it sounds interesting.

[RoGeorge]

I've been programming for 20+ years in various languages, and done a lot of heavy multithreaded code, so I feel comfortable with the idea that a lot of things are happening at once and the potential pitfalls that comes with that.

That's the problem, you need to drop the programming language approach.
Verilog is a different thing, concepts from programming does not apply much to HDL.

HDLs (as VHDL, Verilog) are NOT programming languages, in the sense that HDLs do not describe an algorithm.  They describe a schematic diagram, a machine.  It is just a coincidence that the HDL schematics (the HDL text sources) reminds about programming languages (the programing code sources).  The only resemblance is they are both text, written one line after another, and that's it.

Keep that distinction in mind:
- programing languages are for describing algorithms
- HDL languages are for describing schematic diagrams of digital circuits (as in wires, registers, multiplexers, look up tables, logic gates, flip-flops, etc).

Programing code is executed secvential, HDL code is not executed at all, and certainly is not secvential.  HDL describes a schematic.

On short, HDLs are not programming languages, HDLs are schematic languages.
- HDLs are to describe a digital hardware, a machine
- programming languages are to describe the software running on a hardware machine

[rstofer]

VHDL is a STRONGLY typed language, conceptually similar to Pascal.  Verilog is a little more loosey-goosey, somewhat like C.  Even so, VHDL supports the concept of cast so I can declare a standard logic vector (a simple vector of bits), cast it to unsigned, add 1 and cast it back to standard logic vector.  Or I could have just declared the signal to be unsigned in the first place.  But the point is that the coder has to get the types straight and prove to the compiler that they know what they are doing.  Whether that is a good idea is central to the difference between VHDL and Verilog.

Remember, we are designing hardware and all these casts disappear.  They don't change the resulting hardware in any way, they are just proof that the coder knows what they are doing.

I don't know what you have for FPGA resources but it you can afford a $17 tuition, a $25 prototype board, a $7 display plus a couple of cables, why not follow the VHDL tutorial at VHDLWhiz.com   https://academy.vhdlwhiz.com/fast-track  Save on shipping by checking inventory at DigiKey first.  Truth told, I have no idea how to get parts where you are!

I like the author's tutorials because they lead somewhere and the presentations are very professional.  I also like that he is kicking back in Thailand but that's a separate matter.  FWIW, the author is from Norway!

BTW, there is a lot of free VHDL stuff on that site: https://vhdlwhiz.com/

[mark03]

I am still a rank beginner, so you should take this with a big grain of salt.  I found Verilog quite confusing and VHDL annoyingly bloated.  (It was not the strong typing per se that bothered me.  It just feels like the cultural equivalent, in the HDL world, of writing software in FORTRAN.)  I recently found Stuart Sutherland's new-ish book on SystemVerilog,

https://sutherland-hdl.com/books_and_guides.html#RTL%20Book

and this stuff is making a lot more sense to me now.  If you are headed down the Verilog route, I would strongly recommend getting a book like this and learning SystemVerilog from the beginning, because most of the new constructs relevant to synthesis are now supported in tools like Vivado and Quartus (not sure about Radiant).  It will encourage HDL "goodthink" which, as I understand it, has been a big part of the anti-Verilog critique from the VHDL folks.

Now if I could just find a user-friendly introduction to the art of writing constraints, timing analysis, etc.!

[Yansi]

I'd suggest this book:

[RoGeorge]

(It was not the strong typing per se that bothered me.  It just feels like the cultural equivalent, in the HDL world, of writing software in FORTRAN.)

One does not write software in HDL, one can only draw a digital circuit with HDL.   

[emece67]

.

[emece67]

.

[RoGeorge]

Please don't tell HDLs are Turing complete, so technically they can be considered programming languages.  Yes, they are, but this is not the point.  This is not the point when learning them for the first time, especially when switching from software design to digital design.  It will only add confusion.

Writing testbenches is another story, but first comes the synthetizable code.  If we think about HDL as a schematic, it would be easy to understand this kind of problems:

For example, I mostly get the difference between a "register" and "wire", but yesterday I got confused as to why I couldn't use a register as output from a module, but had to use wire. I also didn't get why I couldn't cast a 32bit result to 24bit by simply slicing it or similar (ie "counter <= (counter + 1)[23:0]). So I clearly need to learn a bit more about the basic syntax, as well as get a firmer understanding of the various concepts.

Later, we can always switch back to programming language thinking, when necessary.

[rstofer]

The thing about HDL is that you are using templates, in effect.  Once you know how to code a MUX, an array of registers, an ALU and a Finite State Machine, you are pretty much all set (I'm going to ignore DSP).  The next MUX looks a lot like the last one - more or less inputs, narrower or wider but the select signal has the same effect.  How many ways are there to build a register?  The big task for the compiler is to take your written description of the hardware and interpret it in such a way as to use standard blocks that can be implemented in one or more LUTs.  The compiler can pull a MUX out of an IF-THEN-ELSIF-ELSE statement.  It knows how to convert the written statements to hardware.  Of course, the designer has to be thinking in terms of these basic building blocks when they write the code.  It helps to give the compiler a hint.

Look at page 35 here:  http://www.cs.utexas.edu/users/fussell/cs310h/lectures/Lecture_10-310h.pdf

What you see is a RISC CPU built up from Muxen (I invented that word, not knowing the plural of MUX), registers, adders and a FSM.  Nothing magic.  Make each block a process or module and wire them together.

Look at the MARMUX in the upper left corner.  It has 2 inputs each 16 bits wide.  It chooses to send either the result of some address generation or an extended field of the Instruction Register to the Memory Address Bus.  So write a module that describes just this piece and call it, oh I guess, MARMUX,  Worry about wiring it up later.

Look at PCMUX - same drill but 3 inputs all 16 bits wide - call the module PCMUX and it's done!


The REG FILE is a little tricky.  It has 2 banks of 8 registers (a 2 dimensional array of standard logic vector) each register is 16 bits wide.  Here's the trick:  both parallel registers are written at the same time independent of which registers are being read.  Note that we have two outputs, SR1OUT and SR2OUT, we have two 3-bit selectors and only one 3 bit DR selector - the destination register.

The FSM has a maximum of 64 states but only 58 are implemented in the microcode.  Here is the state diagram:  https://hkn.illinois.edu/wiki/wiki:architecture:lc-3_instruction_processing

Page 584 in this document has the microcode worksheet.  It is missing one column:  http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdf

Note that all 3 documents come from a different university.  This is quite a popular project!

[james_s]

Honestly I think programming experience is more of a liability than an asset when you are learning HDL. HDL *looks* like a programming language but in reality it is describing hardware.

People often say "everything executes in parallel" but this is not entirely accurate. Nothing is "executing", the circuit is defined and then all of the parts operate at once. This is obvious if you think of it as wiring up several ICs on a board, of course the ICs will all operate at once, they're all wired up on the board and once you wire up an IC it will do whatever it is that it does for as long as power is applied, putting more ICs next to it is not going to affect it.

Keep reminding yourself that you are not writing a program, you are describing hardware, getting used to that mindset was difficult for me. It is further complicated by the fact that you can describe the same circuit using various abstraction levels, behavioral modeling is starting to really look like a program, but it's still describing hardware.

[rstofer]

The smaller the module, the more it looks like a chip.  The big FSM is usually the exception.  That’s the trade off of HDL logic versus a more obscure chunk of microcode.  I like microcode, it is more compact than the typical FSM, but only when I have a meta-assembler.  And I don’t have one!

[mark03]

It was not the strong typing per se that bothered me.  It just feels like the cultural equivalent, in the HDL world, of writing software in FORTRAN.

One does not write software in HDL, one can only draw a digital circuit with HDL.   

In fact I've wrote software in VHDL many times and "draw" circuits with it much less times. Also, I think that many HDL synthesizable models are far from being compararable to schematics.

I didn't mean to suggest any commonality whatsoever!  I was making an analogy:

VHDL is to Verilog    in the HDL world as
FORTRAN is to ____   in the software world   (probably C)

The OP specifically mentioned "wire" vs "register" confusion which I also had (past tense may not be fully accurate .  SystemVerilog is much better in this regard.  If you're going to learn Verilog from scratch, try to get a SystemVerilog text and learn it the right way, so you don't have to unlearn stuff later.

[mark03]

PS  folks piling on to say how you need to get out of the programming mindset, and remember that you are wiring circuits, is almost cliche in these threads.  It is true, but most new students figure that out pretty quick.  For me, the hardest part of "getting past blinky" is all of the stuff they *don't* cover in a text on VHDL/Verilog for synthesis.  How to write constraints, how to know when to instantiate vendor-specific blocks vs trusting the synthesizer to do it for you, how to decompose complex tasks---especially DSP stuff.

IMO the vendors could do a better job at providing gentle on-ramps to this sort of thing, but I think they are incentivized to push their fancy HLS tools instead.  So for questions like "What are all of the ways I can code a FIR filter in HDL?" there is a real dearth of practical information, and the best introductions are often really old app notes from the vendors, before they started telling you to "just use the filter wizard."

[rstofer]

In VHDL, you don’t have to worry about reg versus wire.  They are all ‘signals’

[RoGeorge]

For me, the hardest part of "getting past blinky" is all of the stuff they *don't* cover in a text on VHDL/Verilog for synthesis.  How to write constraints, how to know when to instantiate vendor-specific blocks vs trusting the synthesizer to do it for you, how to decompose complex tasks---especially DSP stuff.

What you are missing is "digital design".

The study of digital design is for hardware what the the study of computer algorithms is for software.

[aheid]

I think I have a fairly ok mental model, I guess it's just the syntax and abstractions of HDL that trips me up. Like yeah it's all wires and circuits, but why then doesn't the slicing work? If I have a breadboard with an IC that has 8 output pins I can just NOT hook up 3 of them to get 5 output signals.

Or the wire vs reg... I made the module declare an "output reg sig", why couldn't I pass a reg to it when instantiating the module, why did it have to be a wire? For regular code I set a register from another, say x <= ~x for example, without specifying the implicit wiring.

Anyway thanks, I'll have a look at the resources suggested.

[RoGeorge]

I think I have a fairly ok mental model, I guess it's just the syntax and abstractions of HDL that trips me up.

For the last time, the mental model you have is incorrect, and that is what stays in your way, not the syntax.  Just put aside, for a moment, your 20+ years of programming.  Let's take your example.

why I couldn't cast a 32bit result to 24bit by simply slicing it or similar (ie "counter <= (counter + 1)[23:0])

I can only speculate that is a piece of synthetizable HDL, and your intention here is to use only the first 24 bits of a 32 bits counter.  Is that what you want to do?  If yes, then it doesn't make sense if you think of it in terms of circuits.  You had before 32 flip-flops chained as a counter, and now you suddenly want to disconnect the last 8 of them?  What if another signal arrives in the meantime?  How should the counter act, as a 24 or as a 32 bits counter?

If you draw a schematic of 32 chained flip-flops, and think about them in terms of schematic (and not as software) it doesn't make any sense to increment only the first 24 bits.  What should the other 8 bits do?  Should they just sit there, or should they increment?  Maybe they should reset?

Picture them as physically minuscule ICs inside the FPGA.  That's a counter.  It's not data, it's a circuit.

Please put the code of the whole module, so we can discuss it line by line, and make an idea of what is happening under the hood.  It's not like a typecast in programming, but enough metaphors.  Put a simplified version of the whole module, say in words what you expect from it, where it does something else than you expect, and the errors spit by the IDE.


Now if you don't have the time to do that, to stay on topic about links, I'll recommend this for a FPGA 101.  Seems trivially simple, but is also concise, so it can be parsed very fast.  Read even the parts you think you know, and think schematics.

https://www.fpga4fun.com/

That was what helped me when, after decades of programming, I stepped for the first time into FPGAs.

[aheid]

Picture them as physically minuscule ICs inside the FPGA.  That's a counter.  It's not data, it's a circuit.

Well say I got 32 outputs from a bunch of ICs sitting on a breadboard. I want to feed these to a new set of ICs on another breadboard. Why can't I just hook up the 24 wires for the first 24 ouputs, and ignore the last 8 outputs? Alternatively, if I got a 32bit adder as one big IC, why can't I simply ignore the pins representing the upper 8 bits? What's wrong with that?

Please put the code of the whole module, so we can discuss it line by line, and make an idea of what is happening under the hood. 

The module I copied from some sample code, I just modified the name of it and the text file it reads the data from:

Code: [Select]

module ROM_SIN_256(
    input clk,
    input [7:0] addr,
    output reg [7:0] dout
);
    reg [7:0] memory [0:255];

    initial
        $readmemh("sin_256.txt", memory);
   
    // synchronous ROM
    always @(posedge clk)
        dout <= memory[addr];
       
endmodule
In my top.v file I have this:

reg sin_clk;
reg [7:0] sin_addr;
reg [7:0] sin_val;

always @ (posedge oclk)
   /* other code */

   ROM_SIN_256 sin_inst(
      .clk(sin_clk),
      .addr(sin_addr),
      .dout(sin_val)
   );

This leads to: "ERROR - concurrent assignment to a non-net sin_val is not permitted. VERI-1195 [top.v:78]".

If I change the declaration of "sin_val" to

Code: [Select]

wire [7:0] sin_val; I don't get an error. What confused me was that dout is declared as "reg", and since I've not yet studied modules in depth I just have an implicit understanding of the syntax. But I think that has more to do with how Verilog works than how the hardware works.

[aheid]

The reason I wanted to slice off the 24 lower bits, is that the implicit addition circuit produced is apparently 32bit, and so I get a warning that I'm discarding the upper 8 bits. So far I get around that by using a function:

Code: [Select]

reg [23:0] count;

function[23:0] truncate24;
input [31:0] data;
begin
truncate24 = data[23:0];
end
endfunction

always @ (posedge oclk or posedge rst)
begin
if (rst)
begin
count <= 24'd0 ;
end
else
begin
count <= truncate24(count + 1) ;
end
end

Also, thanks again for the responses, much appreciated.