Mithro Runs Down Open Source FPGA Toolchains

Tim [Mithro] Ansell has a lot to tell you about the current state of open FPGA tooling: 115 slides in 25 minutes if you’re counting. His SymbiFlow project aims to be the GCC of FPGA toolchains: cross-platform, multi-platform, completely free, and all-encompassing. That means that it’s an umbrella framework for all of the work that everyone else is doing, from work on synthesis and verification tools, to placing and routing, to vendor-specific chip libraries. His talk catches you up with the state of the art at the end of 2019, and it’s embedded below. Spoiler alert: SymbiFlow has the big Xilinx 7-series FPGAs in its crosshairs, and is closing in. SymbiFlow is that close to getting a networked Linux system on the FPGA fabric in a Xilinx 7 today, completely independent of any vendor tools.

But let’s step back a sec for a little background. When you code for an FPGA, words you type get turned into a bitstream of ones and zeroes that flip perhaps a few million switches inside the chip. Going from a higher-level language to a bitstream is a lot like compiling normal programming languages, except with the twist that the resulting computational logic doesn’t map straight into a machine language, but rather into lower-level physical hardware on the FPGA. So “compilation” for FPGAs involves two steps: synthesis and place-and-routing. Synthesis takes the higher-level language that you write and turns it into a set of networks and timing requirements that represent the same logic, and can work across chip families. Yosys is the open-source synthesis tool of choice here.

Continue reading “Mithro Runs Down Open Source FPGA Toolchains”

Yosys Fronts For Xilinx ISE

We always marvel at how open-source tools can often outstrip their commercial counterparts. Yosys, the open-source tool for Verilog synthesis, is a good example. Although the Xilinx ISE design suite is something close to abandonware, a lot of people still use it because it supports older FPGAs the newer tools don’t. Its Verilog parser is somewhat slow to catch up to new standards, and according to a recent GitHub update, Yosys can now provide files for ISE that target Spartan 6, Virtex 7, and Series 7 FPGAs. In addition, there is some support for Spartan 3, Virtex 2, 4, and 5, although those are not ready yet.

According to the post, you’ll want to use the synth_xilinx command along with the -ise option and a -family option that matches your target (that is, xc6s for Spartan 6).  On the output side, you’ll write an EDIF file using the write_edif command.

Continue reading “Yosys Fronts For Xilinx ISE”

Who Could Possibly Need An FPGA With 9M Logic Cells And 35B Transistors?

Xilinx recently announced the Virtex UltraScale+ VU19P FPGA. Of course, FPGA companies announce new chips every day. The reason this one caught our attention is the size of it: nearly 9 million logic cells and 35 billion transistors on a chip! If that’s not enough there is also over 2,000 user I/Os including transceivers that can move around 4.5 Tb/s back and forth.

To put things in perspective, the previous record holder — the Virtex Ultrascale 440 — has 5.5 million logic cells and an old-fashioned Spartan 3 topped out at about 50,000 cells — the new chip has about 180 times that capacity. For the record, I’ve built entire 32-bit CPUs on smaller Spartans.

That led us to wonder? Who’s buying these things? When I first heard about it I guessed that the price would be astronomical, partly due to expense but also partly because the market for these has to be pretty small. The previous biggest Xilinx part is listed on DigKey who pegs the Ultrascale 440 (an XCVU440-2FLGA2892E) at a cost of $55,000 as a non-stocked item. Remember, that chip has just over half the logic cells of the VU19P.

Continue reading “Who Could Possibly Need An FPGA With 9M Logic Cells And 35B Transistors?”

Yo Dawg, I Heard You Like FPGAs

When the only tool you have is a hammer, all problems look like nails. And if your goal is to emulate the behavior of an FPGA but your only tools are FPGAs, then your nail-and-hammer issue starts getting a little bit interesting. That’s at least what a group of students at Cornell recently found when learning about the Xilinx FPGA used by a researcher in the 1990s by programming its functionality into another FPGA.

