--- title: "FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表" url: "https://www.issoh.co.jp/tech/details/18905/" published: 2026-10-26 updated: 2026-10-26 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表 FPGAの回路を書く言語は、実務ではVerilog HDL、VHDL、SystemVerilogの3つからほぼ決まります。どれを選んでも同じ回路は作れるので、差が出るのは文法の好みではなく、型の厳しさが生む不具合の出方、開発ツールが対応する言語の版、検証をどこまで厚くするか、既存のIPと人材の側です。この記事では、3言語の規格の現在地を確かめたうえで、同じ8ビットカウンタを3言語で書き比べ、ビット幅の扱いで挙動が分かれる例と、Vivado 2026.1系やオープンソースのVerilator・GHDLで手元検証するコマンドを示します。最後に、案件の条件から言語を決める判断表と、言語の移植を見送る場面までを扱います。FPGAそのものの仕組みは[FPGAの仕組みとCPU・ASIC・CPLDとの違いを解説した記事](https://www.issoh.co.jp/tech/details/9296/)に譲りました。 ## まとめ｜新規はSystemVerilogを基本とし既存IPと納品先の規約がある案件だけ合わせる 結論から書きます。既存の資産がなく、FPGAベンダーのツールで合成する新規案件なら、SystemVerilogを第一候補にします。Verilog HDLの規格（IEEE 1364）は2009年にSystemVerilog（IEEE 1800）へ統合されて更新が止まっており、今から新しく覚える理由がありません。`logic`型と`always_ff`で設計者の意図をツールに伝えられ、検証側のUVMもSystemVerilogの上に乗っています。 例外は二つ。動いているIPがVHDLで書かれていて改修が中心の案件と、納品先の設計規約で言語が指定されている案件です。この場合は既存の言語に合わせ、VHDLならVHDL-2008の機能まで使えるかをツールで確かめます。 言語の選択より効くのは、書いた直後に幅の不一致や推論ミスを機械で拾う仕組みです。Verilog系は代入の幅が合わなくてもエラーにならないため、lintをCIに組み込みます。言語の移植は、動いているIPの検証結果を捨てる作業なので、新しい機能を足す理由がない限り見送ります。 ## FPGAで使う言語の全体像｜HDL三系統と高位合成・検証言語の役割分担 FPGA開発で「言語」と呼ばれるものは、回路を書く言語、Cから回路を作る言語、回路を検証する言語の3層に分かれます。混ぜて語られやすいので、まず守備範囲を切り分けます。 ### Verilog HDL・VHDL・SystemVerilogの規格番号と2026年の版 3言語はいずれもIEEEの規格です。2026年10月時点で、IEEE SAの規格ページの状態は次のとおりでした。 | 言語 | 規格番号と最新版 | 状態 | 記述の系譜 | | ------------- | -------------- | ------------------------ | -------------------- | | Verilog HDL | IEEE 1364-2005 | Superseded（1800-2009が後継） | C言語に近い構文 | | VHDL | IEEE 1076-2019 | Active（1076-2008を置き換え） | Ada由来の強い型付け | | SystemVerilog | IEEE 1800-2023 | Active（1800-2017を置き換え） | Verilogの上位互換に検証機能を追加 | 出典は[IEEE 1364-2005の規格ページ](https://standards.ieee.org/ieee/1364/3641/)、[IEEE 1076-2019の規格ページ](https://standards.ieee.org/ieee/1076/5179/)、[IEEE 1800-2023の規格ページ](https://standards.ieee.org/ieee/1800/7743/)です。1076-2019は`std_logic`を定めるIEEE 1164も同じ文書に収めています。1800-2023は2024年2月28日の公開で、[AccelleraのIEEE GETプログラムで無償入手できる](https://accellera.org/news/press-releases/394-accellera-announces-ieee-1800-2023-standard-available-through-ieee-get-program)ため、規格書を引くコストもかかりません。「Verilogで書く」と言う現場の多くは、実際にはSystemVerilogの合成可能な範囲を使っています。 ### 高位合成と検証言語の守備範囲｜C++・UVM・Pythonの置き場所 高位合成（HLS）は、C/C++で書いたアルゴリズムからRTLを生成する方式です。アルゴリズムの試行回数が多い案件で効きますが、生成されたRTLの面積と周波数の詰めには結局HDLの読解が要ります。HLSの仕組みと手書きHDLとの品質差は[高位合成（HLS）の仕組みとpragmaの効き方を解説した記事](https://www.issoh.co.jp/tech/details/18907/)で扱うため、ここではHDLを選ぶ前提で進めます。 検証側の標準はUVM（IEEE 1800.2）です。[AccelleraのUVM配布ページ](https://www.accellera.org/downloads/standards/uvm)では、IEEE 1800.2向けライブラリの2020-3.2版が最新として掲載されていました（2026年10月時点）。UVMはSystemVerilogのクラスで組むため、設計をVHDLで書いてもテストベンチ側はSystemVerilogになる構成が珍しくありません。Pythonでテストベンチを書ける[cocotb](https://github.com/cocotb/cocotb)は設計言語を問わず使え、VHDL資産の検証を厚くしたい場合の逃げ道になります。 ## 同じ8ビットカウンタを3言語で書き比べる｜記述量と型の厳しさの差 イネーブル付き・同期リセットの8ビットカウンタを3言語で書きました。機能は同一で、どれも合成すれば同じ回路になります。違いが出るのは、型の宣言と、設計者の意図をどこまで書けるかです。 ### Verilog HDLのカウンタ｜regとwireの区別とノンブロッキング代入 ``` // counter8.v module counter8 ( input wire clk, input wire rst, input wire en, output reg [7:0] q ); always @(posedge clk) begin if (rst) q <= 8'd0; else if (en) q <= q + 8'd1; end endmodule ``` 行数は最も短く、型はビット幅だけで表します。`always`の中で代入する出力は`reg`、それ以外は`wire`と書き分ける決まりですが、`reg`と書いてもフリップフロップになるとは限りません。組み合わせ回路のつもりで書いた`always`で条件の書き漏らしがあると、意図しないラッチが推論されます。順序回路では`<=`（ノンブロッキング代入）を使う、という規律は設計者が守るしかありません。 ### VHDLのカウンタ｜unsigned型と明示的な型変換が必要な理由 ``` -- counter8.vhd library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity counter8 is port ( clk : in std_logic; rst : in std_logic; en : in std_logic; q : out std_logic_vector(7 downto 0) ); end entity; architecture rtl of counter8 is signal cnt : unsigned(7 downto 0) := (others => '0'); begin process (clk) begin if rising_edge(clk) then if rst = '1' then cnt <= (others => '0'); elsif en = '1' then cnt <= cnt + 1; end if; end if; end process; q <= std_logic_vector(cnt); end architecture; ``` 同じ回路で行数はおよそ2倍です。`std_logic_vector`は「ビットの並び」にすぎず足し算が定義されていないため、`numeric_std`の`unsigned`で数えてから出力の型へ変換します。冗長に見える変換が、符号付きと符号なしの取り違えをコンパイルの段階で止めます。ライブラリ宣言を忘れたときのエラーも明確で、黙って違う回路になることはほとんどありません。 ### SystemVerilogのカウンタ｜logic型とalways\_ffで意図の宣言方法 ``` // counter8.sv module counter8 ( input logic clk, input logic rst, input logic en, output logic [7:0] q ); always_ff @(posedge clk) begin if (rst) q <= '0; else if (en) q <= q + 1'b1; end endmodule ``` Verilogとほぼ同じ短さで、`reg`と`wire`の書き分けが`logic`一つに揃います。違いは`always_ff`です。「ここはフリップフロップのつもりで書いた」と宣言する構文で、中身がフリップフロップにならない書き方をした場合は、ツールによる警告の対象です。組み合わせ回路には`always_comb`を使い、ラッチの推論についても、同じ仕組みで検出することができます。AMDの[UG901のSystemVerilogの利点の節](https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Advantages-of-SystemVerilog)も、構造体・列挙型・インタフェースを合成で使える点を挙げた資料です。CのコードとVerilogを並べた比較は[FPGAとマイコンの違いを書き比べで示した記事](https://www.issoh.co.jp/tech/details/18903/)にあります。 ## ビット幅と型の扱いで起きる不具合｜Verilogの暗黙拡張とVHDLのエラー 3言語の差が実害として表に出るのは、幅の違う信号を混ぜたときです。シミュレーションが通ったまま実機で値がずれる不具合は、この挙動差から生まれます。 ### 幅の違う信号を代入したときの挙動差｜黙って切り捨てるか止めるか ``` // width_bug.v module width_bug ( input wire [7:0] a, input wire [3:0] b, output wire [7:0] y, output wire [3:0] z ); assign y = a & b; // b は上位4ビットを0で埋めて8ビットに拡張される assign z = a; // a の上位4ビットは捨てられる endmodule ``` Verilogでもこのコードは文法上正しく、合成もシミュレーションも通ります。`b`を符号付きのつもりで扱っていた場合、負の値が正の値に化けても誰も止めません。VHDLで同じことを書くと、配列の長さが合わない代入はエラーになり、その先の処理は停止します。検出がコンパイル時かシミュレーション実行時かはツールと記述で変わりますが、黙って回路になることはありません。VHDLの冗長さは、この種の不具合を書いた本人に返す代償です。 ### Verilatorのlintで幅の不一致を拾う手順｜書いた直後の無償チェック Verilog系で同じ安全網を張るには、lintを使います。[Verilator](https://github.com/verilator/verilator)はSystemVerilogをマルチスレッドのC++やSystemCへ変換するシミュレータで、lintによるコード検査の機能も持っています。 ``` # 幅の不一致・未使用信号・ラッチ推論などをまとめて検査する verilator --lint-only -Wall width_bug.v verilator --lint-only -Wall counter8.sv # 警告を個別に止める場合は、理由をコメントに残したうえで指定する verilator --lint-only -Wall -Wno-UNUSED counter8.sv ``` `width_bug.v`では、2つの`assign`の行それぞれに幅の不一致を示すWIDTH系の警告が出ます。Verilatorは既定で警告を致命的なものとして扱い、0以外の終了コードで止まるため、プルリクエストごとのCIに1行足すだけで「幅が合わないコードはマージできない」状態を作れます。[SiemensとWilson Research Groupの2024年FPGA検証トレンド調査](https://verificationacademy.com/topics/planning-measurement-and-analysis/wrg-industry-data-and-trends/2024-siemens-eda-and-wilson-research-group-fpga-functional-verification-trend-report/)では、非自明なバグを製品まで流出させたプロジェクトが87%にのぼりました。言語を選ぶ段階で、検査の仕組みまで決めておく価値があります。 ## 開発ツールの対応状況を確かめる｜Vivado 2026.1系とオープンソース検証 言語の版を選んでも、合成ツールが対応していなければ使えません。FPGAベンダーのツールは3言語と混在設計に対応していますが、版ごとの対応範囲には差があります。ベンダーごとのツールの違いは[FPGAメーカー4社の製品レンジと開発ツールの比較](https://www.issoh.co.jp/column/details/17707/)にまとめています。 ### Vivadoの言語版指定Tclコマンド｜VHDL-2008とSystemVerilog AMDのVivadoでは、VHDLファイルは既定でVHDL-2008として扱われません。[UG901（2026.1版・2026年7月8日）のVHDL-2008設定の節](https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Setting-up-Vivado-to-use-VHDL-2008)は、ファイル種別をTclで指定する方法を示しています。 ``` # プロジェクトモード：既存ファイルの種別をVHDL-2008に変える set_property FILE_TYPE {VHDL 2008} [get_files top.vhd] # 非プロジェクトモード：言語の版を明示して読み込み、合成する read_vhdl -vhdl2008 {top.vhd sub.vhd} read_verilog -sv counter8.sv synth_design -top top -part xc7a35tcpg236-1 report_utilization ``` VHDLのトップからSystemVerilogのモジュールを呼ぶ混在構成も、この読み込み方で合成できます。境界のポートを`std_logic`と`std_logic_vector`に揃えておくと、型の対応で迷いません。VHDL-2008のどの構文が合成できるかは、[同じUG901の対応機能一覧](https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Supported-VHDL-2008-Features)で版ごとに確かめます。 ### GHDLとIcarus Verilogで合成前に動かす｜ライセンス不要のシミュレーション ベンダーツールを入れる前に、言語の感触を確かめる方法もあります。VHDLは[GHDL](https://github.com/ghdl/ghdl)、Verilogは[Icarus Verilog](https://github.com/steveicarus/iverilog)が無償で使えます。GHDLのリポジトリによると、1987・1993・2002版のVHDLに完全対応し、2008版と2019版は部分対応です。 ``` # VHDL-2008：解析・エラボレーション・実行（tb_counter8 はテストベンチ） ghdl -a --std=08 counter8.vhd tb_counter8.vhd ghdl -e --std=08 tb_counter8 ghdl -r --std=08 tb_counter8 --stop-time=1us --wave=counter8.ghw # Verilog／SystemVerilogの一部：コンパイルして実行 iverilog -g2012 -o sim counter8.sv tb_counter8.sv vvp sim ``` テストベンチは各自のものに置き換えてください。注意したいのは、無償ツールの対応範囲と合成ツールの対応範囲が一致しない点です。GHDLで通ったVHDL-2019の構文がVivadoでは合成できない、という食い違いは起こりえます。手元検証で使う構文は、合成ツールの対応一覧にある範囲に絞ります。 ## 案件の条件で言語を決める判断表｜既存IP・納品先規約・人材・検証規模 ここからは判断です。言語の優劣を比べても答えは出ないため、案件の条件から逆に決めます。 ### 判断表｜既存資産・納品先規約・検証規模・人材確保の4軸で選ぶ言語 | 案件の条件 | 選ぶ言語 | 判断の根拠 | | ---------------- | -------------------- | ------------------------- | | 既存資産なし・新規開発 | SystemVerilog | Verilogの規格は統合済み・意図を宣言できる | | VerilogのIPを改修 | SystemVerilogへ段階移行 | 上位互換のため既存ファイルを残して追加分から書ける | | VHDLのIPを改修 | VHDL-2008 | 移植の検証コストが改修の効果を上回る | | 納品先の規約で指定あり | 規約どおり | 受け入れ検査とレビューが規約前提で組まれる | | 検証を厚くしたい（UVM） | テストベンチはSystemVerilog | UVMはSystemVerilogのクラスで組む | | VHDLのままPythonで検証 | VHDL＋cocotb | テストベンチの言語を設計言語から切り離せる | 上から順に当てはめ、最初に該当した行で決めます。人材を確保できるかどうかは、表の条件とは別に判断すべき要素です。VHDLとSystemVerilogの両方を読める技術者を1人置いておけば、既存のVHDL資産を抱えたままSystemVerilogで新規の部分を書く混在構成が取れます。 ### SystemVerilogを第一候補にする条件とVHDLを選ぶべき場面の境界 SystemVerilogを選ぶ条件は、使う合成ツールが`always_ff`・`logic`・インタフェースを合成できること、そして検証を設計と同じ言語で回したいことの二つです。Vivadoは2026.1版のUG901でSystemVerilogを合成の対象言語として扱っています。他社のツールは、採用する版の言語サポート一覧で確かめてください。 VHDLを選ぶのは、既存資産か規約という外部の制約があるときに限ります。強い型付けを理由に新規でVHDLを選ぶ判断は、SystemVerilogとlintの組み合わせでほぼ同じ安全性が得られるため、それだけでは根拠として弱いと考えます。ただし、チームの全員がVHDLで書いてきた組織なら、言語の切り替えで生産性を落とす期間のほうが損失は大きく、VHDL-2008で続けるほうが正解です。 ### 言語の移植を見送る場面｜動いているIPを書き換えて失う検証結果 VHDLのIPをSystemVerilogへ書き直す提案は、改修の打ち合わせでよく出ます。機能を足さないまま移植する場合、見送ります。移植で得られるのは記述の統一だけで、失うのは過去のシミュレーション結果、実機での動作実績、タイミング制約の調整履歴です。書き換えたコードは、元の検証項目を全部やり直すまで、動いていたIPより信頼できません。 移植に踏み切ってよいのは、そのIPに大きな機能追加が入り、どのみち検証をやり直す場合だけです。それ以外は、IPをブラックボックスとして混在構成で呼び出し、境界のポートだけを揃えます。 ### 外注先へ言語を伝えるときの確認項目｜版・コーディング規約・検証環境 FPGAの設計を外部に頼むとき、「Verilogで」とだけ伝えると、受け取る側はVerilog 2001の範囲で書くのか、SystemVerilogの合成可能な範囲まで使ってよいのかを判断できません。最低限、次の4点を発注時に文書で渡します。 1. 言語と規格の版（例：SystemVerilog、IEEE 1800-2017の合成可能な範囲） 2. 合成ツールとその版（例：Vivado 2026.1系、Quartus Prime Pro 26.1系） 3. コーディング規約とlintの設定（Verilatorの`-Wall`で警告0を受け入れ条件にするか） 4. テストベンチの言語と納品範囲（UVM、cocotb、ベンダーシミュレータのどれで回すか） ツールの版まで指定するのは、合成できる構文が版で変わるためです。4点のうち工程と工数への影響は[FPGA設計の7工程と期間・体制の見積り方を扱った記事](https://www.issoh.co.jp/tech/details/16844/)で扱っています。センサーや機器の制御を含めた組み込み・IoTの開発として相談したい場合は、[一創のAI・IoTソリューションの開発支援](https://www.issoh.co.jp/service/ai/iot/)で、言語と検証環境の取り決めから一緒に整理できます。 ## FPGA開発言語の選び方でよくある質問｜学習・合成範囲・資産変換の判断 FPGAの言語選びで、検索されることの多い質問に答えます。 ### FPGA初心者はVerilogとVHDLのどちらから学ぶべきですか？ 使う教材とボードが決まっていればその言語に合わせ、決まっていなければSystemVerilogの合成可能な範囲から始めます。Verilogの文法はSystemVerilogにほぼそのまま含まれるため、Verilogの入門書で覚えた知識は無駄になりません。最初の1か月で押さえるべきは文法よりも、記述がすべて同時に動く回路になるという考え方と、クロックとリセットの扱いです。Icarus VerilogやVerilatorなら費用をかけずに試せます。 ### SystemVerilogはFPGAの論理合成でどこまで使えますか？ `logic`、`always_ff`、`always_comb`、構造体、列挙型、インタフェースは、Vivadoの現行版で合成できます。一方、クラス、制約付きランダム、カバレッジといった検証向けの機能は合成の対象外で、使用できる場所は、回路を検証するテストベンチの中だけです。合成できる構文の一覧は版ごとに変わるため、使うツールの版のユーザーガイド（VivadoならUG901）で確かめてから規約に書きます。 ### PythonやC言語だけでFPGA開発はできますか？ C/C++は[高位合成ツールでRTLを生成する方式](https://www.issoh.co.jp/tech/details/18907/)なら使えます。ただし、生成されたRTLの面積やタイミングを詰める段階ではHDLを読む力が必要になり、HDLを一切使わずに製品まで進めるのは難しいのが実情です。Pythonは回路を書く言語ではなく、cocotbでテストベンチを書く用途が主流です。回路はHDL、検証はPythonという分担なら、ソフトウェア技術者も検証側から加わりやすくなります。 ### UVMはFPGA開発でも必要ですか？ 小規模な制御回路なら、UVMは過剰です。テストベンチを直接書くか、cocotbで入出力の期待値を確かめれば足ります。UVMが効くのは、複数のバスや外部インタフェースを持ち、同じ検証部品を案件をまたいで使い回したい規模の設計です。導入には、UVMライブラリを扱えるシミュレータと、クラスベースの検証を書ける技術者が要ります。体制が組めないうちにUVMを指定すると、検証工程そのものが止まります。 ### VHDLの資産をVerilogやSystemVerilogに変換できますか？ 変換ツールはありますが、出力をそのまま製品に使うことは勧めません。VHDLの型変換や`generate`の書き方は1対1に対応しないことがあり、変換後のコードは読みにくくなります。何より、変換したコードは元の検証をやり直すまで信頼できません。既存のVHDLはそのまま残し、混在構成でSystemVerilogの新規部分から呼び出すほうが、手戻りが少なく済みます。 ## 関連記事 - [FPGAとは？LUTと配線で回路を組む仕組みとCPU・ASIC・CPLDとの違い](https://www.issoh.co.jp/tech/details/9296/)：HDLで記述した回路がFPGAの中でどう実現されるかを扱う親記事です。 - [FPGA設計の流れ｜7工程の進め方とソフト開発との違い・期間と体制の見積り方](https://www.issoh.co.jp/tech/details/16844/)：言語を決めた後のRTL記述・検証・合成の工程と工数です。 - [FPGAとマイコンの違い｜同じ処理をCとVerilogで書き比べて分かる選定の5軸](https://www.issoh.co.jp/tech/details/18903/)：CとVerilogの書き比べで、ソフトとの考え方の違いを示した記事です。 - [FPGAメーカー比較｜主要4社の製品レンジ・開発ツール・供給条件で選ぶ基準](https://www.issoh.co.jp/column/details/17707/)：言語の対応範囲を左右する開発ツールの比較です。 - [FPGAによるAI推論とは？量子化・推論IP実装とGPUとの使い分けを実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/16846/)：HDLで直接書く方式と推論IPを使う方式の違いを扱っています。 --- 出典: [FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表]()（株式会社一創）