FPGA recommandations for education

[curiouspat]

Hello!
I'm looking for recommendations for FPGA dev boards to use in introductory electronics classes (technical program). I currently use Altera MaxII FPGAs (CPLDs) on custom boards with the associated Quartus software. This software allows me to program the chip using a graphical tool (i.e. pick and place components and wire them together) rather than use Verilog. Boards are getting old and Quartus is buggy and capricious.

The lab activities I currently do revolve around simulating simple logic circuits (counters using flip-flops, 555 timers, registers, etc.). I don't have time to teach my students Verilog. I realize FPGAs are overkill for this but I'm also interested in more advanced projects for other classes such as implementing soft-processors.

Any FPLDs/dev boards/programming software combo recommendations that would allow me to do this?

Main criteria:

• simplicity
• graphical programming tool (pick and place)
  
• durability
  
• easy interfacing
  

Thank you! 
Patrick

[Laurencewilliams]

There are several FPGA development boards and software tools available that might meet your requirements:

• Xilinx Zynq FPGA Development Board and Vivado Design Suite: The Zynq-7000 All Programmable SoC is a popular platform for teaching electronics and digital design. The Vivado Design Suite provides a graphical programming environment for designing digital logic circuits and implementing soft processors.
• Altera Cyclone V FPGA Development Board and Quartus Prime: If you are already familiar with Altera's Quartus software, the Cyclone V FPGA is a good choice for an introductory electronics course. The Quartus Prime software provides a similar graphical design environment to what you are currently using.
• Digilent Nexys 4 DDR Board and Xilinx Vivado Design Suite: The Nexys 4 DDR board is a versatile FPGA platform that can be used for both simple and advanced projects. The Xilinx Vivado Design Suite provides a graphical design environment and easy interfacing capabilities.
• Lattice iCEstick Evaluation Kit and Lattice Diamond: The iCEstick is a low-cost, easy-to-use FPGA development platform that includes the Lattice Diamond software. Lattice Diamond provides a graphical design environment and supports a variety of programming languages, including Verilog.

It's worth noting that the availability and support for these platforms can vary depending on your location, so it's a good idea to check for local distributors and support before making a purchase.

[hamster_nz]

If you want simplicity you have come to the wrong place, on so many levels.

At it's core digital logic can be all NOR or NAND gates and wires, so it looks as if it should be simple, but even the primitive logic blocks on FPGAs require 100+ pages of documentatiion to fully explain. Then there is I/O structures, and clocking structures.


Far better to stick with graphical simulation software, or maybe 7400 logic on a breadboard or a PCB with jumper wires if you need a physical experience.

[BrianHG]

FPGAs are tough, really tough.  Learning the wrong way around, like using a graphical interface, will only cause problems in the future whe you want to advance above creating designs to replace a few logic chips with an old schematic entry tool will become useless.

For education, I would stick with 74LSxxx/74HCxxx and bread boards to learn logic.

Then I would learn either System Verilog or VHDL programming language in how to describe the logic you want which you have learned with the discreet 74HCxxx IC'.

To learn these HDL (hardware description languages), I would use 'Modelsim' which came with Quartus 20.x and earlier, and it is also integrated into other third party FPGA compilers like Lattice & Xilinx.  Modelsim is an HDL compiler and simulator all on it's own and allows you to fluidly manipulate your HDL code and re-compile and see immediate results onscreen without any FPGA dev board.

Then finally, once you can make HDL code in modelsim, you can bring your HDL code into Quartus to fit into a selected FPGA and assign the IO pins.

Using the graphical entry will leave you in a world of hand wiring schematics 5-10x more complicated than writing the equivalent HDL code and you will never design anything more complicated than a design with something like 10-20 TTL ICs, or be able to use your learned skills for any modern commercial professional work.

[rstofer]

I spent a lot of my undergrad and postgrad dealing with logic design, I really LIKE FPGAs.  They're just like a dumpster full of 74xx and some memory chips thrown in.  Have at it!

The Lattice IceStick is a really nice entry level FPGA board as is the NandLand GO Board.  They're just the beginning in terms of capability but at least the GO board has enough switches and LEDs to do simple logic functions and display the output.

The VHDL to create simple logic gates is pretty simple.  Getting the IO pins lined up is a little more difficult but NandLand provides tutorials.

https://www.latticesemi.com/icestick

https://nandland.com/the-go-board/
https://nandland.com/learn-vhdl/

Given a brief lecture and access to the tutorials, I would expect things to work out fine.

Or, use 74xx chips and call it good.  Do note, however, nobody is using 100 chips when a single FPGA will do that many times over.  Think in terms of hundreds of thousands of logic gates.  When Xilinx rated their chips in gates, I used a Spartan 3 with 1.2 million gates.

