SoftCore CPU Comparison

Monty Python once did a sketch where people tried to summarize Proust in fifteen seconds. Although summarizing eight FPGA-based CPUs is almost as daunting, [jaeblog] does a nice job of giving a quick sketch of how the CPUs work with the Xilinx Vivado toolchain and the Digilent Arty board.

The eight CPUs are:   VexRiscv, LEON3, PicoRV32, Neo430, ZPU, Microwatt, S1 Core, and Swerv EH1.

The comparison criteria were very practical: A C compiler (gcc or llvm) for each CPU and no CPUs that were tied to a particular FPGA. Two of the CPUs didn’t fit on the Arty board, so their comparisons are a bit more theoretical.  There were other considerations such as speed, documentation, debugging support, and others.

It was interesting to see the various CPUs ranging from some very mature processors to some new kids on the block, and while the evaluations were somewhat subjective, they seemed fair and representative of the things you’d look for yourself. You can also get the test code if you want to try things for yourself.

The winner? The post identifies three CPUs that were probably the top choices, although none were just perfect. Of course, your experience may vary.

If you want an easy introduction to adding things to a soft CPU, this RISC-V project is approachable. Or if you prefer SPARC, check out this project.

Xilinx Makes MIPI CSI And DSI Controller IP Blocks Free To Use With Vivado

If you want to use a display or camera with an FPGA, you will often end up with a MIPI-based solution. As of the Xilinx Vivado 2020.1 release, the MIPI DSI (display serial interface) and CSI (camera serial interface) IP blocks are now bundled with the IDE to be used freely with Xilinx FPGAs.

The Xilinx MIPI CSI2 receiver block implements the CSI-2 v1.1 specification, which although a bit older is essentially the same CSI implementation as on the Raspberry Pi boards. This means that it would allow one to use this IP block on an FPGA with many common CSI camera modules out there. The IP block offers a standard AXI4 interface for connecting up to the rest of a design.

Similarly, the Xilinx MIPI DSI transmitter block implements DSI v1.3 specification. This offers a maximum data rate of 1.5 Gbps, with an AXI4-lite interface to communicate with the rest of the design. Both IP blocks are subject to the Core license agreement, which doesn’t appear to preclude it from being used in a specific fashion, whether commercial or personal.

This is not the only way to use MIPI devices with an FPGA, of course. Take for example [Daveshah]’s CSRIx project on Github.

Header image: Kwapix / CC BY-SA 4.0

Lattice Drops EULA Clause Forbidding FPGA Bitstream Reverse Engineering

Yesterday we reported that Lattice Semiconductor had inserted a clause that restricted the reverse engineering of bitstreams produced by their FPGA toolchains. Although not explicitly stated, it’s assumed that this was directed toward several projects over the past five years that have created fully open source toolchains by reverse engineering the bitstream protocols of the Lattice ICE40 and ECP5 FPGA architectures. Late yesterday Lattice made an announcement reversing course.

To the open source community, thank-you for pointing out a new bitstream usage restriction in the Lattice Propel license. We are excited about the community’s engagement with Lattice devices and our intent is to not hinder the creation of innovative open source FPGA tools.

It’s refreshing then to see this announcement from Lattice Semiconductor. Even more so is the unexpected turn of speed with which they have done so, within a couple of days of it being discovered by the open-source community. We report depressingly often on boneheaded legal moves from corporations intent on curbing open source uses of their products. This announcement from Lattice removes what was an admonition opposing open source toolchains, can we hope that the company will continue yesterday’s gesture and build a more lasting relationship with the open source community?

The underlying point to this story is that in the world of electronics there has long been an understanding that hardware hackers drive product innovation which will later lead to more sales. Texas Instruments would for years supply samples of exotic semiconductors to impecunious students for one example, and maybe you have a base-model Rigol oscilloscope with a tacitly-approved software hack that gives it an extra 50MHz of bandwidth for another.

We can only congratulate Lattice on their recognition that open source use of their products is beneficial for them, and wish that some of the other companies triggering similar stories would see the world in the same way. Try interacting more with your open source fans; they know and love your hardware more than the average user and embracing that could mean a windfall for you down the road.

Lattice Semiconductor Targets Bitstream Reverse Engineering In Latest Propel SDK License

