Verilisp を使う

どういう仕組か？

mangle に Python を使っている。module という名称はPython のプログラムによって v_module という名称に変更する。そして、clisp を pipe 呼ぶ。その結果を Verilog-HDL としてファイルに書き出す。

Lisp 側

だいたいが macro になっている。v_module もマクロ。マクロの中で write している。自分で defmacro していけばいろんな便利なものをかけそう。lib にいくつかサンプルがある。

コンパイラではない

コンパイラではない上に構文解析はしていない。その為、verilisp では通すけど、Verilog-HDL 的には NG というものも出力してしまう。結局 Verilog-HDL のデバッグをすることになる。

<= が怪しい

オリジナルは n= オペレータを使って Verilog-HDL の代入を作る。<= は比較演算子とコンフリクトするのが理由。ついうっかり、v_<= を作ってしまった(いや～このミス何回もしてるんだよね)。遅延を入れることができる改造をしたので当分はこのまま。ステートメントであれば代入、じゃなければ比較演算子といったことをする必要がある。

属性を持てない

module にレイテンシーとか名称にその属性(wire or reg) を持てるようになっていない。コンパイラじゃないからね。そのため、型の単純な予測すらできない。

Lisp であること

ここが一番のアドバンテージ。ステートメントを分解して組み立てたりできる。差し込みもできる。接続もできる。名称を見て動作を変更できる。など、拡張し放題（のはず）。

ただ、大概の Lisp 開発に起こる超ローカルルールが増えて自分しか使わないという状況にもなる。

マクロ難しい

結局 defmacro でやっていて、その評価過程出力される string をPython にパイプで返している。defmacro の結果は必要ない。のでnil を返している。なんかスマートじゃない。

さらに、じゃ、これでいいんじゃね？と自分で書いたマクロはことごとくはねのけられる。マクロが超難しいのと Verilog-HDL の組み立てが難しい。

本来なら、defmacro の結果が S 式の Verilog-HDL 形式になってそれを最終的に Verilog-HDL に変換するようにすべきなのだ。

いずれにせよ Lisp

誰かが使うというモノでもないだろう。でも評価されてちょっとうれしい(オリジナルは faulknerさんだけどね)

RISC-V を作り始めたよ

あまり意味はない。どれだけ対応できるのかを検証する意味で作っている。結局、Verilog-HDL で作った方がはやそう。私にとって、一番わかりやすいのは Python でつくった RISC-V。実用性はともかく、仕組みは断然突出でわかりやすい。そのうち公開予定。

bream

そういえば誰かがbreamなるものを作っているね。こちらは scheme だね。