Serguey Zefirov (thesz) wrote,
Serguey Zefirov

The second English post about HHDL.

After I posted on G+ a link to my first English post about HHDL, I got a comment asking "Why Haskell? Why another HDL?".

I cannot stand commenting on G+. And topic is broad enough to be worth a post.

So "Why another HDL?"

The state of affairs in HDL business is either very messy, or very outdated. Or both.

Let us take a look at VHDL.

VHDL is direct descendant of Ada programming language. Type system, control constructs, objects - everything has an Ada flavour. Ada was a pinnacle a few years before 1979, more than 30 years ago.

Two best things in VHDL are records and flexible resolution function system. The former gives you a sort of encapsulation, the latter allows you to simulate some non-discrete aspects of circuits, like resistance between wire and power or ground lines, or bidirectional channels. The good things about VHDL is the separation between interface (entity) and implementation (architecture) and possibility to select configurations (specify where that entity would have this architecture).

Both are notably absent in Verilog.

Verilog has wires and pretty much that is all.

System Verilog improved on both providing records, testing facilities, objects, processes, etc. Many things were taken from Bluespec Verilog, like interfaces.

The standard of System Verilog is... tangled. Looks like everything interact with everything. And then there are objects. 900 pages of entangled cryptogram with objects.

When I once met a Synopsis representative he told me there were 800 PhDs working on all aspects of System Verilog. So you have to have at least 8 PhD in your company to understand a measly 1% of System Verilog. And the count of 800 PhDs was in 2006, I think they are bigger now.

Allow me to sum it up. VHDL and System Verilog have good parts but suffer from overengineering and legacy. You cannot force them to solve your problems. Verilog is too simple for big systems.

Okay, the next contender is Bluespec System Verilog.

Bluespec was born as a Haskell of Hardware Description Languages. Then they made changes in syntax and it became a Clean or OCaml of Hardware Description Languages. No fancy operators (not in examples, at least), no significant whitespace, syntax is as close to Verilog as it could get.

They claim a eleventhfold reduction in source code volume and threefold reduction in the number of errors. Good.

But you cannot validate those claims before committing yourself to Bluespec. There are no free implementations of Bluespec System Verilog. You can buy a license for your developers. But it has significant cost per year, a developer's salary or more.

I see here a vicious circle - you cannot start using Bluespec Verilog because of the cost and if you willing to pay you cannot lower your "learning curve" cost as it is hard to find consultants and/or teachers.

Also there's a cost of Bluespec's computation model - it is hard to find performance problems in all those "WILL_FIRE_xxx" wires. Take a look at GCD in Bluespec. How many cycles it will take to find a GCD of 1 and 1000?

If I am not afraid to offer critique I should be not afraid to offer something for critique.

Let me enumerate my own HDL design points.

It would be highly preferable for language to solve some well defined and actual problem than to solve all problems equally well. The language should be extensible. The type system should allow to express many interesting relations, like "that netlist is valid only in the context of Port A or Port C", "those wires from that clock domain", etc. The less overhead from language text to actual netlist, the better. There should be free version of language.

What problem does HHDL solve? I tried my best to simplify design of ASIC/FPGA internals. HHDL explicitly does not support driving one wire by two sources - this is a job for periphery, it could be made very simple and it is VERY small compared to actual device logic. But HHDL supports clear differentiation between clock domains, algebraic types, pattern matching and almost arbitrary generation of netlists. Those are the hard problems I think.

Given HHDL nature as an embedded language, it is very extensible. All control structures are defined in host language Haskell and user can define his or her own.

HHDL uses Haskell's type system. It is very powerful.

HHDL provide clear encoding of algebraic types. The cost of their use is transparent.


I think I now answered the question "Why Haskell?". But I add a couple of words nevertheless.

I heavily use type level programming, introspection and code generation of Template Haskell to make HHDL thingy work. Other choices lack either type level programming (or type system at all, you have to write your own) or powerful introspection (like Agda2).
Tags: english, haskell
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded