Good intros to FPGAs?

[rstofer]

But, just like Arduino, your first project is to get an LED blinking.  Then you move on to designing simple, then more complex, CPUs and systems.  But first the blinking LED.

Once you have selected a board, which implies a chip manufacturer and a specific toolchain, post back and somebody can help with 'blinky'.

Realistically, there are only a few constructs to learn.  You just manipulate the basic structure to fit the application.  Getting the FSM (Finite State Machine) working is probably the most complex and I'm going to recommend a 2 process design.  You can research 1, 2 or 3 process FSMs.

https://vhdlwhiz.com/n-process-state-machine/

At the NandLand site, there are a number of tutorials for the GO board.  Including a blinking LED:

https://nandland.com/your-first-vhdl-program-an-led-blinker/
https://nandland.com/go-board-tutorials/

[free_electron]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

that's what state machines are for. create counter ,load counter, wait for counter to reach zero then next state

[pcprogrammer]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

[Someone]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot. For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
I use them pretty regularly for all sorts of functions that other people would/could/did write out as repetitive verbose error prone structures. The only difference is that the are always parallel/concurrent evaluations of the loop, no possibility of putting a wait inside there for synthesis yet delays inside for loops are pretty routine for simulation (where until and always loops are very common).

[emece67]

.

[tggzzz]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot. For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
I use them pretty regularly for all sorts of functions that other people would/could/did write out as repetitive verbose error prone structures. The only difference is that the are always parallel/concurrent evaluations of the loop, no possibility of putting a wait inside there for synthesis yet delays inside for loops are pretty routine for simulation (where until and always loops are very common).

The context is discussing why experience with C is not helpful when creating FPGAs in an HDL.

Your reference correctly states "For loops do not behave the same way in hardware as in software."

In C it is quite reasonable to write "for ( i=0, i<32768, i++) {...something complex...}". Not so much in an FPGA!

[tinker357]

Hi,
This is my first post so please be gentle.

Keep in mind that:
- FPGA is not software.  You do not write "programs" for FPGA, you write schematic, with flip-flops and logic gates and so on, except you'll use text to describe the schematic, instead of drawing lines like you do with other electronic schematics.

- you'll need to know/learn digital design, meaning logic gates, flip-flops, multiplexers, counters, state machines, Mealy Moore state machines, synchronous design techniques (e.g. clock domain crossing, metastability, etc.) and so on.  It's not software, it's hardware.  It's all digital schematics written in text, and called HDL (Hardware Design Language).  For example, Quartus still retains a graphic editor, where you draw flip-flops, and logic gates, and circuits from the 400 TTL family to design your schematic instead of describing your schematic wit VHDL or Verilog "code".

For my first meaningful FPGA program, I chose to add more functionality to an open source oscilloscope project.  Being a long-time firmware programmer, I am used to programming in C, and toggling GPIOs and viewing on a logic analyzer to debug.

