It’s here! Clash 1.0 is finally released! And it has a binary release for the very first time! Check out the install instructions instructions on how to get it!

10 years old

First a short retrospective: the very first demonstration of the Clash compiler was given on the 3rd of September 2009 at the Haskell'09 Symposium in Edinburgh:

We were planning the 1.0 release of Clash for some time now, but decided that such a momentous occasion should coincide with the 10 year anniversary of Clash (+1 day due to release engineering mishaps). We really want to thank all of our contributors for their continued support of Clash. The code contributors that invest their time to create new features and fix bugs, and the financial contributors that enable the core Clash developers to work on Clash as their day job. Much praise for our users as well, who’ve struggled through our API changes over the years (which should happen much, much, less from now on), who helped us pinpoint many bugs and thus making Clash a more stable piece of software.

Clash will soon be updated to include the ability to choose whether registers have initial values. In order to do this, we introduce the concept of a synthesis domain. In this blogpost we’ll go over the reasons why we need initial values, and how to use them.

Clash uses Haskell’s bottom to represent undefined values. Traditionally, bottoms are used to represent exceptional situations which, if evaluated and not explicitly handled, should halt program execution. Due to the nature of circuits, Clash programs have to deal with these situations much more often (and more explicitly) than normal Haskell programs. In this blogpost we’ll go over the common pitfalls of undefined values, and what tooling is available to deal with them.

We’ll be running a small tutorial where you will learn the basics of Clash, and hardware design, by building a stack-based CPU (think Forth). Read the full blogpost for more details!

Welcome to the new Clash website! While the old website served us well, we wanted to have support for a blog: go check out our first two posts on matrix multiplication and systolic arrays.

We wanted a static website for all the usual reasons (speed, security, etc), and decided to use hugo because:

• It’s popular, and consequently has many resources on how to customize and setup a site.
• Is simple to install because it’s a single statically compiled binary.
• It has a lot of features, including i18n support which we eventually want to use to have translated versions of our blog posts.

We’re using netlify to host the website because:

Systolic arrays are networks of locally coupled processing elements, continuously receiving and sending their inputs and outputs from and to their neighbors. They cannot access main memory or global buses, thus allowing them to keep critical paths short. Because of this, they are extremely good at solving problems in the field of image processing, artificial intelligence, and computer vision. This blogpost will take a look at how to build systolic arrays with Clash and subsequently build a matrix multiplier with it.

Matrix multiplications happen to be useful in a very broad range of computational applications, such as computer graphics, artificial intelligence, and climate change research. At QbayLogic we help implement these (and more) applications on FPGAs using Clash. In this blogpost we will explore the intricacies of implementing matrix multiplications on FPGAs. We will explore the apparent differences between hardware and software development, how to use Clash to convert a “naive” algorithm to one suitable for an FPGA, and the use of Clash dependent types.