Getting started with FPGA

[NivagSwerdna]

Everyone has an opinion on languages, personally I like VHDL and find that it has the best hobbyist support. Verilog is the other big one, which you choose is largely a matter of personal preference. Anything that can be done with one can be done with the other.

I'm planning on looking at both.   I did buy "Digital Design and Computer Architecture: ARM Edition Paperback – 4 Jun 2015
by Sarah Harris (Author),? David Harris (Author)" and am working through that; it's a good book.

[james_s]

When I was starting out the best book I found was a free one called Free Range VHDL. If you do a search online you'll find it.

The Multicomp was another very useful educational project since he provides a bunch of pre-written modules along with a top level file and instructions for putting it all together. That taught me how to assemble existing building blocks of code.

[Mr. Scram]

When I was starting out the best book I found was a free one called Free Range VHDL. If you do a search online you'll find it.

The Multicomp was another very useful educational project since he provides a bunch of pre-written modules along with a top level file and instructions for putting it all together. That taught me how to assemble existing building blocks of code.

Free Range VHDL is free too. Properly free, not just easily downloadable.

[NivagSwerdna]

Thanks.  I will take a look at http://www.gstitt.ece.ufl.edu/courses/eel4712/labs/free_range_vhdl.pdf

[xaxaxa]

I would highly recommend getting a SoC fpga dev board, e.g. de0-nano-soc, because you can do so many fun things with implementing peripherals on the fpga and writing drivers for it. I've implemented video output devices, data streaming devices (for software defined radio), etc. You can also access dram through an AXI bus without the hassle of dealing with controllers or worrying about timings, as that is all configured for you by the bootloader.

For a beginner I would also recommend vhdl instead of verilog, as vhdl is intentionally designed to make it hard to make mistakes (with its strict type system and all that); once you get past the compilation errors your design usually works. With verilog you will be catching your errors on the hardware rather than at compilation time. Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it. Not to mention the simulated behavior often differs from the hardware, e.g. if you use processes the sensitivity list applies during simulation but is ignored in synthesis (and this is considered working as intended!). Learn the logic analyzer tools instead (signaltap for altera, chipscope for xilinx).

[langwadt]

I would highly recommend getting a SoC fpga dev board, e.g. de0-nano-soc, because you can do so many fun things with implementing peripherals on the fpga and writing drivers for it. I've implemented video output devices, data streaming devices (for software defined radio), etc. You can also access dram through an AXI bus without the hassle of dealing with controllers or worrying about timings, as that is all configured for you by the bootloader.

For a beginner I would also recommend vhdl instead of verilog, as vhdl is intentionally designed to make it hard to make mistakes (with its strict type system and all that); once you get past the compilation errors your design usually works. With verilog you will be catching your errors on the hardware rather than at compilation time. Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it. Not to mention the simulated behavior often differs from the hardware, e.g. if you use processes the sensitivity list applies during simulation but is ignored in synthesis (and this is considered working as intended!). Learn the logic analyzer tools instead (signaltap for altera, chipscope for xilinx).

"Don't bother with simulations" you are joking right?

[tggzzz]

There are only a very few constructs you need to learn.  Gates, registers, multiplexers and finite state machines (unless I forgot a couple).  Once you know how to implement these constructs, the rest is just details.

Clock domains, and how to send signals from one clock domain to another.

[ehughes]

Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it

I usually rarely tell people to ignore advice but this is the worst I have seen in awhile.

Serious FPGA and logic development is 95% simulation.         It is the only way to provide coverage over all of your test cases.     Any organization who hires for serious logic development with never hire you if you don't simulate.    It honestly makes you look like the bench warmer on the JV team.

Anyone who doesn't simulate either:

a.)   Produces useless shit
b.)   Doesn't do anything complicated.

Anything that takes a long to simulate means it takes *much longer* to synthesize.   The load and go method who take so long to debug and test as synthesis cycles drive the process.   When a complex piece of logic takes 2 hours to synthesize,  not using the simulation tools is really dumb.

Logic analyzer tools like chipscope pro are useful as well but come *after* simulation.   Even then,  with a complicated design (i.e. Synthesis Times on the order of hours)   debugging can be slow.

Relying on VHDL strong typing to save you is a bad idea.   

I have only had 1 case in 18 years where something that something that passed all post P&R simulations that had any issues with the real world implementation.   Even in that case the problem had nothing to do with the simulation not being accurate.

