UPDuino: a $9.99 FPGA (tinyletter.com)

Pretty much anything from Digilent. I've got an old Spartan6 board that has a boatload of horsepower. If you want to get fancy, look at the Zedboard family -- FPGA wrapped around ARM cores.

My standard to-go-to FPGA is an Cyclone II EP2C5T144 development board. On a good day, you can find them for less than $5 on eBay.

You'll need a USB blaster to program them, which adds another $10 or so.

They are small, but they are still large enough to add a little CPU with a little RAM, plenty of hardware multipliers etc.

I always recommend the DE0-Nano. It's getting a little old, but it's basically all right there, open for use. I'm a fan of the Arrow DECA which has a complete assortment of neat odds and ends. Lastly Digilent's Arty and CMOD series are awesome depending on what you need.

I know this makes a few assumptions on what you mean by "Cheap", but I find sub $200 for FPGA boards to be pretty affordable when compared to the gamut.

Well... "cheap" is relative, but the Ice40 boards from Lattice are reasonably priced IMO. And more to the point, there is a complete Open Source toolchain available for programming them. That's a big plus in my book.

https://www.digikey.com/product-detail/en/lattice-semiconduc...

http://www.clifford.at/icestorm/

There is a large list here (including this one): https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards The ICE40 chips are the ones supported by the open source icestorm toolchain.

Yes, it can: https://github.com/grahamedgecombe/icicle

Just announced is another project that's doing just that

https://www.cnx-software.com/2018/09/04/licheetang-anlogic-e...

At $10 shipped I'd just get a new one. I don't think there's any reasonable expectation of support here.

Here's a decent getting-started: https://medium.com/@luke_73359/getting-started-with-icestorm...

There isn't really a go-to IDE that everyone uses. Each vendor have a proprietary IDE and they're all very bad. Lattice FPGAs have an open-source toolchain, but it's all command-line tools so you're left to build your own workflow of choice.

You can write Verilog or VHDL (the two main hardware description languages used to design circuits) in any text editor you choose and verify the basic functional correctness (verifying that it implements the logical behavior you want) in a simulator like Icarus Verilog.

However to verify the behavior on the FPGA and actually program it into the device you'll usually need some vendor specific tools, for Xilinx (what I'm familiar with) you'll need a software package called Vivado. It provides information on whether or not the timing you've requested is possible, whether any part of the chip will get too hot, whether the design actually fits in the limited resources of the FPGA, as well as implementing, optimizing and outputting the design to the FPGA.

Lattice has an open source toolchain available at least for some of their devices, for Xilinx there are efforts to produce a reverse engineered toolchain but I don't know how functional they are, there are free (but not libre) versions of Vivado as well but you'll need to fill out US export paperwork and it doesn't support all Xilinx FPGAs unless you pay. I don't know what the story is with Altera.

The equivalent tooling for FPGA programming is starting with a high level hardware description (typically Verilog or VHDL) then

- synthesis -- this converts the text description from HDL into gates (fun fact you can write valid HDL which cannot be synthesized into hardware)

- place & route -- this takes what is essentially a schematic from the first step and assigns it to resources within the FPGA. This is also where you specify which pins on the FPGA you want to be connected to the schematic outputs.

- timing closure and simulation -- This is the process where the FPGA place and route core is trying to either make your design fit in as few gates as possible or run as fast as possible (these choices often conflict so you have to prioritize one over the other)

- bitstream generation -- This is where an often encrypted stream of bits are generated such that if they are fed into the FPGA they will set all the internal switches etc to realize the design you've put together.

- programming/flashing -- most systems use JTAG to do this.

When I started doing FPGA designs the hardest part for me was to break the notion of "software" when I was writing VHDL. You have to keep your head in the 'one clock' every variable gets to change exactly once in this block.

For FPGAs you generally have to use the IDE that the vendor gives be it Xilinx, Altera or Lattice. You can do the coding in Verilog, VHDL or component layout. You can also start with simulation using free stuff like Icarus Verilog or TKCircuit. Those tools are much simpler to get started.

At once very cool and potentially very sad to me. Sad to think that skilled engineers are being underpaid because they lost the geographic birthplace lottery.

