dalance commented 6 months ago

574 の日本語版

VerylによるRTL設計の漸進的な進化

VerylはSystemVerilogの代替言語として設計されたハードウェア記述言語です。特に既存のVerilog/SystemVerilogコードベースを漸進的に改善することに着目しています。

「漸進的」とは既存のコードベースの一部を徐々にVerylに置き換えていくことが可能であることを意味します。すなわち、VerylはSystemVerilogと高い相互運用性を持ちます。Verylに置き換えられたコードベースは、合成可能性やシミュレーションとの一致が保証され、各種エディタのプラグインを通してリアルタイムの編集支援が提供されます。さらにVerylで記述されたライブラリは統合されたビルドツールを通して容易に依存関係として追加することができます。

以下では、SystemVerilogや既存のHDL代替言語との違いを明らかにするために、Verylが提供するものとしないものについて詳しく見ていきます。

Verylが提供するもの

洗練された構文

Verylの構文はSystemVerilogの構文から合成可能記述を抽出し、Rustなど現代的なプログラミング言語の構文的な成果を取り入れたものです。そのため、SystemVerilogで非推奨であった記述の多くは構文の時点で排除されています。

Veryl	SystemVerilog
```systemverilog /// マークダウン形式のドキュメンテーションコメント /// * リスト1 /// * リスト2 pub module Delay #( param WIDTH: u32 = 1, // 末尾カンマ `,` を許容 ) ( i_clk : input logic , i_rst : input logic , i_data: input logic, o_data: input logic, ) { // `_` の付いていない未使用変数は警告される var _unused_variable: logic; always_ff (i_clk, i_rst) { // リセットの極性・同期非同期の抽象化構文 if_reset { o_data = '0; } else { o_data = i_data; } } } ```	```systemverilog // コメント // // module Delay #( parameter int WIDTH = 1 ) ( input i_clk , input i_rst , input [WIDTH-1:0] i_data, output [WIDTH-1:0] o_data ); logic unused_variable; always_ff @ (posedge i_clk or negedge i_rst) begin if (!i_rst) begin o_data <= '0; end else begin o_data <= i_data; end end endmodule ```

Veryl

SystemVerilog


```systemverilog
/// マークダウン形式のドキュメンテーションコメント
/// * リスト1
/// * リスト2
pub module Delay #(
    param WIDTH: u32 = 1, // 末尾カンマ `,` を許容
) (
    i_clk : input logic       ,
    i_rst : input logic       ,
    i_data: input logic,
    o_data: input logic,
) {
    // `_` の付いていない未使用変数は警告される
    var _unused_variable: logic;

    always_ff (i_clk, i_rst) {
        // リセットの極性・同期非同期の抽象化構文
        if_reset {
            o_data = '0;
        } else {
            o_data = i_data;
        }
    }
}
```

```systemverilog // コメント // // module Delay #( parameter int WIDTH = 1 ) ( input i_clk , input i_rst , input [WIDTH-1:0] i_data, output [WIDTH-1:0] o_data ); logic unused_variable; always_ff @ (posedge i_clk or negedge i_rst) begin if (!i_rst) begin o_data <= '0; end else begin o_data <= i_data; end end endmodule ```

上記はVerylとSystemVerilogのソースコードを比較したものです。

/// で始まるドキュメンテーションコメントを付与することで、Verylコンパイラはドキュメントを自動生成することができます。
カンマ区切りリストの末尾カンマを許容することで、リストの並び替えを容易にし、バージョン管理システムにおける不要な差分を抑制します。
変数が未使用であることを _ プレフィックスで明示することができ、明示されていない未使用変数はVerylコンパイラに警告されます。
if_reset 構文によりリセット極性と同期・非同期を抽象化し、Verylコンパイラによるコード生成時にそれらを選択することができます。

リアルタイムフィードバック