Simulations save an enormous amount time in the lifecycle of a project.        Verilog/SystemVerilog have extremely powerful constructs for running just about anything through your logic and getting close to 100% test coverage without a human having to look at waveforms.

That all being said,  if your end goal is to make led blinkers for hobby projects then you can get away with the load and go method.

[james_s]

I rarely simulate but I can see the value of doing so with some types of projects. I find that the simulator in Xilinx ISE is really quite good but for some reason Altera removed it from Quartus and made it a separate tool that is not very good in my opinion. I'm not doing FPGA development professionally either so it doesn't really matter. My primary interest is recreating 70s/80s arcade games and early computers and for that I've found the logic analyzer tool adequate for most of this. Simulating a long enough stream for the 6502 or 6800 code to do something interesting takes ages. 

[mac.6]

Simulation, validation and analysis are 90% of asic work, you just can't send design to fab without testing it as much as possible.
Today verilog coding is almost trivial, but moving from one node to another is not, neither developing boot rom code before tapeout (done on FPGA but also on RTL/gate level simulation).

[james_s]

Most hobbyists are not designing ASICs or sending anything to a fab, for us the FPGA is the end result and if it works that's good enough. One should always strive to do as close to professional grade work as possible but depending on the goal that isn't necessarily something to get too caught up over.

[mikeselectricstuff]

I would highly recommend getting a SoC fpga dev board, e.g. de0-nano-soc, because you can do so many fun things with implementing peripherals on the fpga and writing drivers for it. I've implemented video output devices, data streaming devices (for software defined radio), etc. You can also access dram through an AXI bus without the hassle of dealing with controllers or worrying about timings, as that is all configured for you by the bootloader.

For a beginner I would also recommend vhdl instead of verilog, as vhdl is intentionally designed to make it hard to make mistakes (with its strict type system and all that); once you get past the compilation errors your design usually works. With verilog you will be catching your errors on the hardware rather than at compilation time. Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it. Not to mention the simulated behavior often differs from the hardware, e.g. if you use processes the sensitivity list applies during simulation but is ignored in synthesis (and this is considered working as intended!). Learn the logic analyzer tools instead (signaltap for altera, chipscope for xilinx).

"Don't bother with simulations" you are joking right?

For someone getting started, simulation is just another bunch of stuff to learn before the gratification of getting some hardware working.
As you get into more complex stuff and longer place/route cycles, at some point it will it become necessary but I've yet to feel any need for it it for the few, fairly simple stuff I've done to date.

[langwadt]

I would highly recommend getting a SoC fpga dev board, e.g. de0-nano-soc, because you can do so many fun things with implementing peripherals on the fpga and writing drivers for it. I've implemented video output devices, data streaming devices (for software defined radio), etc. You can also access dram through an AXI bus without the hassle of dealing with controllers or worrying about timings, as that is all configured for you by the bootloader.

For a beginner I would also recommend vhdl instead of verilog, as vhdl is intentionally designed to make it hard to make mistakes (with its strict type system and all that); once you get past the compilation errors your design usually works. With verilog you will be catching your errors on the hardware rather than at compilation time. Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it. Not to mention the simulated behavior often differs from the hardware, e.g. if you use processes the sensitivity list applies during simulation but is ignored in synthesis (and this is considered working as intended!). Learn the logic analyzer tools instead (signaltap for altera, chipscope for xilinx).

"Don't bother with simulations" you are joking right?

For someone getting started, simulation is just another bunch of stuff to learn before the gratification of getting some hardware working.
As you get into more complex stuff and longer place/route cycles, at some point it will it become necessary but I've yet to feel any need for it it for the few, fairly simple stuff I've done to date.

I'm surprised, it must have been some very simple stuff, it only takes seconds to simulate if you not taking huge SoCs and millions of cycles and you can instantly see what is going on without having to guess and wait another tens of minutes to see if you were right

[Bassman59]

One should always strive to do as close to professional grade work as possible

Which implies simulating the design.

If we were interviewing someone for a position as an FPGA design engineer and that person said, "I don't think simulation is necessary," the interview would be terminated immediately.

[NivagSwerdna]

a.)   Produces useless shit
b.)   Doesn't do anything complicated.

That's probably what I am aiming at. 

I plan to look at Verilog, VHDL and simulation all in a probably very superficial way.

In my journey so far I am amazed how there seems to be a huge gap in the market between the expen$ive SoC FPGAs and the commodity processors with a bit of configurable logic.... e.g. a PIC with a CLC.

Anyway it's very fun so far.  Thanks for all the helpful suggestions.

