Getting started with FPGA

[NivagSwerdna]

IMHO I've been very good this year so I'm i'm thinking of asking Santa for a Terasic DE0-Nano or perhaps DE10-Nano..

(I am quite interested in https://github.com/MiSTer-devel/Main_MiSTer/wiki project but that is a long way off and due to time constraints may never happen.)

Can anyone recommend some reading to provide a background for either of these devices/technologies to get started?

(Never done any HDL before)

[rstofer]

I prefer a board with 'gadgets' like 7 segment displays, switches and buttons.  There is nothing wrong with the DE-10 Nano as long as you have a way to implement the gadgets.

My favorite board at the moment is the Nexys 4 DDR but it is really pricey and probably a bit of overkill:
http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/

As a fallback, I would consider the Basys 3 Artix 7 board which is a little more reasonable:
http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/

These are personal choices, but they are based on the 'gadgets'.

You will need to pick a language to start your travels.  You have a choice of 3:  VHDL, Verilog (about which I know little) or System Verilog (about which I know nothing).  I started with and continue to use VHDL.  And, yes, you can start a language war by trying to discuss 'which is better'.  Pick one - just make sure it is VHDL.

You need to install the appropriate toolchain: Xilinx Vivado for either of the Digilent boards and Altera <whatever> for the Nano.  These will be huge installs and CPU speed WILL matter as soon as you try to synthesize a project.

Books:

"Real World FPGA Design with Verilog" - I really need to read this book.  I have it but I haven't had time.

"Digital Design and Computer Architecture" Harris and Harris - Uses System Verilog and VHDL in parallel.  You can compare the languages as you go.  This book builds a MIPS type CPU from scratch and presents all of the design considerations and their implementation.

"Digital Design and Computer Architecture ARM Edition" Harris and Harris - same authors building an ARM processor.

"Computer Architecture and Design" Patterson and Hennessy - has nothing to do with FPGAs but is considered the gold standard for design.  The authors designed the MIPS processors and started the MIPS company.

"RTL Hardware Design Using VHDL" Pong Chu - dedicated to using VHDL properly.

"Introduction to Computing Systems: From Bits and Gates to C and Beyond" Patt and Patel - this book starts at the very beginning of logic design and works up through a RISC CPU and on to an assembler and C compiler.  This is a great starter project and is used in many universities.  Google for 'LC-3'  The book does not present the VHDL but it is a pretty easy project to build as they give you the hardware layout and a description of the state machine.  I really like this project!  You should definitely have this book!

https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond/dp/0072467509

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.

Hint:  As you build LC-3, you will see why I want my boards to have 'gadgets'.  It sometimes comes to pass that my code isn't perfect right out of the gate.  Debugging is easier with 'gadgets'.

 

[asmi]

Pick one - just make sure it is VHDL.

It sucks. SystemVerilog rocks! No other language is even close when it comes to verification. Just take a look at AXI Verification IP from Xilinx, and show me something that is even remotely as powerful written on something other that SV.
I'd pick a board based on Xilinx part over Antel as the former provides a lot of IP cores for free, while the latter will charge you through the nose for the same thing.

[nctnico]

Pick one - just make sure it is VHDL.

It sucks. SystemVerilog rocks! No other language is even close when it comes to verification.

Perhaps but for FPGA code itself VHDL is much more powerful and compact (as long as you don't start to describe hardware). SystemVerilog is just Verilog with some extra features bolted on but it still doesn't cut it when compared with VHDL.

[asmi]

Perhaps but for FPGA code itself VHDL is much more powerful and compact (as long as you don't start to describe hardware). SystemVerilog is just Verilog with some extra features bolted on but it still doesn't cut it when compared with VHDL.

Name VHDL features which don't have SV counterparts. I can easily name quite a few features of SV which not only don't exist VHDL but can not be even emulated in it. We're going to have a good laugh
Not to mention very poor syntax noise-to-signal ratio of VHDL. I know all three languages, so I can compare them.
Also you seem to disregard verification while in fact it's VERY important as it allows to use TDD-like approach which not only speeds up design, but makes it more robust because of automated tests. Full suite of AXI peripheral tests would take a ton of VHDL code that is extremely hard to maintain, while in SV it's literally a few dozen lines of code.
Sorry man, but the holy war is over - SV wins on ALL fronts - from hardware to verification. VHDL is the thing of the past, and holds it own only until old generation of engineers who can't learn new things will be replaced by a new generation.

[daybyter]

I have a de0 nano, which I bought a while ago, and I don't think it makes any sense to buy it today. I might be a special case, since I'm interested in the combination fpga+internet, so GBit ethernet is a must if you ask me.
A CPU with some RAM makes initialization of additional hardware a looot easier (just working on a CPU core just to initialize a phy).
Some 7 segment digits provide some helpful status info.
VGA out is good, if you want to develop gaming hardware.
So if you want to buy altera, buy a de10 or one of those 15$ cyclone 2 boards, if you just want to play with a HDL language.

Or just download the free dev tools and just run simulations.

[Sal Ammoniac]

I have a Digilent Arty-A7, which is only $99. It's got a Xilinx Artix-7 FPGA, which is compatible with Vivado. Not as fancy as some of the other popular boards, but not too pricey either.

And for heaven's sake, use SystemVerilog, not that ancient and mouldy VHDL...

[asmi]

I have a de0 nano, which I bought a while ago, and I don't think it makes any sense to buy it today. I might be a special case, since I'm interested in the combination fpga+internet, so GBit ethernet is a must if you ask me.
A CPU with some RAM makes initialization of additional hardware a looot easier (just working on a CPU core just to initialize a phy).
Some 7 segment digits provide some helpful status info.

I would recommend you take a look at one of Zynq boards if SoC is something you're interested in.

VGA out is good, if you want to develop gaming hardware.

I would suggest you take a look at HDMI instead - it's almost as simple as VGA, and even relatively slow speed grade "1" Artix can easily pump out 720p@60Hz or 1080p@24Hz (as odd as it sounds, the latter actually requires slightly less of "on the wire" bandwidth than the former). It took me just a couple of hours to implement a very simple HDMI core so that I can test HDMI TX connector on my own board. The advantage is obvious though - you will be able to output video in full honest-to-God 24 bit color, and you won't have to search for device that actually have VGA port.

[asmi]

I have a Digilent Arty-A7, which is only $99. It's got a Xilinx Artix-7 FPGA, which is compatible with Vivado. Not as fancy as some of the other popular boards, but not too pricey either.

I have it too, but the problem is I've "outgrown" it quite quickly as it doesn't have any hi-speed expansion options. Which is why now I design and build my own devboards

[NivagSwerdna]

What about a second hand DE2? It has quite an old Cyclone??

[Mr. Scram]

You may want to have a look at this shop on Aliexpress. It has reasonably priced boards and documentation is present, at least with the board I bought. Another forum member had similar experiences. I'm not affiliated in any way.

https://nl.aliexpress.com/store/620372

[RoGeorge]

This is a good place for getting started with FPGA:
http://www.fpga4fun.com/

[suicidaleggroll]

I'm a big fan of Digilent's boards.  They're designed well, reliable, lots of interfaces and I/O, and they have tons of example and demo projects for each board that demonstrate various features.  Finally, they provide their schematics (minus the FTDI/programming page), so if you want to move to designing your own board you can see exactly how everything was hooked up in the dev board.  Many dev boards are like this, but not all.  I personally have experience with the Nexys 2, Nexys 3, Nexys Video, Arty A7, Arty S7, Cmod C2, and Cmod A7.  I don't have any complaints about any of them.  The Artys are good entry level boards, and if you want to experiment with more I/O, high speed interfaces, etc. the Nexys line works well for that.

[asmi]

I'm a big fan of Digilent's boards.  They're designed well, reliable, lots of interfaces and I/O, and they have tons of example and demo projects for each board that demonstrate various features.  Finally, they provide their schematics (minus the FTDI/programming page), so if you want to move to designing your own board you can see exactly how everything was hooked up in the dev board.  Many dev boards are like this, but not all.  I personally have experience with the Nexys 2, Nexys 3, Nexys Video, Arty A7, Arty S7, Cmod C2, and Cmod A7.  I don't have any complaints about any of them.  The Artys are good entry level boards, and if you want to experiment with more I/O, high speed interfaces, etc. the Nexys line works well for that.

Yea, I used their schematics quite a bit during design of my own boards. However you'd better stay vigilant - I've found a mistake in design of their Arty-Z7 board, and they said they are going to fix it, but as of now (over half year later) it still not fixed (at least in schematics).

[rstofer]

As I said earlier, I want gadgets.  I absolutely need at least 8 digits of 7 segment displays and prefer 16.  I also need at least 16 toggle switches and some number of buttons, say 8 or 9, the 9th being 'reset'.  16 individual LEDs would also be helpful.

Microchip IO Expanders will take care of all the discrete IO and a Maxim display driver can handle 16 digits of 7 segment displays.  These devices can be had with SPI interfaces so you need 3 IO lines (SCK, MISO, MOSI) plus some number of CS' lines (probably 4).  Build this PCB first and test it with a 3.3V Arduino.  I would feed it with a 5V wall wart and use a 3.3V LDO regulator for all the devices.  Once working, you would have a universal debugging gadget for any FPGA project.

Obviously, the first FPGA project is to create components to drive the board.

I can't convince myself that these eBay specials will work on 3.3V logic but that's what the supplier says.  They are cheap enough that it is worth experimenting:

https://www.ebay.com/itm/MAX7219-8-Digital-Segment-Digital-LED-Display-Tube-For-Arduino-51-AVR-STM32/201536584320

If the 7 segment displays work out, more than half of the work is finished.  Then it's just a simple PCB for switches, buttons and LEDs.

[NorthGuy]

I absolutely need at least 8 digits of 7 segment displays and prefer 16

If you have USB or Ethernet, you can send data to the PC, which has lots more than 8 digits, and also letters, special symbols, and graphics too. IMHO, this beats the on-board LCD in and out.

[daybyter]

Hmmh...I know that there are some fpga boards with ethernet hardware.

But do they actually come with some software/core to use this hardware? I'm interested in ethernet for fpga, but the easiest way so far would be a 10 MBit SPI PHY, implement a simple CPU and then use something like lwip.

Are there free HDL TCP stacks, that could be used with reasonable effort?

[rstofer]

I absolutely need at least 8 digits of 7 segment displays and prefer 16

If you have USB or Ethernet, you can send data to the PC, which has lots more than 8 digits, and also letters, special symbols, and graphics too. IMHO, this beats the on-board LCD in and out.

If I had USB working or Ethernet, my project would be essentially complete.  These gadgets would be more useful earlier in the process.

Some boards have the USB programmer interface provide a serial port.  This is pretty nice and certainly a useful addition.  I would expect using serial to be considerably more complex than shoving bytes out over an SPI interface.  Maybe not...  I haven't tried it.  We would need to convert 32 bit binary, for example, to 8 ASCII chars. 

No, I think I would prefer gadgets when I first start implementing the project.  If it is a CPU, let the CPU deal with text messages.  Once I get that far...

[mikeselectricstuff]

Hmmh...I know that there are some fpga boards with ethernet hardware.

But do they actually come with some software/core to use this hardware? I'm interested in ethernet for fpga, but the easiest way so far would be a 10 MBit SPI PHY, implement a simple CPU and then use something like lwip.

Are there free HDL TCP stacks, that could be used with reasonable effort?

A Wiznet W5500 is a quick and easy way to get ethernet - certainly easier than doing it on the FPGA

[nctnico]

Hmmh...I know that there are some fpga boards with ethernet hardware.

But do they actually come with some software/core to use this hardware? I'm interested in ethernet for fpga, but the easiest way so far would be a 10 MBit SPI PHY, implement a simple CPU and then use something like lwip.

Are there free HDL TCP stacks, that could be used with reasonable effort?

A Wiznet W5500 is a quick and easy way to get ethernet - certainly easier than doing it on the FPGA

But you'd still need some kind of softcore to setup the W5500 and communicate with it. If you need TCP/IP then the W5500 is a good way to go. Using UDP is much easier and certainly doable directly from the FPGA. A softcore is handy to deal with things like ARP, DHCP and so on.

[rhb]

"Computer Architecture and Design" Patterson and Hennessy - has nothing to do with FPGAs but is considered the gold standard for design.  The authors designed the MIPS processors and started the MIPS company.

Thanks for the nice list of FPGA books.  However, Patterson developed the SPARC and Hennessy the MIPS.  But I salute your including it.  I've got  the first 4 editions and have read 3.  If I had  HPC work I'd read whatever the most recent edition was.  Each edition was a complete change in how you had to write HPC code.

BTW Patterson is also the culprit behind RAID ;-)

[asmi]

Hmmh...I know that there are some fpga boards with ethernet hardware.

But do they actually come with some software/core to use this hardware? I'm interested in ethernet for fpga, but the easiest way so far would be a 10 MBit SPI PHY, implement a simple CPU and then use something like lwip.

Are there free HDL TCP stacks, that could be used with reasonable effort?

Xilinx provides 10/100 Ethernet core, as well as lightweight IP stack for Microblaze softcore for free.

[NorthGuy]

If I had USB working or Ethernet, my project would be essentially complete.  These gadgets would be more useful earlier in the process.

If you get a board, it usually will have some connectivity provisions and often will have sample projects that use them. You can start from these and then add to it using it as a test-bed. Since you're not using all the fabric, the connectivity part may coexist with your project. It is easy with FPGA (unlike MCU where overbloated connectivity modules might be screwing your timing). Then, when you move to your own board, you just shoot off the parts which you do not need. But, by that time you would have your own connectivity.

[NivagSwerdna]

I know it's probably totally obsolete but I bought an old DE2 Terasic Board on EBAY and plan to follow Bruce Land's Cornell https://people.ece.cornell.edu/land/courses/ece5760/ labs and videos... Bruce et al have moved on to the DE1-SoC but that is beyond my current budget.
The DE2 should be a good starting point (although it's too old to be worth using in any YouTube videos).

If any Terasic rep reads this board and wants to lend me a DE1-Soc make sure you get in touch, 

The board I bought smells slightly of magic smoke but seems to power up into some wild flashing mode OK so I am hopeful. it also comes with a display, camera module and some other I/O gadget and all for £75+P&P.... I thought it was worth it.

TRDB-DC2,TRDB-LCM,THDB-ADA & DE2 Serial 1.....

(The THDB-ADA has a bit of physical damage... one ADT1-1WT RF Transformer hanging off... but probably repairable)

[Incidentally, I'm interested in old arcade games, I have a Konami machine... so generating VGA, sprites etc... right up my alley... maybe some AY-3-8910 emulation... ]

[james_s]

For just starting out I like the EP2C5T144C8 "mini boards" you can get for under $15 from ebay and various other Chinese sellers. Yes it's an old part, but it's also plenty capable of doing some really cool stuff. There's Grant Searle's "Multicomp" 8 bit microcomputer, even a variant that runs fullblown CP/M from a SD card. I have recreated a number of 70s Atari arcade games on one, the biggest consumes about 50% of that FPGA. For a beginner there is no need to spend a lot, a fancier FPGA costs more, compiling is much slower, and it will blow up just as easily when you accidentally short one of the IO pins to an excessive voltage.

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.

The most important thing to remember no matter what is when you are writing HDL you are NOT WRITING A PROGRAM!! You are describing digital hardware in a language that superficially resembles a program. Think about that every time you sit down to work with it.

[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

[mikeselectricstuff]

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.

I can't comment on the dead-ness or otherwise of VHDL, but this was the exact reason I went with VHDL - when navigating a new unknown world, having the tools be better at finding errors is very helpful. The biggest learning curve is the concept of HDL - once you've got the hang of that, switching language later isn't a big deal.

In the same way that C is probably not the ideal language to start learning programming with.

A hobbyist just wants to get the job done and learn - it doesn't matter how popular or not the language is, and there are plenty of VHDL examples and tutorials out there.

[mikeselectricstuff]

BTW winding back to the original topic of gettijng started, on the last Amp Hour, the Clifford Wolf mentioned that for simpel designs, the IceStorm open-source toolchain for ICE40 would compile simple designs in a few seconds, so that could be a good route for someone wanting to get something up & running quickly   

[daveshah]

BTW winding back to the original topic of gettijng started, on the last Amp Hour, the Clifford Wolf mentioned that for simpel designs, the IceStorm open-source toolchain for ICE40 would compile simple designs in a few seconds, so that could be a good route for someone wanting to get something up & running quickly   

On a modern PC, I measure 1.79 seconds from verilog to bitstream for a simple fading R-G-B demo for the UltraPlus using icestorm - plus half a second or so to program the SRAM - and you can try a lot of simple designs very quickly!

[iMo]

ICE40UP5k J1a forth design:

IceCube2 v 2017.08 [Win7]:
Build time (verilog->bitstream): 2minutes and 52 seconds  (max 3minutes 3 seconds)

Code: [Select]

Device Utilization Summary
    LogicCells                  : 2596/5280
    PLBs                        : 387/660
    BRAMs                       : 30/30
    IOs and GBIOs               : 30/36
Icestorm (pulled and rebuilt yesterday) [Ubuntu in VirtualBox]:
Build time (verilog->bitstream): 51 seconds (max 56 seconds)

Code: [Select]

After placement:
PIOs       22 / 39
PLBs       565 / 660
BRAMs      30 / 30
Note: UP5k is still in development in Icestorm today, the identical verilog source has been built, the Icestorm counts the 3 LED drivers as PIOs (IceCube2 does not).

As of today, the Icestorm is much faster in creating the bitstream from verilog, but the IceCube2 squeezes the design much better..

[BrianHG]

Learn to simulate.
If you have some major SOC which requires billions of cycle to simulate before you get to what you need to test, learn to have multiple sub-projects or sub-simulate the sections of your design you created to test their functions individually and some collectively as needed.
I could not have created a video scaler/scan rate converter with PIP and OSD without simulation.  Even with simulation, it was still hard enough as compile times could be up to an hour to meet the required FMAX.

*** LEARN to simulate even before buying a board.  You only need to freely download the dev tools to simulate... ***

Though I did like Quartus II v9.x built in simulator, especially cheap functional mode which compiled and simulated my design in 2-3 seconds VS routing the entire FPGA.  I haven't done any FPGA design in a few years, but I know Quartus II v10-12 did something funny by removing simulation.  I don't know about the newer generation Quartus.

[ehughes]

That's probably what I am aiming at. 

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

If your in learning mode,   check out SystemVerilog.   It is a superset of Verilog that eliminates a lot of the cruft from the original Spec.      In the high end logic design world it is taking over as the verification constructs are superior to both regular Verilog and VHDL.   
 
http://www.fpga4fun.com/FPGAsoftware2.html

Look at the difference between A D-Flop for Verilog and VHDL. 

[mikeselectricstuff]

*** LEARN to simulate even before buying a board.  You only need to freely download the dev tools to simulate... ***

Different people have different ways of learning - doing it in simulation may work fine for some people, playing with hardware and looking at what it does on a scope may be better for others.

You could say exactly the same for programming microcontrollers. Or building any hardware.

To go from zero FPGA knowledge  to blinking a LED, or something less trivial but useful ( e.g. driving LED matrices), doing it with simulation will take longer as there's more to learn.

[NorthGuy]

When you're starting with FPGA, I believe it's a good idea to learn what's inside - LUTs, flip-flops, interconnect. How these things interact with each other to form RTL logic. How they can be used to create a simple counter, or a simple state machine, or a simple SPI receiver.

At this stage it doesn't make much difference what language you use, whether you simulate or not (although real hardware is much more fun than simulators). All you need to do is to get familiar with the logic, get some basic understanding. It probably will take a while, but if you like exploring new things, it'll be fun. Once you're past the learning stage you will know what language you want to use, which pieces you want to simulate and which you don't, etc.

If, in contrast, you start from projects which utilize huge IPs with hours in the compile time, you will have no idea what you're doing, what can and cannot be done. You may be able to build a video-digi-quasi-super-duper-thing rather quickly, but it'll have about the same effect as if you bought it pre-made.

[mikeselectricstuff]

That's probably what I am aiming at. 

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

If your in learning mode,   check out SystemVerilog.   

Is SystemVerilog generally supported by the free versions of vendor tools ?

[rstofer]

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

HTH /[2c]

Thanks for posting the link!  That is a massive assortment of FPGA programming videos.

[mac.6]

That's probably what I am aiming at. 

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

If your in learning mode,   check out SystemVerilog.   

Is SystemVerilog generally supported by the free versions of vendor tools ?

vivado/quartus yes, ISE no. And no opensource tools I am aware of.

[Mr. Scram]

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

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.

Can you elaborate on VHDL almost being dead?

[mikeselectricstuff]

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

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.

Can you elaborate on VHDL almost being dead?

AIUI there has always been a USA/Europe division between VHDL and Verilog, don't recall which way.

[james_s]

VHDL is anything but dead, it's very popular. Verilog is more common in the US in professional fields but in the hobbyist community I found far more VHDL support. I also found VHDL to be far easier to learn, it's easier to learn VHDL and then learn Verilog than the other way around. Either way it seems to spark an odd religious war for some reason, as if the language one uses should really matter to someone else. IMHO it's simply the snooty elitism I mentioned earlier.

[Mr. Scram]

VHDL is anything but dead, it's very popular. Verilog is more common in the US in professional fields but in the hobbyist community I found far more VHDL support. I also found VHDL to be far easier to learn, it's easier to learn VHDL and then learn Verilog than the other way around. Either way it seems to spark an odd religious war for some reason, as if the language one uses should really matter to someone else. IMHO it's simply the snooty elitism I mentioned earlier.

I was going to try VHDL, until I found out PSoC only takes Verilog. I can see me making the most practical use of HDL through PSoC, so I'm not quite sure where to go now.

[asmi]

Can you elaborate on VHDL almost being dead?

It just is. There are no improvements, no progress, no anything. Compare that to SystemVerilog, or even SystemC. Compared to them, VHDL's verification tools are just pathetic. It lives on life support provided by older generation of designers who can't be bothered to learn anything new. But they will soon be gone, and VHDL will follow.
Hardware industry slowly realised what was known in software industry for at least a decade - automated testing is the best way to increase quality of the code. Hence all these new developments in verification techniques, tools and frameworks. It will get there eventually.
Also interesting observation - every time I hear someone says sims are useless, that person turns out to use VHDL. So it's not sims which are useless, it's the instrument which is not appropriate for the task in hand.

[rstofer]

I was going to try VHDL, until I found out PSoC only takes Verilog. I can see me making the most practical use of HDL through PSoC, so I'm not quite sure where to go now.

You're talking about the Cypress PSoC devices?  The FPGA fabric is pretty small.  It works for its intended purpose, of course, but I'm not sure you can implement a full RISC CPU, for example.  The fabric is really intended to be glue logic with access to the datapath.

I have been playing with those PSoC devices and I like them a lot.  I kind of enjoy the graphical programming approach.  I'm hoping we get a lot further along with the PSoC 6 robotics project.  I'm waiting...

If I were starting from scratch with FPGAs, I would probably start with Arty 7 - an Artix 7 development board.  The problem with the board is that it doesn't have gadgets like 7 segment displays and a bunch of switches and buttons.  My personal favorite, at the moment, is the Nexys 4 DDR board but it is pricey.  The chip is huge, it has all of the gadgets I want and it is really easy to work with.  Maybe that's why it is targeted at universities.

If I did start with Arty, I would build a PCB with LEDs, 7 segment displays, slide/toggle switches and buttons.  These would all be connected to one or more IO expanders and interfaced with the FPGA via SPI.  In fact, I did something quite similar with I built my CPU project several years ago.  There is a board with 16 toggle switches and another board with 16 digits of 7 segment displays (Maxim makes the controller).  It is really easy to implement SPI on the FPGA.

I started with VHDL and I have no intention of changing.  In many ways, VHDL is like Pascal - strongly typed and simply elegant.  Wordy, but elegant.  I find Verilog incomprehensible.  One look at the code and my eyeballs roll back.  It looks like C without the style.  Things like blocking assignments, non-blocking assignments, always * blocks, wires and regs just haven't clicked.  They never will because I'm not planning to spend the time required to make them click.

Nobody else likes Verilog either; it was always the ugly stepchild of HDLs.  So what did they do?  They took the good features of VHDL and tacked them onto Verilog to create SystemVerilog.  But the good stuff in SystemVerilog started with the good stuff in VHDL.

SystemVerilog may eventually take over from VHDL.  Verilog itself was always a smaller player.  It may actually be worth learning SystemVerilog.

In any event, all 3 languages are gigantic (particularly VHDL) and only a small percentage of the language is actually used to create logic.  There are huge portions of all of these languages that just doesn't get used - especially by hobbyists.

Everybody, including me, will try to justify the language they are using.  Java has portability, C has pointers (oh, wait, that's not a plus), C has conciseness and easily approaches the hardware, FORTRAN is still a standard language in the scientific community (and I would bet it is still used in aerospace), C++ has objects, PASCAL is elegant (I'm still thinking about Modul2 and Oberon) and, for the life of me, I can't get excited about Python, Perl, Ruby or Rust.

I'll just stick with what I know until something comes along that pushes me in a different direction.

[Mr. Scram]

I know the FPGA fabric in PSoC devices isn't huge, but it doesn't necessarily have to be. The ability to add custom features to an existing core is very attactive. If I wanted a full RISC CPU, I'd use a RISC CPU. That'd be cheaper, faster and probably more efficient too. If I just want to tinker around with a homebrew RISC processor, I'd use my Max or Cyclone Altera boards. Throwing one of those on a board next to a microcontroller is always an option too.

While I know PSoC won't fit all problems and designs, it's a very convenient intermediate between a regular bare microcontroller and a full blown CPLD or FPGA. Stacking existing blocks is nice, but making your own should be awesome.

[rstofer]

I know the FPGA fabric in PSoC devices isn't huge, but it doesn't necessarily have to be. The ability to add custom features to an existing core is very attactive. If I wanted a full RISC CPU, I'd use a RISC CPU. That'd be cheaper, faster and probably more efficient too. If I just want to tinker around with a homebrew RISC processor, I'd use my Max or Cyclone Altera boards. Throwing one of those on a board next to a microcontroller is always an option too.

While I know PSoC won't fit all problems and designs, it's a very convenient intermediate between a regular bare microcontroller and a full blown CPLD or FPGA. Stacking existing blocks is nice, but making your own should be awesome.

It always depends on what you want to do.  My only real interest in FPGAs is building up CPUs.  It isn't to actually USE the CPU but to have it available as a drop-in should I come up with a project that could use one.  An example might be some kind of widget that really needs to read/write a compact flash or some serial ports.  One way to go would be to drop in a small RISC processor to handle all the IO and let the widget do whatever it wanted with the data.  It would save on development time for the widget.

Sometimes computer architecture is just fun for its own sake.  This book, linked earlier, provides SystemVerilog and VHDL coding for an ARM core.  This would be too big for my drop-in CPU but it would be fun to see it work.  Pipelined processors are interesting.  Of course, you need to be  a lot more careful with the MMU than Intel was.

https://books.google.com/books/about/Digital_Design_and_Computer_Architecture.html?id=muCcBAAAQBAJ

The LC3b project is a terrific example of a non-pipelined RISC processor.  It's pretty light weight and uses about 54 states.  It's easy to take the state diagram plus some specific requirements and come up with a CPU.  It's only a couple of thousand lines of code.  It would be a lot shorter if I had written it in Verilog.

The book has the usual undergrad beginnings but there is a lot of information for computer engineering students.  The Appendices is where all the fun starts:

https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond/dp/0072467509

This is a really simple project that results in a fast CPU with user & protected modes and a LOT of system and interrupt vectors in low memory.  Just hang on a serial IO gadget and it's ready to go.  It helps if the board has a serial -> USB gadget.

[daybyter]

@rstofer: do you know the zylin cpu (ZPU)? It's very lightweight cpu with minimal instruction set, no copyright problems and gcc support!

https://en.wikipedia.org/wiki/ZPU_(microprocessor)

I want to implement one of these to have a portable design, that could be used on altera and xilinx boards.

[rstofer]

@rstofer: do you know the zylin cpu (ZPU)? It's very lightweight cpu with minimal instruction set, no copyright problems and gcc support!

https://en.wikipedia.org/wiki/ZPU_(microprocessor)

I want to implement one of these to have a portable design, that could be used on altera and xilinx boards.

I do!  I played with it for a while and set it aside.  I'm not sure why I did that because there is a lot of good stuff in that package.

The LC3 package is also pretty nice.  The designers ported LCC so there is a C compiler (I haven't tried this) and there is an assembler/linker.  I used the assembler to create code for testing but I haven't done anything with the core.  It was fun to write because the architecture was given as was the state diagram.  It was pretty much 'fill in the blanks' and, in fact, there is a form used by the project for writing the microcode (assuming a microcode implementation) that you did, in fact, fill in the blanks.  I just used a VHDL case statement to implement the FSM.

I haven't gotten as far with the Harris and Harris MIPS or ARM projects.  Maybe next week I will look at the ARM incantation.  If they implement most of the instruction set, there are a lot of C compilers around.

I'm not hung up on a small core supporting C.  I would imagine that most everything would be written in assembly language.  It would be nice if the GCC assembler/linker could be used.

[Scrts]

VHDL is anything but dead, it's very popular.

Agreed and recent survey shows this as well: https://groups.google.com/forum/#!topic/comp.arch.fpga/fN6nsmi--u0

[asmi]

Agreed and recent survey shows this as well: https://groups.google.com/forum/#!topic/comp.arch.fpga/fN6nsmi--u0

Hardware engineers are some of the most stubborn people I ever interacted with, and often this stubbornness is to their peril. But even they are slowly realizing advantages of SystemVerilog/SystemC for verification, and only continue using VHDL because of their stubbornness (as it doesn't make any technical sense whatsoever). But obviously this is only a temporary state of affairs, and no matter what some people want, single language is always better than multiple. So for beginners learning VHDL is a pure waste of time because they invest time into dying technological dinosaur. Their time will be much better spent learning SystemVerilog.
And I know VHDL folks over here will keep arguing until cows fly, but the history has plenty of examples of what happens to those who try to go against technological progress. Unless they want to share their fate, they will have to adapt.

[mikeselectricstuff]

Agreed and recent survey shows this as well: https://groups.google.com/forum/#!topic/comp.arch.fpga/fN6nsmi--u0

Hardware engineers are some of the most stubborn people I ever interacted with, and often this stubbornness is to their peril. But even they are slowly realizing advantages of SystemVerilog/SystemC for verification, and only continue using VHDL because of their stubbornness (as it doesn't make any technical sense whatsoever). But obviously this is only a temporary state of affairs, and no matter what some people want, single language is always better than multiple. So for beginners learning VHDL is a pure waste of time because they invest time into dying technological dinosaur. Their time will be much better spent learning SystemVerilog.
And I know VHDL folks over here will keep arguing until cows fly, but the history has plenty of examples of what happens to those who try to go against technological progress. Unless they want to share their fate, they will have to adapt.

Often the best tool is the one you know. Technical aspects are often not  the main deciding factor.
If a company has a lot of existing VHDL code and expertise , then VHDL is probably going to be be the best tool to maintain and build on it, and they will want to hire people that know it.
Of course there may be new languages that are better in various ways, but the bottom line is getting the job done.

I have no argument that VHDL sucks in many ways, but for a beginner its strictness and plentiful examples can help ease the learning process. How many Systemverilog example projects are there out there ? It may be declining

And just looking at Doulos' schedule of training courses for 2018 , "confirmed to run" courses in VHDL and SystemVerilog show equal numbers.
Maybe on the decline but a long way from dead.

Despite all the more recent "technically better" programming languages, C  is still rather popular...
Any language that has been around for 30 years isn't going away any time soon.


 

[tggzzz]

I'll just stick with what I know until something comes along that pushes me in a different direction.

My equivalent is to stick with what I know until something comes along that enables me to do something I couldn't easily do before.

For example, I chose C after Pascal, then Smalltalk after C, then Java after Smalltalk. I avoided Modula, C++, C#, Delphi, Perl, and a host of others.

It simultaneously horrifies and delights me that very little has changed in embedded programming in the last 35 years. Changes: smaller faster and cheaper. No changes: C, ICE/JTAG, 8/16-bits.

[NorthGuy]

So for beginners learning VHDL is a pure waste of time because they invest time into dying technological dinosaur. Their time will be much better spent learning SystemVerilog.

I don't think so. When you get proficient with any HDL, switching the language is not such a big deal.

[rstofer]

Despite all the more recent "technically better" programming languages, C  is still rather popular...
Any language that has been around for 30 years isn't going away any time soon.

The first K&R C Language book came out in '78 so C is maybe about 40 years old and is still used for all embedded programming and most OS code (Linux kernel, most of Windows, etc).

Fortran was released in '57 so it's about 60 years old and COBOL came out around '60 so it's about 57 years old.  There's a lot of Fortran use out in the wild, COBOL is kind of a niche thing.

Those 3 languages are likely to be around forever.  Every other language is just passing through (PL/I, Pascal, Modula, Algol, etc).  Anybody remember PL/I?  I used it to write an 8080 assembler in grad school.  I struggled with the transition from Fortran to PL/I but, in retrospect, I should have spent more time with the language.  There was even a version for CP/M (which I still have).  Think about it!  PL/I on an 8 bit 64k machine.

[nctnico]

Agreed and recent survey shows this as well: https://groups.google.com/forum/#!topic/comp.arch.fpga/fN6nsmi--u0

Hardware engineers are some of the most stubborn people I ever interacted with, and often this stubbornness is to their peril. But even they are slowly realizing advantages of SystemVerilog/SystemC for verification, and only continue using VHDL because of their stubbornness (as it doesn't make any technical sense whatsoever). But obviously this is only a temporary state of affairs, and no matter what some people want, single language is always better than multiple. So for beginners learning VHDL is a pure waste of time because they invest time into dying technological dinosaur. Their time will be much better spent learning SystemVerilog.
And I know VHDL folks over here will keep arguing until cows fly, but the history has plenty of examples of what happens to those who try to go against technological progress. Unless they want to share their fate, they will have to adapt.

That is wishfull thinking. To me Verilog looks like completely unstructured gibberish long before I even started working on FPGAs. SystemVerilog is much the same so even with VHDL hacked into Verilog (what they now call SystemVerilog) I wouldn't start using SystemVerilog. I'm sure I'm not the only one.

[SiliconWizard]

Nice flame war guys.
And the author is probably now even more confused than when he first created the topic. 

[NorthGuy]

Anybody remember PL/I?

I do. You don't need to declare variables. Anything which starts from I to N automatically becomes integer. It's a nice feature when you work with punch cards.

Just pure coincidence, but most of the integers I use in C start from a letter between I and N

[DocOptics]

I had a requirement about 5 years ago to get into FPGA design.  Here is how I did it from zero to doing it as part of my professional life.

Which FPGA board?
Started with a DE0-Nano board.  It was cheap and has some on-board bits a pieces (LEDs, switches...)  That meant I started down the route of the Altera toolchain.  A month or two into learning (which was helped by the Altera website which had loads of video tutorials and documentation about FPGA design) the requirement changes as the company policy is to use Xilinx hardware...

2nd board was a Papilio One (Xilinx Spartan 3).  Used this to learn how the Xilinx toolchain works.  Has fewer on-board bits, but lots of I/O headers (0.1 inch!) so interfacing my own hardware (more LEDs and swithces) to it was easy.

At this point the professional requirements starting kicking in, so my next couple of boards were:
Avnet Spartan 6 microboard.  Cheap.  Has Ethernet and a few 0.1 inch headers.  Had the added advantage that at the time the Xilinx license that comes with it also unlocks the full ISIM simulator and ChipScope. (It might still do - haven't looked)  Learnt all about Ethernet MACs, and encoding for data transmission.

SP605 Development Kit (Spartan 6).  At the time expensive.  Used it to learn all about the horrors of using SDRAM in a design.  My main goto development board at the moment.

Recently I have moved onto AC701 development boards, as Xilinx don't seem interested in updating ISE (series 6 FPGAs), and it is all Vivado (series 7+) with them now.

Which language?
Asking this is always guaranteed to start a religious war.
I selected a language by using both VHDL and Verilog for a few weeks each, and seeing which one clicked in my brain quicker.  Try writing the blinky LED in both see which you prefer.  Both are equally weird languages in their own way.
I now use Verilog (as ISE doesn't support SystemVerilog) but I am migrating to SystemVerilog as Vivado supports it.  As a longtime C++ user I prefered the syntax of Verilog.
Whichever language you choose, repeat "I am designing hardware, not software" until it sticks.

To simulate or not to simulate?
Depends what you are doing.  To start off with I found not simulating fine; I was only building small designs that took a few seconds to run through the tools (and ISIM evaluation version has some limitations on design size).  As I got into building large systems the times got longer it become easier to write testbenches and simulate it.  Once I had a decent simulator and built up my library of HDL I now tend to simulate most things first.  My largest designs now take about an hour to simulate, but take about 3-4 hours to synthesize fully - time is money...

Hope this clarifies your thinking

Gavin

[nctnico]

Whichever language you choose, repeat "I am designing hardware, not software" until it sticks.

Definitely no to that! It will result into long winded code because you are basically writing netlists. It is kinda like writing a program in C and use inline assembler. Xilinx (for example) has good documentation on how the synthesizer converts HDL into FPGA building blocks efficiently. THAT is what you need to learn because that allows you to do a lot with only a few lines of code.

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.

In the end you aren't describing hardware at all but logical equations / functions!

[rstofer]

Nice flame war guys.
And the author is probably now even more confused than when he first created the topic. 

Why should he be any different than the rest of us?  We're all going to tout the language we use and, in doing so, perhaps we give examples of why (didn't happen in this case).  In so doing, perhaps we influence a decision that actually helps.

In the end, it's just an opinion.  More often than not, for professionals, there is no choice.  The company chose long ago.

Harris and Harris in "Digital Design and Computer Architecture - ARM Edition" and in their earlier MIPS edition present SystemVelilog and VHDL side by side for all of their code examples.  This might be an ideal way to compare the languages on a real project.  Let's face it, blinking LEDs don't really provide an opportunity to compare much of anything.

[NorthGuy]

Recently I have moved onto AC701 development boards, as Xilinx don't seem interested in updating ISE (series 6 FPGAs), and it is all Vivado (series 7+) with them now.

ISE supports some of the Artix-7 chips.

ISE also has XDL, which is analogous to assembler language for MCUs, but I don't think anyone actually uses it.

[suicidaleggroll]

I think several people here are forgetting what it's like to be new to FPGAs.  So much of the HDL languages is only valid in simulation, trying to start out with simulation is absolutely the wrong way to go about it in my opinion.  Writing synthesizable code AND a simulation test bench for it is like trying to learn two languages at once.  I found it much simpler when I was first starting out to focus solely on synthesizable code, debugging on actual hardware.  Only after learning the ins and outs of the language did I start exploring simulation, and all of the added syntax and options that come with it.  I tried doing simulation at first, but I just kept getting thrown by what syntax was allowed where, it's too much for somebody just starting out in my opinion.  Not to mention the fact that debugging on actual hardware is far more rewarding and encouraging for someone starting out than just some virtual bit flips on a trace on a screen.

[nctnico]

I tend to agree. I'm only using simulation on FPGA designs which take very long to 'compile' and even then I only simulate the part I'm adding/changing.

[DocOptics]

Recently I have moved onto AC701 development boards, as Xilinx don't seem interested in updating ISE (series 6 FPGAs), and it is all Vivado (series 7+) with them now.

ISE supports some of the Artix-7 chips.

ISE also has XDL, which is analogous to assembler language for MCUs, but I don't think anyone actually uses it.

Thanks.  I know it supports Zynq, but didn't realise it supported some Artix 7 FPGAs.  It is still dead in the eyes of Xilinx..

Gavin

[DocOptics]

Whichever language you choose, repeat "I am designing hardware, not software" until it sticks.

Definitely no to that! It will result into long winded code because you are basically writing netlists. It is kinda like writing a program in C and use inline assembler. Xilinx (for example) has good documentation on how the synthesizer converts HDL into FPGA building blocks efficiently. THAT is what you need to learn because that allows you to do a lot with only a few lines of code.

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.

In the end you aren't describing hardware at all but logical equations / functions!

Let me expand on that comment.

It is really getting into the correct mindset.  Often I have seen beginners trying to write programs (a sequential set of instructions) in HDL.  This leads down a bad path.  The designer should be thinking "all this happens simultaneously".

By all means use the higher level abstractions your favourite HDL provides; who wants to write more than they need to?

Gavin

[nctnico]

Parallel versus sequential is definitely something you need to wrap your head around. What doesn't help with that is that the order of statements does matter in HDL as well and assignments can be silently ignored by the synthesizer. For clarity it would be nicer to allow only one assignment.

[SiliconWizard]

Why should he be any different than the rest of us?  We're all going to tout the language we use and, in doing so, perhaps we give examples of why (didn't happen in this case).  In so doing, perhaps we influence a decision that actually helps.

This was clearly getting to the typical language flame war without any real added value. As you just said, giving articulate arguments could have helped, but it didn't happen. Merely stating that one is just better and the other is outdated or crappish leads to nowhere. We have seen that constantly happening on forums and newsgroups about C vs C++ vs Java vs you-name-it, VHDL vs Verilog vs SystemVerilog vs SystemC and it usually leads to nowhere. Many people have predicted (and will predict) the demise of this and that just based on how long it has existed, and the newcomer taking over the whole world, and it has never proven to be right until now. This is moot, all of these languages are widely in use today and each for good reasons. (Although SystemC is not that widely used.)

In the end, it's just an opinion.

Yes, so it's best to state it and hopefully with a rationale, so that gives something to think about. Raw opinions without rationales rarely help people making informed decisions.

More often than not, for professionals, there is no choice.  The company chose long ago.

That's right. From an historical point of view, VHDL has been prevalent in Europe and Verilog in the US. So that just adds up to the probablity of flame wars, even more so than with other languages.
Of course, there are now many exceptions to this rule. But this is something to keep in mind.

As others have said, language-wise, the best approach would be for a newbie to take a look at the various options (excluding the very 'exotic' ones) and see what best clicks for a start. The real point being to learn HDLs and how to develop digital designs more so than learning a specific language. Then if there is ever a specific company that he/she would really be interested in working at, getting to know what HDL they use would help deciding, at least for the short term.

As for me, I find VHDL much more readable, capable and maintainable than Verilog. Some find it verbose, that's something to consider. (And I've been using C as my main programming language for a long time, so saying that C developers are more inclined towards Verilog is not necessarily true at all.) I don't know much of SystemVerilog, so I can't really compare, but as I reckon, it's mostly Verilog with extensions for the RTL part, so for beginners, it probably won't make much of a difference. It's much more capable for verification though, but I've never really tried. You can also do very decent verification with VHDL. One other point to consider is that SystemVerilog is still partially/or unsupported in many existing tools.

Other points that come to mind: there are many processor cores that are written in Verilog, so that would be useful to master Verilog if you intend to get into this business or at least intend to use one in some project. On another level, I think VHDL is still the language of choice in system-critical designs, including the military, in a lot of countries.

But again, what's important for a beginner is grasping the concepts of HDLs and digital design.

And finally, for a more practical approach, since the author is interested in the "MiSTer" board, there are several example projects for this board in the repo that are written in Verilog. Something to think about.

[rx8pilot]

Did anyone mention the Nandland Go Board?

Simple intro to FPGA development without much distraction from fancy advanced stuff. Cheap enough that there is no tears when you outgrow it, yet enough toys to dig your heals into FPGA world.

Russel has some well considered and plentiful YT videos that a beginner can follow along. Seems like a great place to start.

https://www.youtube.com/channel/UCsdA-aNqtMA1_2T15aXePWw
http://nandland.com/

[mac.6]

and supported by Icestorm, so less hassle working trough the software itself as it is relatively straightforward (you just need to learn how to instantiate special IO block and PLL in the code).

[mikeselectricstuff]

Video on VHDL Vs. Verilog with some stats :

[mac.6]

If amateur, choose one and be a dick about it. If professional then you need both and systemVerilog also.

So in the end it doesn't matter really...

[james_s]

I've observed far more rampant elitism in the FPGA development community than anywhere else in my hobbies. Perhaps the only place I've been with a worst case of that is the hardcore Linux guys which unfortunately drives many less technical people away from what is otherwise a great OS. I suppose it's unavoidable when you have such a small group of people working with something esoteric that is by any measure difficult to learn. My goal is to expand this community and get as many people playing with FPGAs as possible, even if most of them never approach a professional level.

When it comes to languages, the verbosity is one of the things I like about VHDL and as someone who thinks in a very literal way it meshes well with the way my mind works. I can type faster than I can think in many cases so having to type more is not really an issue. Having started out in VHDL and gotten the hang of things I later found I was able to pick up and understand Verilog relatively easily however previously it looked to me as someone else here said, incomprehensible gibberish, like trying to read my mother's shorthand cursive notes. Liberal use of comments is important in any language but even more so with Verilog.

Whatever the case, starting out is very difficult, or was for me. It took me about 2 years of on and off tinkering before something finally clicked and I got to where I could write HDL from scratch and it would more or less work in most cases after fixing a few typos. I initially started playing with the simulator but found it boring and abstract, making actual hardware *do* something is far more engaging, then once I had the basics down I went back and revisited simulation. Even so a lot of the projects I do are simple enough that it's unnecessary, or major blocks like softcore CPUs and ASICs have already been developed and simulated by someone else so I don't need to reinvent the wheel.

[NivagSwerdna]

I've decided to get slightly side tracked.... thought I would play with 22LV10 whilst I get my Quartus II issues sorted.

[nctnico]

If amateur, choose one and be a dick about it. If professional then you need both and systemVerilog also.

So in the end it doesn't matter really...

I'd be carefull with these kind of statements. In my experience it takes time to master a language well enough to take full advantage of it. Learn 3 languages and you triple that time. What you are proposing is like learning all the ins&outs of C, Java and Pascal and their libraries.
Besides that I've been working with FPGAs for nearly 20 years and never needed anything else other than VHDL.

[NorthGuy]

So in the end it doesn't matter really...

...

Besides that I've been working with FPGAs for nearly 20 years and never needed anything else other than VHDL.

Do you mean, if that was Verilog (instead of VHDL), it would make huge difference in your life?

<edit>Voulez-vous dire, si c'était Verilog (au lieu de VHDL), cela ferait une énorme différence dans votre vie?

[james_s]

Anything you can describe in VHDL can be described in Verilog and vice versa. It's not like a traditional programming language where you see large variations in what is possible or in the performance of the finished product. No matter which HDL you use, the end result in the FPGA fabric is largely the same. Now there are caveats of course, it's possible to write code which will synthesize as a giant mess, and there are certainly optimizations that can be done but it's not the same as a traditional programming language and it applies to any HDL. Making your code more compact has no direct bearing on he ultimate result.

I don't understand the religious war, in the end it doesn't matter. Most of us hobbyists working with FPGAs have no intention of doing it for a living, and most of us are not building anything very complex, for me if it takes 10 minutes to synthesize that's a *really* big project. Spend some time playing with the languages available and pick the one you like the best, resting assured that you can achieve exactly the same result as someone else using a different language. The language itself is only a small part of the equation anyway, the more important aspect is the design itself that you're trying to describe.

[rx8pilot]

If amateur, choose one and be a dick about it. If professional then you need both and systemVerilog also.

So in the end it doesn't matter really...

I'd be carefull with these kind of statements. In my experience it takes time to master a language well enough to take full advantage of it. Learn 3 languages and you triple that time. What you are proposing is like learning all the ins&outs of C, Java and Pascal and their libraries.
Besides that I've been working with FPGAs for nearly 20 years and never needed anything else other than VHDL.

True.....choosing wisely at the beginning is very important since time is not unlimited.

[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.