Verylコンパイラは各種エディタのプラグインを通して、構文エラーやリントエラーをリアルタイムにフィードバックします。これにより時間のかかるコンパイルや合成プロセスを経ることなく、問題のある記述を即座に修正することができます。また、自動フォーマットによりコードベース全体に渡って一貫したフォーマットを容易に維持することができます。

SystemVerilogとの相互運用性

VerylはSystemVerilogとほぼ同じセマンティクスを持ち、Verylコンパイラは可読性の高いSystemVerilogソースコードを出力します。そのため既存のSystemVerilogコードベースの一部を置き換えたり、協調して使用することができます。

Verylが提供しないもの

短いコード記述

多くのHDL代替言語は既存のVerilog/SystemVerilogが短いコードで表現できることを重視していますが、Verylではそのようなアプローチは採用しません。短いコードから多くのVerilog/SystemVerilogが生成されることは、生成後のコードのデバッグや微調整を困難にするためです。代わりにVerylでは冗長なSystemVerilog記述を明示性を失わない範囲で略記できるようにします。

シミュレーション記述

シミュレーション記述は合成可能なRTL設計とは大きく異なるドメインです。サポートすべきものは単純な遅延記述だけでなく、複雑なアサーションや階層構成を取る巨大な検証フレームワークまで多岐にわたります。そのためVerylではこれらの記述を直接にはサポートせず、SystemVerilogやPythonなど他言語で書かれたテストベンチとの統合により検証をサポートします。

taichi-ishitani commented 6 months ago

= と <= の使い分け
リセットの指定漏れの検出
未宣言信号

とか、SV では気を付けながらコーディングしていた部分を言語レベルでチェックしてくれる、と言うのを強調しても良いのではと思います。

shioyadan commented 6 months ago

まず前提についてなのですが，「 https://veryl-lang.org/ 」の WEB ページのトップに書く紹介なのか，それともドキュメントのトップに書く紹介なのかで，すこし方向性が違ってくるのかなと思いました．現在は両者で同じ文章が使われているようですが，これらではそれぞれ目的が少し違ってくると思います．

まず WEB のトップの方については，とにかく「Veryl を使うと何がうれしいのか」を読者がさっとわかる事に目的があり，それを短くシンプルにまとめるのが良いのだと思います．たとえば以下の Rust や TypeScript の WEB ページはこれをやっているように思います（たまたまなのかわかりませんが，割と似た構造をしています）．

これらのページでは，まず最初に１文ぐらいのその言語の短い説明があったあとに，特徴や利点を箇条書きに近いスタイルでまとめています．これは，ちょっと興味を持った人が最初にちらっと見たときに，なんとかして次のステップに進んでもらう上で有効だと思います．また，両方とも比較的新しい言語で，新しく使ってもらうために積極的なアピールをしてこようと工夫してきたと思うのですが，他の部分も含めてこれらのページの作りは参考になると思います．

https://www.rust-lang.org/ https://www.typescriptlang.org/ja/

次にドキュメントの最初の概要ですが，こちらは既に最初の興味をもって中身自体をもうちょっと知りたい人や，これから学んでみようと考えた人が読む部分なので，トップページに比べるともう少しゆっくり言語自体の中身や思想，目的を絡めて話しても良さそうに思います．実際，Rust のドキュメント？のイントロも，「どういう人にとってどう嬉しいのか」をじっくり書いておりこのスタイルも参考になりそうです．

あと，これを見ていて思ったのですが，普段どう言う HDL を書いている人達が対象としてありえて，それぞれの人達にとってどう嬉しいのか，を１回考えてみるのは良さそうに思います（あんまりバリエーションはないかもしれませんが）．

https://doc.rust-lang.org/book/ch00-00-introduction.html

あとは，その上で内容についてですが，現在「漸進的な進化」が一番トップに来ていますが，それで良いのかがちょっと気になりました．「漸進的な進化」は柱となるとても重要な要素ではあると思うのですが，より上位の最終的に良くしたい事（理想的にどのような言語であってほしいのか的な）があった上で，それを実現する重要なアプローチなのかな、と言う気がするのですが，どうでしょうか？

