hdl

10 Articles

Do We Need A New Hardware Description Language?

March 15, 2024 by 20 Comments

When you think about hardware description languages, you probably think of Verilog or VHDL. There are others, of course, but those are the two elephants in the room. Do we need another one? [Veryl-lang] thinks so. The Veryl language is sort of Verilog meets Rust. What makes Veryl interesting is that it transpiles to normal SystemVerilog, so it will — probably — work with your existing tool chains.

That means you can define your logic Veryl, have it output SystemVerilog, and then use that Verilog in your vendor’s (or an open source) Verilog tool. The output is supposed to be human-readable Verilog, too, so you don’t have to transport opaque blocks of gibberish.

Continue reading “Do We Need A New Hardware Description Language?” →

Exploiting Hardware-Level Parallelism In The Manticore Hardware-Accelerated RTL Simulator

May 10, 2023 by 10 Comments

Before a chip design is turned from a hardware design language (HDL) like VHDL or Verilog into physical hardware, testing and validating the design is an essential step. Yet simulating a HDL design is rather slow due to the simulator using either only a single CPU thread, or limited multi-threading due to the requirements of fine-grained concurrency. This is due to the strict timing requirements of simulating hardware and the various clock domains that ultimately determine whether a design passes or fails. In a recent attempt to speed up RTL (transistor) level simulations like these, Mahyar Emami and colleagues propose a custom processor architecture – called Manticore – that can be used to run a HDL design after nothing more than compiling the HDL source and some processing. Continue reading “Exploiting Hardware-Level Parallelism In The Manticore Hardware-Accelerated RTL Simulator” →

Al Williams Tells All In The Logic Simulation Hack Chat

March 4, 2022 by 1 Comment

The list of requirements for hosting one of our weekly Hack Chats is pretty short: you’ve got to be knowledgeable, passionate, and above all else, willing to put those two quantities on display for a group of like-minded strangers. Beyond that, we’re not too picky. From industry insider to weekend hobbyist, high school dropout to double doctorate, if you’ve got something interesting to talk about, we’re ready to listen.

But in casting a such a wide net, we occasionally forget that we’ve got a considerable collection of potential hosts within our own worldwide roster of contributors. Among this cast of characters, few can boast the same incredible body of knowledge as Al Williams, who was able to pencil in some time this week to host the Logic Simulation Hack Chat.

Or at least, that was the idea. In reality the Chat covered a wide range of topics, and was peppered with fascinating anecdotes pulled from Al’s decades of experience in the field. Though to be fair, we expected no less. He was building hardware before many of us were born, and can take credit for designs that have been at the bottom of the ocean as well as launched into orbit. He’s been writing about it just as long too, with articles of his appearing in iconic print magazines such as Dr. Dobb’s Journal.

Al has seen and done so much that he still surprises us with the occasional nugget, and we’ve been working with him for years. It was only a week or two back that he started a story with “Back when I used to manage a gas pipeline…” in the middle of a conversation about utility metering.

Of course, that’s not to say some technical discussion didn’t sneak in there from time to time. Sure Al’s  recollection of how they used to literally crawl over the schematics for the 68000 back at Motorola might stick out as a particular high point, but he also explains his personal preference for vendor-specific software tools over their more generic open source counterparts. He also draws comparisons between hardware description languages (HDLs) like Verilog and parametric CAD tools such as OpenSCAD in the way that they help model complex relationships in ways that can’t be easily done by more traditional means.

At one point the conversation lingers on the design and production of application-specific integrated circuits (ASICs), and how they compare to field-programmable gate arrays (FPGAs). Traditionally ASICs have been out of reach for the hobbyist, but with the recent collaboration between Google and SkyWater Technology to create an open source process design kit (PDK), they’re now within the capabilities of a dedicated individual. Matt Venn spoke on the topic during Remoticon 2021, and it’s good to see more folks in the community openly discussing the possibilities of custom silicon designed by hackers.

From there, things start really getting wild. From dreaming of virtual reality circuit simulators that let you fly amongst your creations like in Tron, to salivating over high-end technologies such as reflective memory, this Chat really runs the gamut. But then, that’s sort of why we hold them in the first place. Whether you actively participate or are just along for the ride, the Hack Chat gives everyone in the community a chance to gather around a virtual water cooler with fascinating characters that you won’t find anywhere else.