Using outdated hardware to recreate a technical paper from decades ago might be possible, but an easier solution was simply to emulate the Xilinx in a more modern FPGA, the Cyclone V FPGA from Terasic. This allows much easier manipulation of I/O as well as reducing the hassle required to reprogram the device. Once all of that was set up, it was much simpler to perform the desired task originally set up in that 90s paper: using evolutionary algorithms to discriminate between different inputs.

While we will leave the investigation into the algorithms and the I/O used in this project as an academic exercise for the reader, this does serve as a good reminder that we don’t always have to have the exact hardware on hand to get the job done. Old computers can be duplicated on less expensive, more modern equipment, and of course video games from days of yore are a snap to play on other hardware now too.

Thanks to [Bruce Land] for the tip!

An FPGA Drives This Antique LCD Screen

If you’re reading this article on a desktop or laptop computer, you’re probably staring at millions of pixels on a TFT LCD display. TFT became a dominant technology due to its picture quality and fast response times, but it’s not the only way to build an LCD. There are cheaper technologies, such as STN and its color variant, CSTN. They’re rarely used nowadays, but [Wenting Zhang] had one lying around and wanted to take a crack at driving it.

Still scenes aren’t bad, but motion blur is readily apparent on any moving content.

The screen in question came courtesy of a 20th century laptop. It’s a Hitachi SX21V001-Z4, with a resolution of 640×480 pixels. Driver boards for CSTN screens were once readily available, however now such things are difficult to come by.

[Wenting] instead grabbed an FPGA and got to work. Driving displays can be taxing for small microcontrollers, so an FPGA is always a great choice when working on such projects. They’re easily capable of generating whatever weird and wacky signals are required, and can generate many such signals in parallel without breaking a sweat.

[Wenting] successfully got the screen up and running, and hooked up to a VGA input. Image quality is surprisingly passable for still images, though things absolutely go to pieces when motion is introduced. [Wenting]’s demo shows off the screen playing Breath of the Wild, and it’s a great showcase of how far technology has come since the mid-90s.

Driving strange LCDs is a hacker rite of passage, and we see plenty of efforts around these parts. Video after the break.

Continue reading “An FPGA Drives This Antique LCD Screen”

FPGA Used VHDL For Fractals

Over on GitHub, [ttsiodras] wanted to learn VHDL. So he started with an algorithm to do Mandelbrot sets and moved it to an FPGA. Because of the speed, he was able to accomplish real-time zooming. You can see a video of the results, below.

The FPGA board is a ZestSC1 that has a relatively old Xilinx Spartan 3 chip onboard. Still, it is plenty powerful enough for a task like this.

Continue reading “FPGA Used VHDL For Fractals”

Racing The Beam On A Thin Client, In FPGAs

A few years back, a company by the name of Pano Logic launched a line of FPGA-based thin clients. Sadly, the market didn’t eventuate, and the majority of this stock ended up on eBay, to eventually be snapped up by eager hackers. [Tom] is one of those very hackers, and decided to try some raytracing experiments with the hardware.

[Tom] has one of the earlier Pano Logic clients, with VGA output and a Xilinx Spartan-3E 1600 FPGA under the hood. Due to limited RAM in the FPGA, and wanting to avoid coding a custom DRAM controller for the memory on the board, there just wasn’t room for a framebuffer. Instead, it was decided that the raytracer would instead “race the beam” – calculating each pixel on the fly, beating the monitor’s refresh rate.

This approach means that resource management is key, and [Tom] notes that even seemingly minor changes to the raytracing environment require inordinately large increases in calculation. Simply adding a shadow and directional light increased core logic utilisation from 66% to 92%!

While the project may not be scalable, [Tom] was able to implement the classic reflective sphere, which bounces upon a checkered plane and even added some camera motion to liven things up through an onboard CPU core. It’s a real nuts-and-bolts walkthrough of how to work with limited resources on an FPGA platform. Code is available on Github if you fancy taking a further peek under the hood.

If you’re new to FPGAs yourself, why not check out our FPGA bootcamp?