dalance commented 6 months ago

まず前提についてなのですが，「 https://veryl-lang.org/ 」の WEB ページのトップに書く紹介なのか，それともドキュメントのトップに書く紹介なのかで，すこし方向性が違ってくるのかなと思いました．現在は両者で同じ文章が使われているようですが，これらではそれぞれ目的が少し違ってくると思います．

想定としてはドキュメントのトップですね。あとはこれをもう少しまとめてGitHubのREADMEにするイメージでした。正直Webページのトップは頭から抜けてました…。現状のあれはドメインを取るついでにでっち上げたくらいのもので、あまり考えられていないです。 RustやTSのページは参考になりそうなのでそのうち何とかしたいですね。

あとは，その上で内容についてですが，現在「漸進的な進化」が一番トップに来ていますが，それで良いのかがちょっと気になりました．「漸進的な進化」は柱となるとても重要な要素ではあると思うのですが，より上位の最終的に良くしたい事（理想的にどのような言語であってほしいのか的な）があった上で，それを実現する重要なアプローチなのかな、と言う気がするのですが，どうでしょうか？

これはどちらかというと「漸進的」であることが最上位なのではないかと気づいたので今回の文章を作ることにした感じです。正確に言うとより最上位はSVをなんとかしたいということだと思うので

（自分が）SVで効率よく開発したい
- SVの言語自体を改善する -> AccelleraやEDAツールベンダじゃないと無理
- SVのツールを作る -> svlint/svlsで試みたが行き詰まり
- 新言語を作って徐々に移行する -> Veryl

という感じですかね。これがSV自体を変えられる立場であれば、理想的な言語に向かっていくアプローチになると思うのですが、そうではないとすると実は「徐々に」という部分が最も重要でなのではないかと思います。（なぜなら「一気に素晴らしい新言語に移行する」というのは理想的には良くても実現不可能なので）

実際これまでに検討してきた言語デザインでもSVとの嚙み合わせの悪さを理由に不採用にしたりしていて判断基準の最上位がそこにあることを明示した方がいいのではないか、と思った次第です。

shioyadan commented 6 months ago

想定としてはドキュメントのトップですね。あとはこれをもう少しまとめてGitHubのREADMEにするイメージでした。正直Webページのトップは頭から抜けてました…。現状のあれはドメインを取るついでにでっち上げたくらいのもので、あまり考えられていないです。

ドキュメントのトップを想定するにしても，論文の abstract じゃないですけど，先頭になにか端的な特徴とユーザーから見たメリットを，Rust や JavaScript のページみたいにまとめておくのは良いかもしれないと思います．

というのも最近の hacker news でのコメントなどを見ても思ったのですが，こういうのは最初にわかりやすい形でユーザーからみた利点が伝わらないと，「それで何が嬉しいの？」「よくわかんないからまぁいいや」「どうせ XXX みたいなやつがまた出たんだろ」となって，次のステップの「ちょっと書いてみる」に全く進んでくれないんだなと思ったからです．

WEB ページはまた後でなのかもしれませんが，どこかに貼っつけて宣伝するときなどに，なにかすごく短い形でユーザーから見た利点が，どこかにぱっとまとまっているのはとても良いと思います．

これはどちらかというと「漸進的」であることが最上位なのではないかと気づいたので今回の文章を作ることにした感じです。

このあたりの説明していただいた理由や動機については大変納得しました．なにかこう言う理由や動機も，ドキュメントに多少含まれていた方がよかったりしないでしょうか？今の書き方はやや淡々と漸進的である事を説明していて，動機がもう少し書かれていると納得感があるかもと思いました．

正確に言うとより最上位はSVをなんとかしたいということだと思うので

今のバージョンの冒頭は「漸進的であること」から始まっていると思うのですが，やっぱりこの「SVをなんとかしたい」について，ユーザーから見た現世利益的な「なんとかなった」点を箇条書きででも簡単にまとめたあとに，これをやるうえで「漸進的であること」がキーなのだと言う筋で行くほうがとも思うのですが，どうでしょうか．