I don't know what a Logic Cell is, exactly, but there are over 100,000 of them in a Artix 7 100T, my current favorite chip.  That's a metric boat load of logic!

Not the little guys I linked above, of course.  But they're a good place to start.

More tutorials at VHDLwhiz.com for the Lattice IceStick and VHDL,

[agehall]

Either go 100% virtual and just simulate everything using appropriate software or go back to basics and use breadboards.

If you go for more advanced topics in the classes, like soft cores etc, you have an actual use for a CPLD or FPGA. But until you do, I would go the software only route.

[laugensalm]

Hi,

if it's just supposed to be an entry course for HDL, I would recommend to not put any priority on the FPGA technology as such and stay away from the vendor specific graphical solutions, even though this may have had some success in the past for the elegant and somewhat popular Papilio/ISE setups.

If the targeted incentive is sufficient to be:
- a blinking LED: I'm seconding the approach of putting something together out of old 74 logic on a breadboard.
- a correct waveform output: Dry dock setups with any open source simulator will do, for simple logic you can get by with qucs or similar

A few years ago I've had some fun with Jupyter Notebooks running MyHDL to create logic via yosys within a Binder environment, thus no need for any student to install software. The learning curve is a little steeper, but people then understand how synthesis basically works and how HDL is turned into logic primitives on an FPGA and finally verified to synthesize correctly (and eventually downloads to a supported FPGA). However, as always, there's a lot of controversy on Python HDLs, especially since MyHDL has exposed quite a few maintenance issues. If you'd still want to go down that road and invest some spare hacking time, I'm happy to send a few pointers.

[jmelson]

Years ago, I got into CPLDs and FPGAs using Xilinx parts and schematic entry.  The Xilinx-supplied schematic package by Aldec was awful, but I discovered that my favorite package (Protel 99) had a schematic library for FPGAs and could output VHDL.  This looked like a great way forward, but the format it produced was sligntly different than what Xilinx wanted.  For instance, any canonical parts like FFs should have only been decalerd ONCE, but they were declared as many times as they were instantiated.  So, you had to hand-edit the extras away.  Also, Protel's component library had been entered by a "secretary" who had no concept of joined nets vs. crossing lines.  So, there were no connection dots in their parts.  I had to go in and fix all those 4-bit counters, etc.  What a PAIN.

Anyway, I finally took it upon myself to learn how to use VHDL properly, and while I DO appreciate those VERY concise schematic pages where I could put an entire quadrature encoder counter with digital filter on ONE PAGE, moving to behavioral VHDL really was a huge improvement.  Xilinx also had a graphical state machine generator, but I never was able to get that to work well.  It DID work for simple cases, but more complex ones neede several pages, and then it got very unwieldy.
Jon

[mark03]

A few years ago I've had some fun with Jupyter Notebooks running MyHDL to create logic via yosys within a Binder environment, thus no need for any student to install software. The learning curve is a little steeper, but people then understand how synthesis basically works and how HDL is turned into logic primitives on an FPGA and finally verified to synthesize correctly (and eventually downloads to a supported FPGA). However, as always, there's a lot of controversy on Python HDLs, especially since MyHDL has exposed quite a few maintenance issues. If you'd still want to go down that road and invest some spare hacking time, I'm happy to send a few pointers.

If there is "controversy" on Python HDLs it is primarily because newcomers do not understand that a Python HDL is an HDL; they may assume because the base language is Python it must be a form of high-level synthesis like Matlab-to-gates or C-to-gates, which it definitely is not.  It just gives you the ability to write your testbenches in a nice modern language.  But the inertia/momentum of the V languages pretty much guaranteed MyHDL would remain niche, which is unfortunate---it had a lot of potential.

[mark03]

I teach an undergraduate course introducing students to VHDL and FPGAs.  It's a follow-up to the basic digital logic course, where at the end they were introduced to flip flops and sequential logic.  So this whole course is mainly about designing state machines and how to describe them in VHDL.

We are using Artix-7 devices but the curriculum (inherited by me) starts them off with schematic entry.  The thinking (confirmed in my experience) is that they need to see the HDL as generating gates first and foremost, lest they start trying to "code" in HDL.  So they design some simple circuits, up to and including a basic state machine, pulling gates, flip flops, etc. from the Xilinx library.  For this we have to use ISE because Vivado removed the capability for schematic entry.

We obviously need to move away from ISE eventually.  I have thought about re-doing the first labs where they would do something simple in VHDL and then be required to interpret the generated schematics.  But typical schematic output is hard to read.  We probably need to switch those labs over to some simulation environment.

[laugensalm]

