Getting started with FPGA

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