論文の abstract なんかでも，どう考えても理屈は通じてないだろうって段階で「～％性能があがりました」とか書いて気を引きますけど，まず現世利益を示すのは結構有効だと思います（しつこくてすいません）．

以下はその他のコメントです：

左が Veryl 右が SystemVerlog になってますが，人はまず知っているものから見るので，これ逆の方が良いかもしれません．
hacker news でも誰かが書いてましたけど，SV を何らかのスクリプト言語でテンプレートからパラメータ展開等して生成して使ってる人はそこそこいるはずで，（理想的には）それを Veryl に閉じて綺麗に実現できるのだと思うのですが，もし出来そうならそういうことも書いてあってもいいかもしれません．（できると嬉しいです）
SystemVerilog は，どうも always_comb 内でローカル変数的な logic の使用ができないくさいですが（例：logic a=b; とか for ループ内で書けない？），それが Veryl だと出来るようであれば，これも書いても良いかもしれません．自分はそれが出来るなら，かなり嬉しいです．

taichi-ishitani commented 6 months ago

テンプレート云々は、ジェネリスクが実装されれば解結しますかね？

dalance commented 6 months ago

@shioyadan コメントありがとうございます。ちょっとすぐには難しいので、また次の機会に新しい案を考えたいと思います。

dalance commented 6 months ago

テンプレート云々は、ジェネリスクが実装されれば解結しますかね？

ジェネリクスだけでは難しいかもしれません。より柔軟にやるならRustの手続きマクロ的なもの（構文木を受け取って変形した構文木を返すようなマクロをユーザが定義できるような仕組み）が必要かもしれないと思っていますが、複雑性も増すのでトレードオフはありますね。

dalance commented 6 months ago

一度に全部考えると大変なので、とりあえず「なぜVerylか？」を書いてみました。1つ目のタイトルもアイデアあればお願いします。

なぜVerylか

？？？

Verylの構文は論理設計のために最適化されており、合成可能性やシミュレーションとの一致が保証されています。さらに頻出する定型文を簡素化するような構文が多数提供されています。

相互運用性

Verylは可読性の高いSystemVerilogソースコードを生成します。そのため既存のSystemVerilogコンポーネントと組み合わせたり、SystemVerilogプロジェクトの一部をVerylで置き換えたりすることができます。

生産性

Verylにはパッケージマネージャとビルドツール、多数のエディタに対応するリアルタイムチェッカーや自動補完、自動フォーマッタといったツール群が数多く揃っています。

taichi-ishitani commented 6 months ago

SV の辛さとか、Chisel とか Alt HDL の辛さの例があると、見た目は SV に近い新しい言語を作ったか理解が深まるかもですね。

ciniml commented 6 months ago

Chiselの生成したVerilog HDLは読めないけど、Verylのは読めるみたいな話があるといいんですかね。

実際のところ、言い方はアレですが、VerylからSystemVerilogに’戻りたくなっても何とかなるだろうと思って触り始めてるというのはあります。最悪、どこかの時点でVerylが生成したSVコードをもとにSystemVerilogのみの開発に戻ればいいだろうと。

この辺も "漸進的" という利点に含まれるのかなと思います。

dalance commented 6 months ago

具体的に他言語の辛い点に触れるのはちょっとセンシティブな感じはします。（Rustを推すときにC++を下げると印象が悪いというのはよく言われる話だったり…）

実際のところ、言い方はアレですが、VerylからSystemVerilogに’戻りたくなっても何とかなるだろうと思って触り始めてるというのはあります。最悪、どこかの時点でVerylが生成したSVコードをもとにSystemVerilogのみの開発に戻ればいいだろうと。

ここは実際業務のコードに投入するために意識している部分ですね。自分が退職したときにVerylを書く人がいなくなったらそのままSVに戻ればいいという想定です。