If there is "controversy" on Python HDLs it is primarily because newcomers do not understand that a Python HDL is an HDL; they may assume because the base language is Python it must be a form of high-level synthesis like Matlab-to-gates or C-to-gates, which it definitely is not.  It just gives you the ability to write your testbenches in a nice modern language.  But the inertia/momentum of the V languages pretty much guaranteed MyHDL would remain niche, which is unfortunate---it had a lot of potential.

The controversy is very much depending on the target audience, I guess. Here in german speaking academia, people typically think in separate hardware and software categories and tend to stick with conservative but awkward HDL schemes. Those already intrigued by Python solutions are more or less left with the question what to go for (i.e. MyHDL versus various migen derivatives).
The higher level HDL approaches of whatever kind (based on Python, Scala, or other functional programming concepts) won't make the V* langs obsolete (as long as there is no standard RTL intermediate representation), but my credo is these days: you'll just have to be able to read and understand them. The rest is all up to verification during development, along the lines of: Make sure what you describe runs right on the target. Early.

For all the graphical development like the omnipresent LabVIEW approaches, there is one big catch: It's mostly write-only designing, it may likely not work with future releases of the tool (or get stripped completely, as in the Vivado case), and last but not least, it won't work with revision control or some sort of complex collaborative. So for all sustainable and reusable designs, one is stuck with a language and a simulator, typically.
Thus: writing code and checking up on the inferred RTL schematic sounds like a better approach to me.
This was for example exercised for a blinky (unfortunately, that setup won't run in the public binder cloud any longer):

https://github.com/hackfin/hdlplayground/blob/master/ew2021/blinky.ipynb

The .dot output from yosys is just not very readable, there's however a nice Python framework called 'hwt' providing better RTL schematics. Not sure if/how this is on the backend roadmap of the yosys developers.

[AndyC_772]

We are using Artix-7 devices but the curriculum (inherited by me) starts them off with schematic entry.  The thinking (confirmed in my experience) is that they need to see the HDL as generating gates first and foremost, lest they start trying to "code" in HDL.  So they design some simple circuits, up to and including a basic state machine, pulling gates, flip flops, etc. from the Xilinx library.

I'd suggest this may not be an approach that's kindest to your students, or which gives them the most useful grounding in either VHDL or the wider way in which FPGAs are used.

I totally understand the desire to show how an FPGA can be programmed to behave as though it were some combination of 74 series logic devices all connected together. I get that there's a certain intuitive clarity to this - but there's also a major problem.

It used to be the case that, if an engineer wanted a device that behaves a certain way, then they'd have to work out for themselves what logic would produce that behaviour. The starting point has always been that desired behaviour, and the exercise of figuring out what combination of gates and memories might actually achieve that behaviour used to be a thing we all had to be able to do.

The thing is, we simply don't any more. That step, of figuring out manually how to map complex behaviour onto 74 series chips, is one which has been both automated and superseded. The building blocks aren't even AND, OR and NOT gates any longer; they're much more complex n-element look-up tables with clocked D-types in between.

The existence of the synthesis tool brings with it a whole different design flow. The engineer can now describe, in a clear and readable scripting language, what behaviour is required. Compared to a list of logic gates and a wiring diagram, the script is clearer, more maintainable, and much better able to describe a complex system.

We all 'get' the idea that an FPGA is a device that can be programmed to behave like a bunch of logic gates. The concept of a programmable device is a trivial, familiar one. We don't need a lab practical to prove the point.

Instead, why not develop a practical that illustrates some of the most relevant issues that crop up when developing for an FPGA; for example:

- start with a simple clocked process, which could even just be a logic gate, but with registered inputs, or outputs, or both. Or neither. Show how the clock may add latency but eliminates glitches

- show how VHDL can be used to describe complex behaviour without the need to describe every logical case independently. My favourite example for this is to calculate the write request for a FIFO, which must be: 0 on every clock edge by default, is set to 1 when some specific conditions are met that means data is available, but despite all of the above, must be 0 whenever a separate reset signal is asserted. This behaviour is trivial to describe in VHDL, and doesn't require a complex chain of if - then - else structures. Just put the assignments in order from top to bottom, explain how later assignments take precedence. This demonstrates how important it is to understand that the statements are NOT being executed one after the other, and that the resulting signal does NOT have glitches on it

- move on to consider what happens when inputs change at just the same time as the clock does. Introduce static timing analysis, ensure that setup & hold times are always met.

- then consider how data is moved from a device in one clock domain to another. What happens if the timing of one clock relative to another is unknown or cannot be controlled? It's never too early to mention double sampling or metastability, they're so fundamental to robust FPGA design that they really are day one concepts, IMHO.

[asmi]

I think the root of the problem is that a lot of people (and apparently even some of actual FPGA designers are among them) think that FPGAs contain programmable logic gates. They don't. What they do contain is lots of small memory cells called "look-up tables" or LUTs which can be programmed to perform any logical function. So a much more useful demonstration would be to pick up any parallel EEPROM chip and demonstrate how you can program it such that each of it's data outputs would perform some logic function of address inputs. That would drive home the concept of a LUT, how it works, and also will explain exactly how most FPGA's LUTs can be turned into memory (it can be called LUTRAM, or distributed memory, or something else depending on a vendor) - because they ARE the memory.

[hamster_nz]

I think the root of the problem is that a lot of people (and apparently even some of actual FPGA designers are among them) think that FPGAs contain programmable logic gates. They don't. What they do contain is lots of small memory cells called "look-up tables" or LUTs which can be programmed to perform any logical function. So a much more useful demonstration would be to pick up any parallel EEPROM chip and demonstrate how you can program it such that each of it's data outputs would perform some logic function of address inputs. That would drive home the concept of a LUT, how it works, and also will explain exactly how most FPGA's LUTs can be turned into memory (it can be called LUTRAM, or distributed memory, or something else depending on a vendor) - because they ARE the memory.

I'ld agree with you if the course was to understand FPGA technology, but if the need is to have a physical realization of simple digital logic designs (e.g. building an adder with basic gates) for an intro course then it might be better to not dive that deep, and stick at the "FPGAs are filled with an army of tiny elves that rewire thousands of simple logic gates for you" level of abstraction.

[rstofer]

Or, you could rip off parts of Ben Eater's 6502 project:

https://eater.net/6502

Specifically, the use of 28256 32kx8 EEPROMs and the chip programmer.

https://eater.net/shop


You will have a re-programmable device with 15 inputs and 8 outputs.  You can build up truth tables to implement a lot of logic functions by using some of the address bits to select the logic function and the other address bits to provide inputs.  The outputs do whatever they should given the function selected and the logic inputs.

Essentially, the EEPROM is working like a really big LUT.  An Artix 7 uses 6 input LUTS that can be split into 2 each 5 input LUTS.  See page 21

https://www.eng.auburn.edu/~nelson/courses/elec4200/FPGA/ug474_7Series_CLB.pdf

A lot of experiments can be selected with 15 inputs.  A single address can show 8 functions of 2 inputs for example.  AND, OR, XOR, NAND, NOR, XNOR, Zero and One would be one such example.  Hang an LED off of each output bit and you are ready to demonstrate the primary logic functions.

[iMo]

..The lab activities I currently do revolve around simulating simple logic circuits (counters using flip-flops, 555 timers, registers, etc.). I don't have time to teach my students Verilog. I realize FPGAs are overkill for this but I'm also interested in more advanced projects for other classes such as implementing soft-processors..

I started with FPGAs 30y back (ViewLogic) pushing TTLs from the libs into an Actel FPGA via the schematic capture (as I had had pretty experience with TTLs/CMOS stuff). I would not recommend that (wrong) approach anymore, the HDL is the way. As mentioned above do use simulators with your students when playing with simple logic circuits. Also - when the FPGAs - I would better go with cheapo boards with small CPLDs or with small FPGAs as the students usually smoke the chips soon..

[Sherlock Holmes]

Hello!
I'm looking for recommendations for FPGA dev boards to use in introductory electronics classes (technical program). I currently use Altera MaxII FPGAs (CPLDs) on custom boards with the associated Quartus software. This software allows me to program the chip using a graphical tool (i.e. pick and place components and wire them together) rather than use Verilog. Boards are getting old and Quartus is buggy and capricious.

The lab activities I currently do revolve around simulating simple logic circuits (counters using flip-flops, 555 timers, registers, etc.). I don't have time to teach my students Verilog. I realize FPGAs are overkill for this but I'm also interested in more advanced projects for other classes such as implementing soft-processors.

Any FPLDs/dev boards/programming software combo recommendations that would allow me to do this?

Main criteria:

• simplicity
• graphical programming tool (pick and place)
  
• durability
  
• easy interfacing
  

Thank you! 
Patrick

Give this a try: https://projectf.io/posts/hello-arty-1/

[Mario87]

Why not mix a bit of HDL, IP generation and block design together?

Use HDL to generate a simple function (shift register maybe, where when the input goes high an 8-bit output initialized to 8'b00000001 shifts 1 bit to the left, if a reset goes high it resets back to the initial position and when it reaches the MSB it loops back), then create an IP from it, then implement the IP into a simple block design where all you do is add a NOT gate to the input and then they can see that the shift will only occur when the input is held low, etc.

Can be done in Vivado with a Digilent Basys 3 board or similar which has LEDs on the board so you can visually see the bits shifting as a button is pressed.

If it's an introduction only class I think that is plenty sufficient to get people who might have an interest to look into FPGAs more and do proper courses. No need to go too in depth.