FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表

FPGAの回路を書く言語は、実務ではVerilog HDL、VHDL、SystemVerilogの3つからほぼ決まります。どれを選んでも同じ回路は作れるので、差が出るのは文法の好みではなく、型の厳しさが生む不具合の出方、開発ツールが対応する言語の版、検証をどこまで厚くするか、既存のIPと人材の側です。この記事では、3言語の規格の現在地を確かめたうえで、同じ8ビットカウンタを3言語で書き比べ、ビット幅の扱いで挙動が分かれる例と、Vivado 2026.1系やオープンソースのVerilator・GHDLで手元検証するコマンドを示します。最後に、案件の条件から言語を決める判断表と、言語の移植を見送る場面までを扱います。FPGAそのものの仕組みはFPGAの仕組みとCPU・ASIC・CPLDとの違いを解説した記事に譲りました。

まとめ｜新規は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の規格ページの状態は次のとおりでした。

出典はIEEE 1364-2005の規格ページ、IEEE 1076-2019の規格ページ、IEEE 1800-2023の規格ページです。1076-2019はstd_logicを定めるIEEE 1164も同じ文書に収めています。1800-2023は2024年2月28日の公開で、AccelleraのIEEE GETプログラムで無償入手できるため、規格書を引くコストもかかりません。「Verilogで書く」と言う現場の多くは、実際にはSystemVerilogの合成可能な範囲を使っています。

高位合成と検証言語の守備範囲｜C++・UVM・Pythonの置き場所

高位合成（HLS）は、C/C++で書いたアルゴリズムからRTLを生成する方式です。アルゴリズムの試行回数が多い案件で効きますが、生成されたRTLの面積と周波数の詰めには結局HDLの読解が要ります。HLSの仕組みと手書きHDLとの品質差は同じシリーズの別記事で扱うため、ここではHDLを選ぶ前提で進めます。

検証側の標準はUVM（IEEE 1800.2）です。AccelleraのUVM配布ページでは、IEEE 1800.2向けライブラリの2020-3.2版が最新として掲載されていました（2026年10月時点）。UVMはSystemVerilogのクラスで組むため、設計をVHDLで書いてもテストベンチ側はSystemVerilogになる構成が珍しくありません。Pythonでテストベンチを書ける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の利点の節も、構造体・列挙型・インタフェースを合成で使える点を挙げた資料です。CのコードとVerilogを並べた比較はFPGAとマイコンの違いを書き比べで示した記事にあります。

ビット幅と型の扱いで起きる不具合｜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は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検証トレンド調査では、非自明なバグを製品まで流出させたプロジェクトが87%にのぼりました。言語を選ぶ段階で、検査の仕組みまで決めておく価値があります。

開発ツールの対応状況を確かめる｜Vivado 2026.1系とオープンソース検証

言語の版を選んでも、合成ツールが対応していなければ使えません。FPGAベンダーのツールは3言語と混在設計に対応していますが、版ごとの対応範囲には差があります。ベンダーごとのツールの違いはFPGAメーカー4社の製品レンジと開発ツールの比較にまとめています。

Vivadoの言語版指定Tclコマンド｜VHDL-2008とSystemVerilog

AMDのVivadoでは、VHDLファイルは既定でVHDL-2008として扱われません。UG901（2026.1版・2026年7月8日）の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の対応機能一覧で版ごとに確かめます。

GHDLとIcarus Verilogで合成前に動かす｜ライセンス不要のシミュレーション

ベンダーツールを入れる前に、言語の感触を確かめる方法もあります。VHDLはGHDL、VerilogはIcarus Verilogが無償で使えます。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軸で選ぶ言語

上から順に当てはめ、最初に該当した行で決めます。人材を確保できるかどうかは、表の条件とは別に判断すべき要素です。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工程と期間・体制の見積り方を扱った記事で扱っています。センサーや機器の制御を含めた組み込み・IoTの開発として相談したい場合は、一創の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を生成する方式なら使えます。ただし、生成された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との違い：HDLで記述した回路がFPGAの中でどう実現されるかを扱う親記事です。
• FPGA設計の流れ｜7工程の進め方とソフト開発との違い・期間と体制の見積り方：言語を決めた後のRTL記述・検証・合成の工程と工数です。
• FPGAとマイコンの違い｜同じ処理をCとVerilogで書き比べて分かる選定の5軸：CとVerilogの書き比べで、ソフトとの考え方の違いを示した記事です。
• FPGAメーカー比較｜主要4社の製品レンジ・開発ツール・供給条件で選ぶ基準：言語の対応範囲を左右する開発ツールの比較です。
• FPGAによるAI推論とは？量子化・推論IP実装とGPUとの使い分けを実装視点で解説【2026年版】：HDLで直接書く方式と推論IPを使う方式の違いを扱っています。