The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.

Write In PipelineC For FPGAs

August 16, 2020 by 15 Comments

The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.

[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.

PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.

If you want to dive head-first into pipelining, give [Al Williams]’ two-part mini-series a look.

Pipeline graphic CC BY-SA 3.0 by CBurnett

Circuit-Level Game Boy: Upping Emulation Ante By Simulating Every Cycle

April 23, 2019 by 12 Comments

Usually when writing emulation software for a system like the Game Boy, one makes sure to take as many shortcuts as possible in order to reduce the resources required for the emulation. This has however the unfortunate side-effect that it reduces the overall accuracy of the emulation and with it the compatibility with games on the system.

This is the basic reasoning behind projects which seek to abandon simplistic abstractions in favor of cycle-accurate, full compatibility approaches, of which MetroBoy is probably the most extreme one. Instead of abstracting away the hardware, it instead does the emulation at the circuit level. As with such other projects, this means that the emulator requires a lot more CPU cycles to get things just right. On the bright side, one can likely still run this emulator on any modern system.

As the MetroBoy author explains, he implemented code in C++ which allowed him to construct circuits in an HDL-style manner, which should theoretically also allow him to generate a Verilog (or VHDL) softcore out of the project. As a demonstration of implementing HDL in C++ it’s decidedly interesting.

An approach like this is pretty much the exact opposite of a project like the UltraHLE (ultra high-level emulator) Nintendo 64 emulator, which used the knowledge that Nintendo 64 games are written in C as a first step to creating libraries that the code in the Nintendo 64 ROMs would call instead of the native (Nintendo) libraries. This allowed N64 games to directly run on the target system, with the graphic and system calls translated by UltraHLE into native OS calls, using the 3dfx Glide API for accelerated graphics.

While an approach like UltraHLE took allows for the most minimal use of system resources by essentially foregoing emulation completely, for retro systems like the Game Boy where games were implemented in assembly on bare hardware, using this circuit-level emulation ensures that one gets the most accurate match with the original handheld console experience.

As a word of caution to those who are now itching to try out MetroBoy, its Github site notes that it currently lacks support for game saves, uses a mixture of original Game Boy (DMG) and Game Boy Advance SP (AGS) hardware that confuses some games and has rather buggy sound support.

If playing around with software-defined Game Boy circuits isn’t enough and would like to literally look inside a real Game Boy, the X-ray image from the top of the article is something Chris over at Elektronaut pulled off several years ago.

FPGA Clocks For Software Developers (or Anyone)

September 21, 2017 by 18 Comments

It used to be that designing hardware required schematics and designing software required code. Sure, a lot of people could jump back and forth, but it was clearly a different discipline. Today, a lot of substantial digital design occurs using a hardware description language (HDL) like Verilog or VHDL. These look like software, but as we’ve pointed out many times, it isn’t really the same. [Zipcpu] has a really clear blog post that explains how it is different and why.

[Zipcpu] notes something we’ve seen all too often on the web. Some neophytes will write sequential code using Verilog or VHDL as if it was a conventional programming language. Code like that may even simulate. However, the resulting hardware will — at best — be very inefficient and at worst will not even work.

Continue reading “FPGA Clocks For Software Developers (or Anyone)” →

An Open Source Toolchain For ICE40 FPGAs

May 29, 2015 by 65 Comments

FPGAs are great, but open source they are not. All the players in FPGA land have their own proprietary tools for creating bitstream files, and synthesizing the HDL of your choice for any FPGA usually means agreeing to terms and conditions that nobody reads.

After months of work, and based on the previous work of [Clifford Wolf] and [Mathias Lasser], [Cotton Seed] has released a fully open source Verilog to bitstream development tool chain for the Lattice iCE40LP with support for more devices in the works.

Last March, we saw the reverse engineering of the Lattice ICE40 bitstream, but this is a far cry from a robust, mature development platform. Along with Yosys, also written by [Clifford Wolf] it’s relatively simple to go from Verilog to an FPGA that runs your own code.

Video demo below, and there’s a ton of documentation over on the Project IceStorm project page. You can pick up the relevant dev board for about $22 as well.

Continue reading “An Open Source Toolchain For ICE40 FPGAs” →