The topic of reverse engineering is highly contentious at best when it comes to software and hardware development. Ever since the configuration protocol (bitstream) for Lattice Semiconductor’s iCE40 FPGAs was published in 2015 through reverse engineering efforts, there has been a silent war between proponents of open bitstream protocols and FPGA manufacturers, with the Lattice ECP5’s bitstream format having been largely reverse-engineered at this point.

Update: About eight hours after this article was published, Lattice Semiconductor issued a statement retracting the EULA language that banned bitstream reverse engineering. Please check out Hackaday’s article about this reversal.

Most recently, it appears that Lattice has fired a fresh shot across the bow of the open source projects. A recently discovered addition to the Propel SDK, which contains tools to program and debug Lattice devices, specifically references bitstream reverse engineering. When logged in with an account on the company’s website the user must agree to the Lattice Propel License Agreement for Lattice Propel 1.0 prior to download. That document includes the following language:

In particular, no right is granted hereunder […] (3) for reverse engineering a bitstream format or other signaling protocol of any Lattice Semiconductor Corporation programmable logic device.

Continue reading “Lattice Semiconductor Targets Bitstream Reverse Engineering In Latest Propel SDK License”

An Open Source HDMI Implementation For FPGAs

With some clever hacks and fast IO work, it’s possible to get your average garden-variety microcontroller to output some form of video. Old analog standards like composite and VGA are just slow enough that it’s possible to bitbash one’s way to success. If you’re serious about video work, however, you’ll want something more capable. For those use cases, [purisame]’s got what you need – an open source HDMI implementation for FPGAs.

Unlike other free and open source projects in this space, [purisame] has eschewed simply outputting compatible DVI signals on the port. This implementation is pure HDMI 1.4b, enabling the extended capabilities this brings, like combined video and audio streams. Thus far, it’s been tested on Xilinx and Altera platforms, though it may be compatible with Lattice, too.

In addition to the code, [purisame] breaks down options for those looking at going into production with an HDMI device. Licencing the technology for sale can be a fraught area, so a lawyer is recommended if you’re heading to market. Oh, and funnily enough, if your really do want to do HDMI on an Arduino, there’s a shield for that, too. Natch!

WiFi Goes Open

For most people, adding WiFi to a project means grabbing something like an ESP8266 or an ESP32. But if you are developing your own design on an FPGA, that means adding another package. If you are targeting Linux, the OpenWifi project has a good start at providing WiFi in Verilog. There are examples for many development boards and advice for porting to your own target on GitHub. You can also see one of the developers, [Xianjun Jiao], demonstrate the whole thing in the video below.

The demo uses a Xilinx Zynq, so the Linux backend runs on the Arm processor that is on the same chip as the FPGA doing the software-defined radio. We’ll warn you that this project is not for the faint of heart. If you want to understand the code, you’ll have to dig into a lot of WiFi trivia.

Continue reading “WiFi Goes Open”

FPGA Raises Component Video From A Sinclair ZX Spectrum

An abiding memory of the early-80s heyday of 8-bit computing for many is operating their computer from the carpet in front of the family TV. While the kids in the computer adverts had parents who bought them a portable colour telly on which to play Jet Set Willy, the average kid had used up all the Christmas present money on the computer itself. The cable would have been an RF connection to the TV antenna socket, and the picture quality? At the time we thought it was amazing because we didn’t know any different, but with the benefit of nearly 40 years’ hindsight, it was awful.

For ZX Spectrum owners in 2020 a standard modification is to bring out a composite video signal, but [c0pperdragon] has gone a step or two beyond that with a component video interface. And this isn’t a mod in which the signals are lifted from the Spectrum’s colour encoder circuitry, instead it uses an FPGA hooked directly to the ULA chip to generate the component video itself.

The Altera chip sits on a little PCB designed to occupy the footprint of the original Astec modulator, and sports a neat bundle of wires hooked up to the various Spectrum signals it needs. There are a couple of jumpers to select the output type and resolution, it supports YPbPr or RGsB outputs and both 288p and 576p. If you think perhaps it looks a little familiar, that’s because it’s the sister project of an earlier board for the Commodore 64. So if you have a Spectrum and are annoyed by UHF and PAL, perhaps it’s worth a look.