The terrible routing of the board does actually impact the device though - the decoupling and power distribution is so messed up that PLLs do not lock on it [1]. Also the lack of a proper external clock means you have to rely on the +/- 10% internal 48MHz oscillator.

[1] - https://twitter.com/oe1cxw/status/950083493073178625?lang=en

And on component sourcing, reading from further down the thread (https://www.element14.com/community/groups/fpga-group/blog/2...)... actually I won't spoil it, go find out where the flash chips came from yourself.

(Or... perhaps they weren't refurbished/reused, and we just discovered one manufacturer's test image?!)

Start with digital logic fundamentals(not, or, and, xor, xnor gates, flip-flops(d, jk, etc). It helps to know some analog theory so you understand propagation delay and such. Then you'll probably want to learn a language like Verilog or VHDL. From my experience, most people like Verilog and VHDL is mostly used in the defense industry.

You could probably skip right to Verilog/VHDL, but I really suggest having a background in digital logic.

FWIW, I'm just an embedded software guy. I came from an EE background but it's been a long time since I've played with programmable logic.

if practicality is a concern at all, then you can get stm32's for about that which will have significantly more power than you'll be able to cram into a $5 FPGA, and the development environment will actually be pleasant.

(or just buy them, there's at least one on crowd supply, another was on kickstarter in the last couple years, etc)

You can synthesize a 6502 on an FPGA just fine and can probably do it on this specific chip. There is a project I've seen (https://danstrother.com/fpga-nes/) where someone did synthesize the 6502 along with the rest of the hardware on a Spartan 3 which does have more resources available to it. Looking at the utilization report in the comments on that page, it would be too much for this little Lattice chip. There are other FPGA development cards out there similar in size that would work better for your idea. You would be better off getting a larger development card for designing and then moving to some custom PCB that fit only the components you need at the size you want.

The FPGA seems to be a ICE40UP5K which has 5280 logic elements each configurable to any Boolean function of up to four inputs plus a flip-flop to store the result. Wikipedia gives two numbers for the transistor count of the 6502 namely 3,510 and 4,237 but both are smaller than the number of logic elements so fitting a 6502 should be easily possible. The FPGA has an integrated 48 MHz clock so a 2 MHz designs also seems quite achievable. I can not tell whether the remaining logic elements, the memory, and the I/O blocks are sufficient to build everything else because I know essentially nothing about the NES. It seems at least not wildly implausible to me but memory might become an issue because there is only about one megabit on the FPGA.

Choosing FPGA = learning, how to be independent from ASICs, which have more and more "hidden security parts" like Intel ME, AMD PSP, ARM TrustZone...

For hobby projects?

Multiple reasons:

- because writing RTL is fun, while writing C code is boring. :-)

- because it's probably not possible to outputs VGA with your standard microprocessor. You can create a dinky 3-bit VGA output with very little hardware.

- because I may want to DMA data from an external sensor and feed it straight into a DSP for processing, and only use the CPU to deal with the post-processed result. Think multi-channel audio etc.

- because anything that requires fast real-time is probably not possible with the standard microprocessor.

But mostly because writing RTL is fun.

Amazing answer from stackexchange:

ASIC VS FPGA

A Field Programmable Gate Array can be seen as the prototyping stage of Application Specific Integrated Circuits: ASICs are very expensive to manufacture, and once it's made there is no going back (as the most expensive fixed cost is the masks [sort of manufacturing "stencil"] and their development). FPGAs are reprogrammable many times, however because of the fact that a generic array of gates is connected to accomplish your goal, it is not optimised like ASICs. Also, FPGAs are natively dynamic devices in that if you power it off, you loose not only the current state but also your configuration. Boards now exist though that add a FLASH chip and/or a microcontroller to load the configuration at startup so this tends to be a less important argument. Both ASICs and FPGAs can be configured with Hardware Description Languages, and sometimes FPGAs are used for the end product. But generally ASICs kick in when the design is fixed.

FPGA VS microcontroller

As for the difference between a microcontroller and a FPGA, you can consider a microcontroller to be an ASIC which basically processes code in FLASH/ROM sequentially. You can make microcontrollers with FPGAs even if it's not optimised, but not the opposite. FPGAs are wired just like electronic circuits so you can have truly parallel circuits, not like in a microcontroller where the processor jumps from a piece of code to another to simulate good-enough parallelism. However because FPGAs have been designed for parallel tasks, it's not as easy to write sequential code as in a microcontroller.

For example, typically if you write in pseudocode "let C be A XOR B", on a FPGA that will be translated into "build a XOR gate with the lego bricks contained (lookup tables and latches), and connect A/B as inputs and C as output" which will be updated every clock cycle regardless of whether C is used or not. Whereas on a microcontroller that will be translated into "read instruction - it's a XOR of variables at address A and address B of RAM, result to store at address C. Load arithmetic logic units registers, then ask the ALU to do a XOR, then copy the output register at address C of RAM". On the user side though, both instructions were 1 line of code. If we were to do this, THEN something else, in HDL we would have to define what is called a Process to artificially do sequences - separate from the parallel code. Whereas in a microcontroller there is nothing to do. On the other hand, to get "parallelism" (tuning in and out really) out of a microcontroller, you would need to juggle with threads which is not trivial. Different ways of working, different purposes.

https://electronics.stackexchange.com/questions/150058/what-...

You can program an FPGA to work like a microprocessor, or pretty much any other digital circuit that fits. They are great for teaching students about computers and hardware design languages.

Most FPGAs are essentially grids of little devices which are programmed to map a certain input pattern to a certain output pattern. Like, 0000 -> 0101, 0101 -> 1111. They emulate logic gates. When you program an FPGA, you are both programming these maps, and setting the connections between them.

(Note: efficient means processing power / electrical power)

ASICs, on the other hand, are custom-built ICs which are designed to very efficiently perform one task, like performing SHA hashes or h.264 decoding.

FPGAs can be more efficient than full-fledged processors because they can make use of custom combinational (combinations of gates) logic along with sequential (clocked) logic. ASICs can be more efficient than FPGAs.

Essentially, there's a tradeoff between development cost, unit cost, efficiency, and flexibility.

                 flexibility    development cost    unit cost   efficiency
    processor        ++             ++                 -            -
    FPGA             +              +                  --           +
    ASIC             --             --                 ++           ++

You chose fpga when you have yo handle bit streams with a precise clock to interface with a hardware, for example a screen or camera.

It is very difficult to have a precise timing with a microcontroller unless you have a good one with timers. It becomes impossible to do when you need to toggle several pins at the same time quickly (like a pci bus). You overcome the problem by adding a fpga to your microcontroller board, which will handle the bit flipping and communicate to the micro with a standard bus like spi or i2c.

You are correct enough here. The interesting question is not how they are different, but what the advantages are.

An FPGA is really good at doing a single task a ton of times. A microprocessor is good at doing a lot of tasks a ton of times. And an ASIC is just a more permanent and more efficient FPGA.

So when would I use an FPGA? Let me describe an example: Stream processing.

Let's say I have a stream of data. Like a camera producing a video feed. As each frame of data comes in, we want to compare it to the previous frame and take the average of the two values to create a blurring effect.

On a microprocessor we process each frame. We iterate over groups of pixels one at a time, compare it to the value at the pixel in the previous frame and divide by two. Our processing time is a function of the number of pixels we want to look at. If we're lucky we have multiple cores so we can do work in parallel. Maybe even do 32 groups of pixels in parallel on a ryzen or something. But if we have a 1 megapixel image, we're going to still have to visit ~30k pixels sequentially on each core and perform some math. We're probably adding at least a few ms of lag on the feed. And if we're trying to do any multitasking on this cpu, then we may not have very predictable performance.

On an FPGA we approach the problem very differently. Instead of having sequential logic for visiting each pixel, we have combinatorial logic. Supposed each pixel came through on a different wire. That wire goes into a component that holds the previous value for the pixel and outputs the average of the current and previous value. We then take that output and rebuild the video feed with it. On a 1 megapixel image, our unit of work is a single pixel and we have concurrency of 1 million units. We add a cycle or two of lag, which is negligible. Additionally, we have very predictable performance because our computation executes in lock step with the system clock.

FPGA's are expensive (per unit cost) and aren't always the most efficient. An ASIC will drop per unit cost and power requirements significantly but has a large up front capital investment.

I think you have it pretty close. Also FPGA are good for low volume custom circuitry. ASICs are good for high volume custom circuitry. And things are a hybrid of the three these days. Something like a cell phone has a ASIC with standard features like an ARM core, cellular communications, WiFI, display controllers.

FPGAs can have hardware parallelism. And not some specialized SIMD instructions, but the one kind of parallelism you need.

FPGAs can have deep pipelines, so instead of taking data from the memory, working on it, storing it back and moving to the next, you can take serial data, process it in multiple stages and only writing to memory at the end.

FPGAs can have deterministic timing (with a clock). So you can synchronize stuff in parallel, you can have it respond in nanoseconds, you can follow a signal without losing any sample.

FPGAs can have complex pipelines, so you can take an earlier response from the system, but continue processing your data for a more elaborated response later, without performance loss.

When you are talking about small ones like this a common reason I don't see mentioned here is peripheral flexibility. A processor is going to come with a fixed set of peripherals what happens if you need 10 UARTs but the processor only has 3? An FPGA can solve that problem.

An FPGA is not the same thing as a microcontroller. Field Programmable Gate Array: An FPGA can be a microcontroller, but a microcontroller can only pretend to be an FPGA. Your microcontroller was probably prototyped on an FPGA.

ASICs are basically FPGA designs etched onto permanent silicon.

Thank you for linking to at least one page on the company site. The https://tinyletter.com/ article links to it only very obscurely around an image. There are many normal links in the article, so I assume the failure to link clearly to the product under discussion was just an oversight.

As someone who just started getting into it, it's kinda hard to come up with an application until you have one and know how to use it a bit. I bought an icestick not knowing what I was going to do with it, but now I have quite a few ideas. They can be useful in robotics, as glue logic, for sensor fusion or for very precise real-time applications.

apio is a command line tool that automates installing the toolchain for your FPGA and running it. It just simplifies things, you don't have to use it if you'd rather call the individual tools for synthesis, P&R, simulation etc. It'd be reasonable to think of it as akin to a very smart Makefile combined with an automatic package manager, specialized to FPGAs (it's based on PlatformIO). It's nice when you're still kind of getting oriented, because you don't need to know how to set up and invoke the different tools... just call `apio build` or `apio simulate`.

You aren't going to be able to build a super-fast CPU on an FPGA but there are plenty of other tasks you could give it. You can build a processor for analyze multiple sensors, looking for specific events that you could then feed to the uC or setup a DSP pipeline to filter the sensor data to look for patterns. The nice thing about an FPGA is that there is no interruption when it's running. The uC might be trying to feed data over wifi to the controller station and polling sensors/analyzing sensor data is going to bog things down really quick. Another task for an FPGA would be to act as a switch for a network within the robot. It would sit between all of the sensors/actuators and an ethernet-enabled uC located elsewhere in the robot. The FPGA would read command packets from the uC and translate tasks like "read temperature sensor #5" or "turn 15 degrees" into specific impulses on the pins while also turning sensor and feedback data into packets to send back to the uC. You could even run video feeds from cameras back to the uC over gigabit if the FPGA supports it. This way you can run a cheap, small uC to control things from a higher level while the i/o-plentiful FPGA does all the heavy lifting at 100Mb/s speeds.

Typical uses for FPGAs in robotics include basic processing on the high bandwidth bitstreams from cameras or laser scanners into a format / representation more easily handled by the main CPU (building a depth map from the raw laser scanner photodiode stream, for example).

They are also used on the motor control side, though these days a motor control mcu may be more practical in most cases today.

Decoding rotary encoders is a common task, and very hard to do with Microcontrollers at either high event rates or multiple instances.

Maybe even turning a brushless motor with an encoder into a servo motor.

My main idea for using FPGAs would be talking to a couple of i2c/spi sensors and reducing the data rates. Some sensors only have one or two possible i2c addresses, some require multiple requests to get a limited amount of data, reducing the polling frequency.

A useful example project would be an FFT or OFDM accelerator for a microcontroller. Most microcontrollers really struggle with FFT so it is an example where a small uC and a small FPGA can be cheaper than a large uC. Sliding window FFT is going to be another good example where the FPGA option is competitive.