shioyadan commented 6 months ago

SystemVerilog に基本的には基づいている事など，いくつか情報を足した上で，ChatGPT 先生に整理してみてと頼んだら以下の内容が出てきました．最初の項目名は「最適化された構文」を提案されましたが，これでも良いかもしれません（論理設計に，などを足してもいい気がします）．全体に少し不自然なところがあるというか，英語的な日本語になってるきがしますが，大枠では悪くない気がします．

VerylはSystemVerilogに基づくHDLであり、以下の利点を提供します。

最適化された構文: Verylは、SystemVerilogの経験者にとって親しみやすい基本構文に基づきながら、論理設計に最適化された構文を採用しています。この最適化には、たとえば合成可能性の保証やシミュレーション結果の一致の保証、頻出する定型文を簡素化する多数の構文などの提供が含まれます。このアプローチにより、学習の容易さ、設計プロセスの信頼性と効率の向上、およびコードの記述の容易さが実現されます。

相互運用性: VerylはSystemVerilogとの相互運用性を考慮して設計されており、既存のSystemVerilogコンポーネントやプロジェクトとの組み合わせや部分的な置き換えをスムーズに行うことができます。さらに、VerylからトランスパイルされたSystemVerilogソースコードは、その高い可読性により、シームレスな統合やデバッグを可能にします。

生産性: Verylはパッケージマネージャ、ビルドツール、そしてVSCode、Vim、Emacsなどの主要なエディタに対応するリアルタイムチェッカー、自動補完機能、自動フォーマッタなど、豊富な開発支援ツールを備えています。これらのツールは、開発プロセスを加速し、生産性を大幅に向上させることができます。

これらの特性により、Verylは設計者が高品質なハードウェア設計をより効率的かつ生産的に行うための強力なサポートを提供します。

shioyadan commented 6 months ago

「漸進的な改善」は，いくつかの利点があると思うのですが，ユーザーから見た利点の１つは，SystemVerilog 経験者には学習が容易であることだと思いますので，この点について追加してみた形です．あとは，他の HDL のように，SystemVerlog からかけ離れている訳ではないという雰囲気も入れた方が良いかなと思いました．他は細かいですが，エディタは名前を出した方が良いかなとか思いました．

dalance commented 6 months ago

ありがとうございます。ひとまずWebサイトの方はこれで更新しようと思います。

dalance commented 6 months ago

https://veryl-lang.org の方を更新しました。

dalance commented 6 months ago

READMEの方もこれで良さそうなので更新しました。コード例はSVと対比できるようにしましたが、テーブルの横幅が制御できなくていまいちですね…。 SVを左にするとVerylが見切れてしまったのでとりあえずVerylを左のままにしています。画像にした方がいいかもしれません。

shioyadan commented 6 months ago

とりあえず出した叩き台のつもりだったんですが，大丈夫でしたでしょうか？

英文の方は一応校正にかけてみたのですが，多少修正を提案されました．

This optimization includes guarantees for synthesizability, ensuring consistency between simulation results, and providing numerous syntax simplifications for common idioms.

３つの項目の表記が一貫していないため，ensures と provides にしてはと提案されました．やや意味が変わってしまう気もしますが，後ろの２つは確かに ensures と provides のが自然な気もします．

あと，日本語の時点で気になっていたのですが，consistency between simulation results は，正確にはシミュレーション時と合成時の一貫性ですよね？これはでも，短く言うのが難しいですね．consistency between simulation and synthesized circuits とか書けば良いでしょうか．

Veryl adopts syntax optimized for logic design while being based on a familiar basic syntax for SystemVerilog experts.

whiole being のところが不自然なようです．以下を提案されましたが，この感じで親しみやすい基本構文が保たれていると言う言い方をした方が，確かにわかりやすいかもしれません．

Veryl adopts an optimized syntax for logic design, maintaining a familiar basic syntax for experts in SystemVerilog.