(Having read the code for the DE2_Default I'm more confident that the board I bought is at least mostly functional)

[mikeselectricstuff]

For someone getting started, simulation is just another bunch of stuff to learn before the gratification of getting some hardware working.
As you get into more complex stuff and longer place/route cycles, at some point it will it become necessary but I've yet to feel any need for it it for the few, fairly simple stuff I've done to date.

I'm surprised, it must have been some very simple stuff, it only takes seconds to simulate if you not taking huge SoCs and millions of cycles and you can instantly see what is going on without having to guess and wait another tens of minutes to see if you were right

I'm talking compile cycles of under a minute or two max. Lowest-end devices - SPartan3, MachXO2, LFEC3 etc.
It may only take seconds to simulate but how long to set up all the external signals you're interfacing to?
And what when the output is a firehose of data to a large LED matrix, glitches are seen immediately on real hardware, but would be impossible to see on a simulation without extensive analysis.
One of the designs was pulling image data from NAND flash to two LCDs ( mirrors of each other), and implementing a comms prototcol to program the flash (and also the SPI flash) over an LVDS link daisychained through about 40 nodes.
I have no clue how you could begin to set up stimulus to simulate that effectively.
I'm sure it's possible but I suspect it would take a lot of compile-run cycles before the time-spent break-even point.
All the stuff I've done is so far below the device's speed that timing would never have been an issue. 
I just built it up progressively a step at a time, testing and debugging as I went along, and often planning out the next section while waiting for the previous one to compile.

[mikeselectricstuff]

a.)   Produces useless shit
b.)   Doesn't do anything complicated.

That's probably what I am aiming at. 

I plan to look at Verilog, VHDL and simulation all in a probably very superficial way.

In my journey so far I am amazed how there seems to be a huge gap in the market between the expen$ive SoC FPGAs and the commodity processors with a bit of configurable logic.... e.g. a PIC with a CLC.

