新しいHDL（ハードウェア記述言語）を考える

この記事は HDL Advent Calendar 2022 の16日目の記事です。

はじめに

HDL （ハードウェア記述言語）は ASIC や FPGA を開発するための言語です。一般的には昔からある Verilog/VHDL/SystemVerilog がよく使われており、私自身は SystemVerilog を主に使っています。

最近はこれらを代替する言語として Chisel が RISC-V のエコシステムを中心にある程度使われるようになってきました。Chisel については SystemVerilog を置き換えられる言語になるのではないかと期待していた部分もあったのですが、現時点で ASIC 開発用言語として使用できる状態には至っていないと思っています。

https://qiita.com/dalance/items/43175bfd61c0754ecb1c

というわけで当面は SystemVerilog を使い続けるしかない状況ですが、そうはいってもいろいろと不便な言語ではあるのでもう少し何とかしたいところです。
ちょうど parol というパーサジェネレータの記事を読んで、言語実装してみたい気分になったので、新しい HDL を考えてみることにしました。実装言語は Rust になります。

https://zenn.dev/ryo33/articles/26f87f776b4bfa

簡素な HDL 専用構文

まず構文についてです。SystemVerilog の構文は規格書の BNF が46ページもあり、これを全て
Rust 実装した sv-parser は45,000行という大規模なものになっています。

https://github.com/dalance/sv-parser

これほど大きな構文になっているのは、通常のRTL記述で使うような記述だけでなく、ゲート記述や SystemVerilogAssertion などいろいろなものを全てカバーしているためです。
構文には曖昧な部分がいくつもあり、本格的な処理系を実装するためには規格に従ったパーサを実装するだけでは足りません。意味解析を通して曖昧性を解決する必要があるため、実装のハードルは非常に高いです。（実際に商用の EDA ツールでさえ規格に従った記述を通せないことが少なくありません）

一方、既存の代替言語の多くはプログラミング言語の内部 DSL として実装されています。例えば

• Chisel: Scala
• MyHDL: Python

という具合です。
この方式は代替言語のパーサ実装をせずに済むだけでなく、各種エディタ用のシンタックスハイライトやフォーマッタ、リンタなどをそのまま再利用できるというメリットがあります。

しかし、内部 DSL であるということはベース言語の構文に制約されることになります。ベース言語はプログラミング言語なので、どうしても HDL として表現したいことが表現しにくい場面が多く出てきます。具体的には

• ビット幅表現
• クロックの扱い
• 信号の方向

といったあたりで、これらは HDL としては極めて基本的な要素であるにもかかわらず、既存のプログラミング言語では簡潔に表現できません。

そこで新言語は SystemVerilog の構文を簡素化した独自言語にすることを考えています。ただし構文要素の取捨選択においては SystemVerilog からの引継ぎや利便性よりパーサの実装負荷を重視します。

例えば実装が重い要素の1つにプリプロセッサがあります。単に ifdef や define を展開するだけならその名の通り事前にプリプロセッサで処理してしまえばいいのですが、Language Serverなどで適切な位置にエラーを表示したいなどと考えると途端に困難になります。

また、SystemVerilog では互換性維持のための古い書き方と新しい書き方が混在したり、ツールによってはトラブルの起きやすい非推奨な書き方をしてしまうことがありました。簡素化によって記法を統一し、非推奨記述をそもそも記述できないようにすることは、パーサだけでなくユーザにもメリットがあるのではないかと思います。

SystemVerilog へのトランスパイラ

多くの代替言語は Verilog を出力するようになっています。これにより商用含めた既存の EDA ツールとインターフェースすることができますし、 OSS のツールでは Verilog しかサポートされていないことも多いのでやむを得ない選択ではあります。

しかしせっかく代替言語において複雑なデータ構造を表現できるようにしても、 Verilog に変換した時点でバラバラの変数に展開されてしまうため、その後のデバッグなどが困難になります。
また Chisel などで顕著ですが、代替言語のセマンティクスと Verilog のセマンティクスが違いすぎると、生成されたコードと元コードの対応を取ることが困難になってきます。