Designed with interoperability with SystemVerilog in mind, Veryl allows smooth integration and partial replacement with existing SystemVerilog components and projects.

with が２回はちょっとかっこ悪いので，for にした方がいいかもです．

Designed for interoperability with SystemVerilog, Veryl allows smooth integration and partial replacement of existing SystemVerilog components and projects.

Veryl comes with a rich set of development support tools, including package managers, build tools, real-time checkers compatible with major editors such as VSCode, Vim, Emacs, automatic completion, and automatic formatting. These tools accelerate the development process and significantly enhance productivity.

VSCode, Vim, Emacs のところがやや読みにくいので，分割した方がよさそうです．あと，日本語のときは語順てきに問題なかったと思うのですが、エディタのサポートはその後ろの項目（automatic completion とか）にもかかってるので，上記だとやや不自然かもしれません．

Veryl enhances productivity with a suite of development support tools, including package managers and build tools. For editing, it offers features like real-time checkers, automatic completion, and automatic formatting, compatible with major editors such as VSCode, Vim, and Emacs. These features accelerate the development process, improving workflow efficiency for designers.

dalance commented 6 months ago

とりあえず出した叩き台のつもりだったんですが，大丈夫でしたでしょうか？

ドキュメントの場合は多少変でも特に実害はないので、じっくり検討するよりやる気があるうちにどんどん変えていくのがいい気がしてきています。（OSSの場合、次にやる気が出るのが半年後とかになる可能性も十分あるので…）

英文の修正もこのまま取り込んでいいと思っているので、もしよろしければPRだしていただけますか？面倒なようであればこちらでコピーしますがせっかくなので。

shioyadan commented 6 months ago

言われてみるとたしかに，こう言うのはやる気があるときに不完全であってもえいやっとやってしまった方が良さそうですね．では後で準備して PR だしておきます．ありがとうございます．

dalance commented 6 months ago

SVに対して構文的に優位性がある点を列挙したページを作ろうと思います。とりあえずリストアップしたのですが、他に入れたほうがいいものがあれば教えてください。

末尾カンマ
クロックリセットの抽象化構文
同名接続の省略記法
ドキュメンテーションコメント
代入演算子がalways_ffでも使える
enumバリアントの名前空間が切れている
ビット連結のrepeat構文
if/case式
半開区間、閉区間記法（と範囲for/inside）
msb/lsb
outside式
let 文による中間変数バインドが任意の場所で使える
名前付きブロック
可視性制御
未使用、未宣言、未代入変数のチェック（_による未使用の明示）

taichi-ishitani commented 6 months ago

同名接続の省略記法

Verilog にも *. で接続を省略できる機能がありますね。

現状、文法に関しては、概ね SystemVerilog のサブセットの範囲かとおもいます。なので、ジェネリクスとか今後実装が予定されている機能で、どう差別化できるかみたいなのもあった方が良いのではと思います。

dalance commented 6 months ago

.* での接続に対しては「（.*は何がつながっているか全くわからないので）明示性を損なわない範囲で省略できる」というような説明がいいでしょうか。

以下のような感じでSVとソースコードを対比できるといいのではないかと思っています。なので構文がfixしていないものはちょっと書きにくいですね…。今後の予定みたいなのはまた別途書くのがいいかもしれません。

dalance commented 6 months ago

.* での接続に対しては「（.*は何がつながっているか全くわからないので）明示性を損なわない範囲で省略できる」というような説明がいいでしょうか。

今調べて初めて知ったのですが、ポート名での省略記法もSVにあるんですね。

ModuleA u (
    .i_clk,
    .i_rst,
    .i_dat (a)
);

なのでこの点は特にVerylが良いというわけでもありませんでした。（この記法が普通に使えるなら生成後のSVでは使った方がいいかもしれません）

taichi-ishitani commented 6 months ago

.* での接続に対しては「（.*は何がつながっているか全くわからないので）明示性を損なわない範囲で省略できる」というような説明がいいでしょうか。