I needed to do the following, which I could figure out how to do like a programmer, but I had no idea of how this could be done writing a schematic:
  Use 1 to 10 4K BRAMs, (which allows up to 8KB samples if using 4 channels, or 40KB if using one channel.
  Turn the BRAMs on and off at the appropriate time, and from experiments it seemed I had to turn on the BRAM one clock cycle before I actually wanted to store to it.
  If doing peak detect, use two BRAMs per channel, one for high voltage, and one for low voltage.
  If doing hi-res, average multiple samples per interval.

In addition, since I was acquiring samples at 100 MHz, looking for trigger, storing samples to BRAM each cycle, and then sending all the data out over a serial port, it seemed much easier to use GPIO toggles to debug rather than figure out how to create a simulation to do all this.  Also, most of my bugs seemed to occur when I was switching from one BRAM to another, or the samples to store before the trigger occurred in a different BRAM in the linked list of BRAMs.

Since verilog looks so much like C, I just relied on the compiler to turn it into hardware, which seemed to work fine in most cases.  The only real problem I had was that it seemed that when I saved the offset and BRAM number of when the trigger occurred, sometimes  it did not get saved correctly, but when I added a GPIO toggle when this occurred, it worked (kind of like it was getting optimized out).  I tried looking at the netlist RTL viewer, but it is gigantic and hard for me to follow.

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
 

[agehall]

There are numerous things you need to be aware of and that will trap you if you think like a programmer.

First of all, assignments may not happen instantly. This is a big thing and can cause a ton of issues.

Secondly, you always have to remember that you are building hardware, not writing a program even though you are programming. This implies things like having true concurrency in many cases which can work for or against you.

Again, I think having a C/C++ background can be very helpful, as long as one understands that it is hardware you are building with your code. Don’t do things like a huge for-loop as there is no such thing in hardware. State machines are your best friend and don’t be afraid of using them.

Again, we all have different ways of learning and how we relate to old knowledge. For me, C/C++ translates very well into SystemVerilog and some patterns come in handy. For a less experienced programmer and/or someone without experience in building hardware logic circuits this may not be true.

[RoGeorge]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

So bad?  I didn't say it's good or bad, I wrote it's different, and told the main differences.  Hardware and software are not the same, and sometimes this difference matters.

Now about the notions of bad vs good (because you seem preoccupied if the method you used was bad).  Good and bad only make sense in regards to a given goal.  There is no such thing as absolute good or evil.

If the goal was to read the datastream (and the tools were able to hide the differences between software and hardware), that's very well.  Nothing wrong to achieve a goal faster, or easier.  Well done with your proj, by the way.   

There are even easier ways to make use of an FPGA, for example National Instruments' LabView FPGA is all graphic, will let one drag and drop blocks and do the most amazing things with an FPGA, without the need to write a single line of code.

However, if the goal is to learn about FPGA, then refusing to take into account the differences between how synthetizable HDL works vs how a software programming language works will be bad.  And also technically incorrect.

[pcprogrammer]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

[rstofer]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

Because a software programmer is generally looking at a single line of code being executed and then the next line, etc.  Clearly, threads expand this view but not all that much.

HDL programmers understand that thousands of lines of code are executing concurrently.  Consider:

Code: [Select]

ACC_Zero <= '1' when ACC = "0000000000000000" else '0';This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff.  It just sets up a signal to indicate the accumulator is zero.  I never look back at that code while I consider how my FSMs deal with it.  It exists, it is guaranteed to be available under all conditions and anywhere I want to use it.  I can pass it as an input to other components, whatever.  It simply exists and is constantly evaluated.  If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it.  It just happens because it is nothing more than a really wide NOR gate following synthesis.

The thought process changes substantially between hardware and software.

[pcprogrammer]

...(I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
 

Using the same master clock edge and non blocking assignments are proper things to use, but to assume that timing is not an issue is wrong. When looking at it from a hardware standpoint one has to think about propagation delay, setup and hold times, clock skew and many more aspects that come into play.

It all depends on how the logic is placed in the FPGA what the delay's between logic blocks, memory blocks, interconnects, etc are going to be. By telling your FPGA tools what the timing constraints on your clock and signals are it can take this in account and try to optimize the placing and routing.

Think of the FPGA as an array of dedicated TTL ic's with a big routing matrix between the pins. A signal that has to go through a block at the lower left corner and then through the interconnect up to a block on the upper right corner will take its time. This limits the maximum frequency a design can run at. The same applies to the clock signal. Even though there are special clock routes through the FPGA there can still be a delay in the rising of the signal at one end of the trace to the other end of the trace.

In programming a processor this is not an issue because, to state it simple and bluntly, every instruction has a fixed duration and everything is done sequential.

[agehall]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

Because a software programmer is generally looking at a single line of code being executed and then the next line, etc.  Clearly, threads expand this view but not all that much.

HDL programmers understand that thousands of lines of code are executing concurrently.  Consider:

Code: [Select]

ACC_Zero <= '1' when ACC = "0000000000000000" else '0';This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff.  It just sets up a signal to indicate the accumulator is zero.  I never look back at that code while I consider how my FSMs deal with it.  It exists, it is guaranteed to be available under all conditions and anywhere I want to use it.  I can pass it as an input to other components, whatever.  It simply exists and is constantly evaluated.  If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it.  It just happens because it is nothing more than a really wide NOR gate following synthesis.

The thought process changes substantially between hardware and software.

And to add to that - you could add that statement anywhere in source file. The fact that everything is evaluated concurrently is something that can throw a traditional programmer off quite a bit as they are normally used to read code sequentially while in HDL, you need to consider what happens at every signal change.

[Someone]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

[tggzzz]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

[Someone]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

Your short one liner makes a broad and misleading generalization. There are loops, they are almost exactly the same as C. Understanding the difference between synthesizable and non-synthesizable constructs/features is the underlying matter. You're just as wrong as the people who try and make generalizations about resets.

VHDL/Verilog can be used as high level languages, but there isnt a readily available or open source library ready to go as the OP specifically asks about (in reference to Audrino). At which point pretty much every single thing you said is incorrect:

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

[tggzzz]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

Your short one liner makes a broad and misleading generalization. There are loops, they are almost exactly the same as C. Understanding the difference between synthesizable and non-synthesizable constructs/features is the underlying matter. You're just as wrong as the people who try and make generalizations about resets.

Loops might be used when testing FPGAs, but that is outside FPGAs.

Of course there are loops in HDLs. But if they aren't synthesisable they aren't in FPGAs.

If loops are synthesisable, then their semantics are very different to those in C.

VHDL/Verilog can be used as high level languages, but there isnt a readily available or open source library ready to go as the OP specifically asks about (in reference to Audrino). At which point pretty much every single thing you said is incorrect:

HDLs and C are Turing Complete, so of course they are equivalent. But the abstractions are very different.

While you could write a transaction processing system in Prolog or an HDL, doing so would be (at best) only of academic interest.

Understand the abstractions and what they are not suitable for. That's bog standard engineering: use the right tool for the job, and don't resort to imaginative hillbilly constructions.

Whether or not a "library" (to use your word) is or isn't open source is irrelevant. The FPGA equivalent of a library is the hardware building blocks (sometimes called IP blocks) provided by the device manufacturer

[Someone]

Whether or not a "library" (to use your word) is or isn't open source is irrelevant.

That's what the OP asked about... hence the replies discussing that rather than your pet flavour point.

Of course there are loops in HDLs. But if they aren't synthesisable they aren't in FPGAs.

If loops are synthesisable, then their semantics are very different to those in C.

Its the wall of text needed to clairify that possible corner case which you omit that is the problem. Loops do exist in HDL, they are synthesiable, and do the same job as in C....   iterating over a section of code in a controllable way. The significant difference that everyone keeps pointing to in the thread is that the majority of HDL code (there are examples/structures that do not have this characteristic) is executed in parallel, which is not something specific to loops but applies to almost all aspects of HDL coding.

Can you have a syntheisable loop with a wait statement inside to blink an LED? no, but that's true of any HDL structure. Yet you only talk about loops as if they are somehow treated differently.

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

[pcprogrammer]

The main key here is semantics.

This line explains it.

For loops in synthesizable code are used to expand replicated logic.

It is not the for loop itself that is synthesized. It is the logic in it that is implemented repeatedly.

As a programmer who originated from being trained as a hardware engineer, I also choose verilog to start with doing FPGA again, just because it looks a lot like C. The truth is I had to free myself of the programmers way of looking at things, even though I have used FPGA in the past. The difference is that I, at that time used schematics to implement the FPGA and with that you are in a "hardware" mode and not a "programmers" mode.

I think that before starting with FPGA's and HDL's it is better to first learn a bit about digital hardware in the gates and flip-flops sense. This way you also get familiar with things like propagation delay and setup and hold times.

Assuming that when you know how to program and understand a bit about micro processors and some electronics that it is easy to move on to FPGA's is very wrong.

[Someone]

For loops in synthesizable code are used to expand replicated logic.

It is not the for loop itself that is synthesized. It is the logic in it that is implemented repeatedly.

that may be an overly narrow view of loops, since "replicated" isn't always the result of a loop, and you can have loops in functions or with blocking assignments that work even more like sequential instructions in C. A loop is a programming construct that can be used for all sorts of different purposes, in HDL its often used to express things which would be awkward or verbose in other ways.

One common example:
https://stackoverflow.com/questions/14113125/short-way-to-write-vhdl-priority-encoder
which could be written in HDL or C, and a common solution in the other direction:
https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObvious
Equally could be implemented in HDL or C.

So there are real uses of loops, being able to be directly translated between C and synthesiable HDL (in either direction) with no functional difference. Implementation/efficiency differences, but still using loops to solve the problem.

[pcprogrammer]

The priority encoder is a nice example.

Wat one has to understand as a difference between it running on a processor or a FPGA is that on the processor it is a sequential evaluation of the if statements and takes the given number of loops to come to the result, where as, if I'm not mistaken, in the FPGA it happens "instantaneous" meaning all the if's are evaluated concurrently.

The HDL compiler will translate it into a bunch of "gates" to evaluate the signals.

Or am I totally wrong here?

[Someone]

Wat one has to understand as a difference between it running on a processor or a FPGA is that on the processor it is a sequential evaluation of the if statements and takes the given number of loops to come to the result, where as, if I'm not mistaken, in the FPGA it happens "instantaneous" meaning all the if's are evaluated concurrently.

That's true if the ifs/loops contain only combinatorial non-blocking assignments. Throw in blocking assignments, or sensitivity/registers and it gets more complicated (before talking about delays in simulation, or generate for loops). Loops and functions with blocking assignments can read and function just like C, the choice is there for the coder to pick what they think is best. Most people would agree a loop is much better than those repeated ifs in the priority encoder example, even though they will synthesize to the same structure.

[RoGeorge]

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

I see it different.

Here's a quote from the link you posted:

For loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.

To make an analogy, that type of "for" loops are rather like the preprocessor directives for C (if it were to make a parallel with C).  I wouldn't say C has an "#include" or a "#define" keyword.  Those directives are for the preprocessor, not for the C compiler.

I'm thinking about a "for" in a HDL in a similar way I'm thinking about a macro in C.  Except in HDL the "macro" is usually written in the same HDL language as the synthetisable HDL parts, while a C macro uses different keywords than C.

I wouldn't say a macro in C is to be compiled, I'll say is to be expanded/transformed into more C code, then compiled.  Same with the "for" loops in HDL.  Those are not turned directly into gates and flip-flops.  Those "for" loops are expanded (unrolled) into more HDL source code, and only after that the HDL is synthesised into interconnections between gates and flip-flops in the FPGA, just like a C macro after expansion would be turned into more C code then eventually compiled into executable binaries.

If one uses C macros as if it were C code, that will get unpredictable results, or compiling errors.  Same in HDL with the "for" loops, which should be considered rather a macro for HDL, and not like synthetizable code.

As long as one notices the difference between C macros vs C code, and uses them properly, I don't care if one insists to say a macro in C is eventually compilable code.  Well, one might say that, but that looks twisted to me.

I'll say a C macro is not compilable code, same as a "for" loop is not synthetizable HDL.

[Someone]

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

You misunderstood.  That's a quote from the link you posted:

For loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.

To make an analogy, that type of "for" loops are rather like the preprocessor directives for C (if it were to make a parallel with C).  I wouldn't say C has an "#include" or a "#define" keyword.  Those directives are for the preprocessor, not for the C compiler.

I'm thinking about a "for" in a HDL in a similar way I'm thinking about a macro in C.  Except in HDL the macro is usually in the same HDL language as the synthetisable HDL parts.

I wouldn't say a macro in C is to be compiled, I'll say is to be expanded/transformed into more C code, then compiled.  Same with the "for" loops in HDL.  Those are not turned directly into gates and flip-flops.  Those "for" loops are expanded (unrolled) into more HDL source code, and only after that the HDL is synthesised into interconnections between gates and flip-flops in the FPGA, just like a macro would be in C.

If one uses C macros as if it were C code, that will get unpredictable results, or compiling errors.  Same in HDL with the "for" loops, which should be considered rather a macro for HDL, and not like synthetizable code.

You're only just considering a subset of the uses of a loop in HDL (and making plainly false generalised statements). Synthesiable loops can have variable numbers of iterations and make complex control structures, just because you haven't seen it or used it doesn't mean they don't exist. Its not just a trivial roll/unroll operation. That article gives some replication examples, but that is not the entirety of HDL loops.

The quote above is to start pointing out that tggzzz (who's quote you removed from the nesting so the text above is out of context) is factually wrong that loops are not sythesizable. Are we past that point yet? Once you see that loops are synthesizable, they can be used for all sorts of things, replication is just one of those applications. You want to write fancy algorithms with loops that modify the loop variable? HDL will do that with some futzing, but "simple" loops are just like C.

Or is this some bizarre pile on from a bunch of people who don't actually use or write HDL?

[sicco]

For me, Icestudio and Icebreaker (ice40) were what Arduino is for microcontrollers: cheap, open, easy & free. Up and running, blinking the first LED, in less than an hour.

https://github.com/FPGAwars/icestudio/wiki

I disagree with the suggestion that it takes weeks or months to get going.
It is work in progress, targeted at education / hobby use, just like Arduino, has a sizeable and growing community, and it has improved a lot in recent years. I have now removed the Lattice tools from my PC: too heavy, too much license hassle.
With Icestudio, you first graphically draw (=wire) circuits as gates, counters, flipflips and only later on you get persuaded to write verilog code. And only after that’s under the belt, you start peeking inside huge libraries (collections) and learn how to wire in dual port ram, spi, i2c, the pll, dsp mac blocks and so on.