The Lattice XO2/3 and ICE40 devices fit nicely into this gap. (And don't forget CPLDs). Also Cypress PSOC

[james_s]

One should always strive to do as close to professional grade work as possible

Which implies simulating the design.

If we were interviewing someone for a position as an FPGA design engineer and that person said, "I don't think simulation is necessary," the interview would be terminated immediately.

Strive for doesn't necessarily mean meet at all times. I strive to eat healthy and avoid junkfood but it doesn't always happen, getting 50% there is better than not even trying.

Who is even talking about interviewing as a professional FPGA design engineer and how is that even relevant here? If every electronics hobbyist was held to the same standards as high level professional engineers there would be no hobbyists. If the choice was always between doing it all by the book and not doing it at all, most hobbyists would never even try. This isn't someone wanting to fly passenger airliners as a hobby, nobody is going to die if they don't follow all the rules. The things I'm using FPGAs for, mostly replicating 35-45 year old existing designs are not at all what FPGAs are designed to do in the first place but that's what hacking is all about.

Obviously if someone is interviewing as an FPGA designer they're going to be proficient at simulation but there is a very long road from zero to being a proficient professional level developer. One of the reasons competent FPGA developers get paid as well as they do is because there are so few of them so I don't think a hobbyist should be put off by not being able to reach that bar. The small number makes it a rather exclusive club which I guess breeds a lot of elitism.

[rstofer]

I haven't found simulation to be all that helpful.  Sure, it works for decade counters and things like that.  Where my problems crop up is about a million cycles after the start when I don't properly handle the op code that's 1000 lines into the OS code.  I know the system hangs but I might not know where so I don't know which op code.

So, one layer up, I write test code for each instruction and watch it execute on the LEDs.  I might even build a hardware breakpoint capability into the FSM breaking on the address in the console switches and perhaps single-step from there.

In the early years, I didn't have a simulator with Xilinx ISE.  I'm still working through whether it is worth the effort with Xilinx Vivado.  The logic analyzer capability is pretty nice but it remains to be seen how well it works a million cycles in.

My projects are all hobby  works.  I try to avoid getting clever with the coding.

One thing I learned a long time ago:  If I don't put bugs into the code, I won't have to spend time getting them out of the code.

[lem_ix]

Did Xilinx introduce non bga Artix parts? Remember sticking to ISE and Spartan on a project a while ago because of that.

[asmi]

Did Xilinx introduce non bga Artix parts? Remember sticking to ISE and Spartan on a project a while ago because of that.

There is no need to be afraid of BGA parts as 4 layer boards are quite cheap nowadays.

[asmi]

For a beginner I would also recommend vhdl instead of verilog, as vhdl is intentionally designed to make it hard to make mistakes (with its strict type system and all that); once you get past the compilation errors your design usually works. With verilog you will be catching your errors on the hardware rather than at compilation time.

Bad advice. VDHL is almost dead. Forget it ever existed.

Don't bother with simulations because once you start doing more complex designs it will be unusably slow and you will have to un-learn relying on it. Not to mention the simulated behavior often differs from the hardware, e.g. if you use processes the sensitivity list applies during simulation but is ignored in synthesis (and this is considered working as intended!). Learn the logic analyzer tools instead (signaltap for altera, chipscope for xilinx).

This is the worst advice I ever heard on this forum!
The reason you don't like setting up sims is because you use a language from the stone age of computing. Modern HDLs (like SystemVerilog) have many useful tools specifically designed for use in test benches. And so setting up fully automated TBs with it is much easier, and it allows you to cover cases which are hard to recreate in hardware on purpose. And since tests are automated, there is no need to babysit them, you can launch them in the evening to see results next morning. But this is only true for integration tests, which mostly test components integration. Usually I create a TB for each component, and only run single TB during development, so it runs quite quickly.
Testing in HW is the last step of HDL design, and is only done after all sims are passed successfully and it works as it should 100% of times.
This is especially bad advice for hobbyists who tend to not have very expensive equipment like oscilloscopes with multi-GHz bandwidth that would be able to "catch" issues in high-speed data streams, which is what FPGAs are mostly used for nowadays, so extensive sims is the only chance for them to catch these problems. Another reason for sims is making sure you don't mistakenly output signals that could lead to damage of downstream components. This again is an issue for hobbyists because they usually don't have infinite R&D budgets to replace parts destroyed due to bugs in design.

[rstofer]

For an interesting and educated article on the various HDLs, try this:

https://trilobyte.com/pdf/golson_clark_snug16.pdf

Check the 4th paragraph of section 8.  It seems that FPGA designers haven't all jumped ship from VHDL to SystemVerilog.  ASIC designers, probably.  FPGA users seem to be using VHDL for the RTL bit and are moving slowly toward SystemVerilog for verification.  There's a lot of inertia in the aerospace and military industries.


Languages are a funny thing.  You would think that COBOL would be a dead issue.  And you would be wrong!  The banking industry is a heavy user of COBOL to the extent that an estimated $3 trillion per day moves over systems coded in COBOL.

https://thenextweb.com/finance/2017/04/10/ancient-programming-language-cobol-can-make-you-bank-literally/

Then there are the physicists - they are still using FORTRAN (as am I but I'm not a physicist).

http://moreisdifferent.com/2015/07/16/why-physicsts-still-use-fortran/

Languages come and languages go but COBOL and FORTRAN will live forever!

Don't bury VHDL just yet!

[obiwanjacobi]

I watched all these: https://www.youtube.com/user/LBEbooks

HTH /[2c]

[tggzzz]

I haven't found simulation to be all that helpful.  Sure, it works for decade counters and things like that.  Where my problems crop up is about a million cycles after the start when I don't properly handle the op code that's 1000 lines into the OS code.  I know the system hangs but I might not know where so I don't know which op code.

So, one layer up, I write test code for each instruction and watch it execute on the LEDs.  I might even build a hardware breakpoint capability into the FSM breaking on the address in the console switches and perhaps single-step from there.

In the early years, I didn't have a simulator with Xilinx ISE.  I'm still working through whether it is worth the effort with Xilinx Vivado.  The logic analyzer capability is pretty nice but it remains to be seen how well it works a million cycles in.

My projects are all hobby  works.  I try to avoid getting clever with the coding.

One thing I learned a long time ago:  If I don't put bugs into the code, I won't have to spend time getting them out of the code.

Appropriate design strategy is key to not inserting bugs, of course. Surprising few people cotton on to that concept, maybe because they are young and inexperienced.

Testing never creates quality; there's an old aphorism "you can't test quality into a project". However, testing (i.e. simulation in this context) does have several invaluable benefits:

• tests prevent regressions, i.e. (re)introduction of bugs into something that was previously working
• tests are the best available technique when integrating your (perfect) code with that from imperfect sources (libraries or co-workers)
• where placement and routing takes significant time, pre-P&R simulation can act as a sanity check that saves time
• tests enable radical refactoring
• tests enable initial system design using behavioural models, then switching to structural or gate models