以下のような感じでSVとソースコードを対比できるといいのではないかと思っています。なので構文がfixしていないものはちょっと書きにくいですね…。今後の予定みたいなのはまた別途書くのがいいかもしれません。

リセットの抽象化が例になっていますが、生成後の SV で

active low なリセットに、極性を示す接頭辞なり接尾辞 (_x とか _n とか) がない
active high なリセットに、極性を示す接頭辞なり接尾辞がある

と言うのも違和感があるので、極性をしめす接頭辞とかを生成時に後付けできるようにしておけると良いかしれないですね。

dalance commented 6 months ago

と言うのも違和感があるので、極性をしめす接頭辞とかを生成時に後付けできるようにしておけると良いかしれないですね。

確かにそこは書いていてちょっと気になる点ではありますね。ただ現状だと何をリセットと認識するのかが難しい（always_ffのリセットポートから逆に辿るのは大変）ので、#569 のようなclock/reset型が必要かもしれません。クロックリセットが明示的だとSDCの生成やチェックみたいな方向にも行けそうです。

dalance commented 6 months ago

ドキュメントの1ページ目をWebサイトのものと同じに変更し、2ページ目に特徴を列挙するページを追加しました。

https://doc.veryl-lang.org/book/ja/ https://doc.veryl-lang.org/book/ja/02_features.html

taichi-ishitani commented 6 months ago

と言うのも違和感があるので、極性をしめす接頭辞とかを生成時に後付けできるようにしておけると良いかしれないですね。

確かにそこは書いていてちょっと気になる点ではありますね。ただ現状だと何をリセットと認識するのかが難しい（always_ffのリセットポートから逆に辿るのは大変）ので、#569 のようなclock/reset型が必要かもしれません。クロックリセットが明示的だとSDCの生成やチェックみたいな方向にも行けそうです。

属性を示す接尾辞なりをつけるとなると、リセット自体に属性を持たせることになるので、always_ff での指定ではなく、型で属性を指定することになるでしょうか。 (後で別の issue に纏めます。)

reset
- 生成時に指定
reset_async_low
reset_sync_high

dalance commented 6 months ago

属性を示す接尾辞なりをつけるとなると、リセット自体に属性を持たせることになるので、always_ff での指定ではなく、型で属性を指定することになるでしょうか。

最終的には生成時の指定とRTL中の指定のミスマッチがどこで検出されるかの問題で、どちらでも可能な気はします。もしミスマッチしないなら生成時の指定のみに従って接尾辞をつけて問題ないはずなので。

always_ffでの指定（現状）：always_ffのリセットポートで検出
reset型での指定：reset型からreset_*型への接続で検出

reset_*型の場合、この型の変数名をどうつけるのかがちょっと微妙かもしれません。

i_rst  : input reset_async_low // 生成時に _n が付くことを期待する。型がlowなのにVeryl上の名前が _n でないのは不自然
i_rst_n: input reset_async_low // Veryl上の見た目は一致するが、reset型の種類によって接尾辞付与の挙動が一貫しない

あとは「特定の極性しかサポートしないライブラリ」みたいなもののサポートが現状あまり考えられていないのでその辺との兼ね合いも考える必要がありそうです。

taichi-ishitani commented 6 months ago

always_ff (i_clk, async_low i_reset) {

}

always_ff (i_clk, sync_high i_reset) {

}

の様に、同じリセット信号を違う極性で使う場合を防ぐ目的で、型で属性を指定した方が良いと考えました。この場合をビルド時にエラーとして弾くなら、型で属性を指定しなくても良いかと思います。

veryl-lang / veryl

言語デザインドキュメントの改善 #575

574 の日本語版

VerylによるRTL設計の漸進的な進化

Verylが提供するもの

洗練された構文

リアルタイムフィードバック

SystemVerilogとの相互運用性

Verylが提供しないもの

短いコード記述

シミュレーション記述

なぜVerylか

？？？

相互運用性

生産性