そのため新言語は SystemVerilog へのトランスパイラとして開発します。構文を SystemVerilog ベースにすることである程度自然に達成できそうですし、生成されるソースコードの可読性も高くできるのではないかと思います。

トランスパイル時チェック

問題のある記述はできるだけ構文レベルで排除するようにしたいですが、どうしても意味解析後にしか分からないようなチェック項目もあります。例えば以下のようなものです。

• 合成不能記述（ex. always_comb でのラッチ生成）
• 未使用変数
• case網羅
• ビット幅不一致

これらを後段のツール（例えば合成ツールなど）に渡すことなく、ソースコード編集中にリアルタイムにチェックできるようにしたいです。

現代的な開発ツール

現代的なプログラミング言語では、リンタやフォーマッタ、 Language Server があるのが当たり前になっています。SystemVerilog 向けの OSS もいくつかありますが、先に述べたような実装の困難さもあり、完全なものが揃っているという状態ではありません。

新言語においてはこれらの開発ツールが最初から揃っている状態を目指します。
ソースコードの再利用をし易くするためのパッケージマネージャ的な機能も欲しいところです。

ソースコード（案）

今のところ以下のようなソースコードをイメージしています。基本的には SystemVerilog から予約語と言語機能を、構文要素の多くは Rust から引き継いでいます。

module ModuleA #(
    // 整数型は u32/u64/i32/i64/f32/f64
    parameter  ParamA: u32 = 10           ,
    localparam ParamB: u64 = 64'hffff_ffff,
    localparam ParamC: i32 = 10           , // 末尾カンマ対応
) (
    clk   : input  logic                 , // 型は後置
    port_a: input  logic                 ,
    port_b: output logic                 ,
    port_c: inout  logic [ParamA][ParamC],
    if_a  : InterfaceA.master            , // インターフェース
    // ifdef 相当
    // プリプロセッサではなくアノテーションで表現する
    #[if DefineA]
    port_d: output logic [ParamA],
) {
    // 型のビット幅は範囲ではなく幅で指定
    // SystemVerilogのように範囲指定にすると [1:10] や [9:0]
    // のようにバリエーションが生まれるので
    a: logic     ;
    b: logic [A] ;
    c: logic [20];

    assign a = 1;
    // 宣言と同時に assign
    assign d: logic[32] = 1;

    // ユーザ定義型
    enum EnumA {
        A,
        B,
    }
    struct StructA {
        a: logic    ,
        b: logic[10],
    }
    x: EnumA  ;
    y: StructA;

    always_ff (posedge clk) {
        // if の () なし
        if port_a == 1 {
            // 代入演算子は blocking / non-blocking の区別なし
            // always_ff / always_comb で区別する
            b = port_c[0][5];
        }
    }

    always_comb {
        c = b[2:0] + 10;
        x = EnumA::A;
        y.a = 1;
        y.b = 20;
    }

    // function/task のパラメータオーバーライド対応
    // static/automatic の区別なし。全て automatic 相当
    function FuncA #(
        parameter ParamX: u32 = 1,
    ) -> logic[ParamX] (
        a: input  logic[ParamX],
        b: output logic[ParamX],
        c: ref    logic[ParamX],
    ) {
        b = a + 1;
        c = a / 10;
        return a + 2;
    }

    // module のインスタンスとパラメータオーバーライド
    ModuleB #(
        ParamA, // 同名のパラメータ接続
        ParamB: 100,
    ) b (
        clk, // 同名のポート接続
        port_b: port_a,
        port_c: port_c,
    )
}

今後の予定

とりあえず parol を数日触って感触は分かってきたので、冬休みを使ってある程度動くものを作ってみる予定です。もし要望などあれば言っていただければ検討します。