SystemVerilog—Verilog与Systemverilog中的线程

余大大.

于 2025-06-03 16:45:22 发布

阅读量640

点赞数 11

CC 4.0 BY-SA版权

分类专栏： UVM验证文章标签： fpga开发笔记

本文链接：https://blog.csdn.net/weixin_44700185/article/details/148404741

UVM验证专栏收录该内容

17 篇文章

订阅专栏

在SystemVerilog中，模块（module）之间的通信和同步机制是硬件设计的核心，继承了Verilog的基础特性，同时引入了更强大的抽象能力。以下是关键点总结和扩展说明：

一、Verilog与Systemverilog中的通信

1. 模块间通信的基础：信号连接

模块通过端口（port）和信号线（wire/reg）进行通信，这是Verilog和SystemVerilog的共同基础。

端口定义：模块声明输入（input）、输出（output）或双向（inout）端口。

信号赋值：通过信号线连接不同模块的端口，传递逻辑值（电平或边沿）。

module ModuleA (
    input  logic clk,
    output logic data_out
);
    // 内部逻辑生成data_out
endmodule

module ModuleB (
    input  logic clk,
    input  logic data_in
);
    // 使用data_in的逻辑
endmodule

// 顶层模块连接A和B
module top;
    logic clk, data;
    ModuleA a_inst(.clk(clk), .data_out(data));
    ModuleB b_inst(.clk(clk), .data_in(data));
endmodule

2. 同步机制：事件（Event）与过程块

硬件行为的同步依赖事件触发和时序控制语句，这是Verilog的核心机制。

事件触发（-> 和 @）
通过事件（event）显式定义同步点，用于跨模块的精确同步。

module Source (
    output logic trigger
);
    always @(posedge clk) begin
        trigger <= 1;
        -> sync_event;  // 触发事件
    end
endmodule

module Sink (
    input logic trigger
);
    event sync_event;
    always @(posedge clk) begin
        @(sync_event);  // 等待事件触发
        // 执行同步后的操作
    end
endmodule

时序控制语句
使用 @(posedge clk)、#delay 或 wait 实现基于时间的同步。

always @(posedge clk) begin
    wait(data_ready == 1);  // 等待信号条件
    // 处理数据
end

3. SystemVerilog增强：接口（Interface）与时钟块

SystemVerilog引入了接口（Interface）和时钟块（Clock Block），显著简化复杂通信。

接口（Interface）
将一组相关信号和协议封装为单一实体，减少连线错误。

interface DataBus (input logic clk);
    logic [7:0] data;
    logic       valid;
    clocking cb @(posedge clk);
        output data, valid;
    endclocking
endinterface

module Master (DataBus bus);
    always @(posedge bus.clk) begin
        bus.cb.data  <= 8'hAA;
        bus.cb.valid <= 1;
    end
endmodule

module Slave (DataBus bus);
    always @(posedge bus.clk) begin
        if (bus.cb.valid) begin
            // 接收bus.cb.data
        end
    end
endmodule

时钟块（Clock Block）
定义信号在特定时钟域的同步行为，避免时序竞争。

interface SyncInterface (input logic clk);
    logic req, ack;
    clocking master_cb @(posedge clk);
        output req;
        input  ack;
    endclocking
endinterface

4. 高级进程间通信（IPC）

SystemVerilog支持更高层次的进程间通信机制，适用于验证和复杂行为建模。

Mailbox（邮箱）
用于线程间安全的数据传递（类似队列）。

module Processor;
    mailbox #(int) mb = new();
    initial begin
        int data = 42;
        mb.put(data);  // 发送数据
    end
    initial begin
        int received;
        mb.get(received);  // 接收数据
    end
endmodule

Semaphore（信号量）
控制对共享资源的访问。

semaphore lock = new(1);  // 初始化为1个钥匙
initial begin
    lock.get(1);   // 获取钥匙
    // 访问共享资源
    lock.put(1);   // 释放钥匙
end

5. 同步设计的注意事项

避免组合逻辑环路：确保信号变化的传播路径无循环依赖。
消除亚稳态：跨时钟域信号需同步器（如双触发器）处理。
时序收敛：通过静态时序分析（STA）验证关键路径。

6.总结

基础通信：端口信号连接 + 事件触发（Verilog继承）。
高级抽象：接口封装 + 时钟块（SystemVerilog增强）。
复杂场景：Mailbox/Semaphore（验证和系统级建模）。

通过合理选择同步机制，可以构建高效、可维护的硬件模型，同时避免常见的时序和竞争问题。

在SystemVerilog中，线程（Thread）是仿真过程中并发执行的基本单元，用于描述硬件行为或验证平台的动态交互。以下是关于线程的核心概念和使用场景的详细说明：

二、线程的定义与特性

基本定义
线程是独立运行的程序单元，需要被触发（如时钟边沿、事件或直接调用），可以主动结束或持续运行。其特点包括：
- 动态性：验证环境中的线程可动态创建和销毁（如通过initial块生成对象）。
- 并发性：多个线程可同时执行，通过同步机制协调操作。
- 资源占用：硬件模型中的always块线程会持续占用仿真资源，而验证环境线程通常按需释放资源。
线程的载体
- initial块：在仿真0时刻启动，通常用于测试平台初始化或一次性操作。
- always块：用于硬件行为建模（如时序逻辑），持续运行且不会自动终止。
- 任务（task）：支持耗时操作（如#delay或wait），可通过fork并行调用。
- 函数（function）：仅用于计算，不可包含时序控制语句，通常非耗时。

1、验证环境中为何避免使用`always`块

资源管理差异
- 硬件模型：always块模拟持续运行的电路逻辑（如时钟生成），需长期占用资源。
- 验证环境：动态对象（如事务处理器）需按需创建和销毁，使用initial块更灵活，避免资源浪费。
控制粒度需求
- always块的局限性：无法按需启动或终止，难以适应验证场景的动态需求（如随机测试序列）。
- 替代方案：通过initial块结合fork/join系列控制线程生命周期。

2、线程的控制与同步

线程的创建与终止
- fork/join系列：
  - fork...join：父线程等待所有子线程结束。
  - fork...join_any：任一子线程结束即恢复父线程，其他线程后台运行（适用于超时控制）。
  - fork...join_none：父线程立即继续执行，子线程并行运行（适用于异步任务触发）。
- 终止方法：
  - disable语句：终止指定线程或所有衍生子线程（disable fork）。
  - process类方法：如kill()终止线程、await()等待线程完成。
同步机制
- 事件（event）：通过->触发和@/wait(event.triggered)等待，实现简单通知。
- 旗语（semaphore）：控制共享资源访问，通过get()/put()管理钥匙数量，防止数据竞争。
- 信箱（mailbox）：线程安全的数据缓存队列，支持阻塞式put()/get()和非阻塞try_put()/try_get()。

3、验证环境中的线程管理实践

动态对象与线程
- 任务驱动的线程：在类的task中通过fork...join_none启动事务处理器，避免阻塞父线程。
- 资源释放：通过final块在仿真结束时自动清理资源（如关闭文件句柄）。
避免竞争与死锁
- 线程隔离：使用mailbox传递数据而非直接共享变量，减少竞争风险。
- 超时机制：结合fork...join_any和#delay防止无限等待。

4、总结

线程本质：独立执行的程序单元，支持硬件建模和动态验证场景。
验证环境设计：优先使用initial块和动态线程管理，避免always块的资源占用问题。
同步选择：
- 简单通知：事件（event）。
- 资源控制：旗语（semaphore）。
- 数据传递：信箱（mailbox）。

通过合理选择线程控制与同步机制，可构建高效、健壮的验证平台，兼顾性能与可靠性。

三、Verilog和SystemVerilog线程的定义

在硬件描述语言中，Verilog和SystemVerilog（SV）对线程（Thread）的实现理念存在显著差异。以下是两者的核心区别和演进关系的总结：

1. 线程基础概念的对比

Verilog中的线程

载体形式：仅通过initial和always块实现。
- always块：用于硬件行为建模（如时序逻辑），一旦启动则持续运行，不会自动终止。
- initial块：从仿真0时刻执行一次，通常用于初始化或简单测试逻辑。
并行控制：使用fork...join，但必须等待所有子线程完成后才能继续后续操作。
局限性：
- 缺乏动态线程管理能力，无法灵活创建或销毁线程。
- 线程同步依赖事件（event）和wait语句，功能较为基础。

SystemVerilog的扩展

新增并行控制结构：
- fork...join_any：任意子线程完成即继续父线程，其他线程后台运行（适用于超时控制）。
- fork...join_none：父线程立即继续执行，子线程异步执行（适用于动态任务触发）。
动态线程管理：
- 支持在类（class）中通过fork...join_none启动事务处理器，实现线程的动态创建。
- 可通过disable fork终止子线程，或通过wait fork等待所有子线程完成。

2. 线程同步与通信机制

Verilog的基础机制

事件触发：通过->触发事件，@或wait等待事件。
资源竞争风险：依赖共享变量传递数据，易导致竞争条件（Race Condition）。

SystemVerilog的增强

高级同步机制：
- 信箱（Mailbox）：线程安全的队列，支持阻塞式（put/get）和非阻塞式（try_put/try_get）数据传输。
- 旗语（Semaphore）：通过get()和put()管理共享资源访问，防止多线程冲突。
接口（Interface）：封装信号和协议，简化模块间通信，支持时钟块（clocking）管理时序。

3. 应用场景的差异

Verilog的硬件建模

适用场景：RTL级硬件设计，如时序逻辑（always @(posedge clk)）和组合逻辑。
资源占用：always块线程持续占用仿真资源，无法按需释放。

SystemVerilog的验证优势

动态验证环境：
- 测试平台通过initial块启动多个动态线程（如驱动、监测、检查器）。
- 支持面向对象编程（OOP），在类中管理线程生命周期。
高效资源利用：通过fork...join_none异步启动线程，避免阻塞主流程。

4. 语法与抽象层次的演进

时序控制精度：
- Verilog依赖timescale指令，易因编译顺序导致不一致。
- SystemVerilog引入timeunits和timeprecision全局声明，统一时间单位和精度。
抽象层次提升：
- 引入interface封装复杂总线协议，替代传统的端口连线。
- 支持C语言数据类型（如int、struct），便于系统级建模。

5. 总结：核心差异对比表

特性	Verilog	SystemVerilog
线程启动方式	`initial`和`always`块	新增`fork...join_any`/`join_none`
动态线程管理	不支持	支持类内动态创建和终止
同步机制	事件（`event`）和`wait`	新增`mailbox`、`semaphore`
通信抽象	直接信号连接	接口（`interface`）封装
资源占用	`always`块持续占用资源	按需创建和释放线程
适用场景	RTL硬件设计	验证平台和系统级建模

演进意义

SystemVerilog在Verilog的基础上实现了从硬件描述到系统验证的全覆盖，通过动态线程管理和高级同步机制，显著提升了验证效率和代码可维护性。其核心目标是通过更抽象的建模能力，解决复杂SoC验证中的并发控制和数据交互难题。

四、父线程和子线程的定义

在SystemVerilog中，父线程是启动fork块的线程（如initial或task），而子线程是fork块内并行执行的所有语句或代码块。两者通过fork...join系列结构实现并发控制，具体行为取决于join的类型。以下是详细说明及示例：

1. 父线程与子线程的基本关系

父线程：发起并发操作的主体线程，负责启动fork块并控制其执行流程。
子线程：fork块内定义的并行执行的代码段，可能包含多个独立分支。

示例场景

initial begin
    $display("[父线程] 开始执行");
    fork
        // 子线程1
        #10 $display("[子线程1] 延迟10ns完成");
        // 子线程2
        #5  $display("[子线程2] 延迟5ns完成");
    join
    $display("[父线程] 所有子线程完成");
end

父线程行为：等待fork...join内所有子线程完成后才继续执行。
子线程行为：并行执行，完成时间取决于各自的延迟。

2. 不同`join`类型对线程行为的影响

(1) `fork...join`：父线程等待所有子线程

父线程：阻塞直到所有子线程完成。
子线程：并行执行，无优先级顺序。

代码示例：

initial begin
    $display("[父线程] 启动");
    fork
        #10 $display("[子线程A] 完成");  // 子线程1
        #5  $display("[子线程B] 完成");  // 子线程2
    join
    $display("[父线程] 继续");
end

仿真结果：

[父线程] 启动
[子线程B] 完成  (5ns)
[子线程A] 完成  (10ns)
[父线程] 继续    (10ns后)

(2) `fork...join_any`：父线程等待任一子线程

父线程：任一子线程完成后立即继续，其他子线程后台运行。
典型应用：超时控制或优先级响应。

代码示例：

initial begin
    $display("[父线程] 启动");
    fork
        #20 $display("[子线程1] 完成");  // 子线程1
        #10 $display("[子线程2] 完成");  // 子线程2
    join_any
    $display("[父线程] 任一子线程完成");
    #30;  // 父线程继续执行其他操作
end

仿真结果：

[父线程] 启动
[子线程2] 完成  (10ns)
[父线程] 任一子线程完成  (10ns)
[子线程1] 完成  (20ns)  // 后台继续执行

(3) `fork...join_none`：父线程立即继续

父线程：不等待子线程，直接执行后续代码。
子线程：后台异步执行。

代码示例：

initial begin
    $display("[父线程] 启动");
    fork
        #15 $display("[子线程] 后台执行");  // 子线程
    join_none
    $display("[父线程] 立即继续");
    #20;  // 父线程执行其他操作
end

仿真结果：

[父线程] 启动
[父线程] 立即继续  (0ns)
[子线程] 后台执行  (15ns)

3. 动态线程管理注意事项

资源释放：
后台子线程（如join_none生成的）不会自动终止，需通过disable fork或信号量手动终止。
数据竞争：
若子线程共享变量，需使用mailbox或semaphore避免竞争条件。

示例：使用disable fork终止子线程

initial begin
    fork
        #100 $display("长时间任务");  // 子线程
    join_none

    #50 disable fork;  // 父线程50ns后终止所有子线程
end

总结

`join`类型	父线程行为	子线程行为	适用场景
`join`	等待所有子线程完成	并行执行，完成后父线程继续	需同步所有任务
`join_any`	任一子线程完成即继续	未完成的子线程后台运行	超时控制、优先级响应
`join_none`	立即继续，不等待子线程	后台异步执行	异步任务触发

通过合理选择join类型，可实现灵活的并发控制，适应不同验证场景的需求。

`五、fork...join_none`

在SystemVerilog中，fork...join_none的线程调度行为与父线程的执行流程密切相关。当父线程和子线程在20ns时刻都有任务需要执行时，其执行规则和优先级如下：

1. 线程调度规则

父线程的优先级：
父线程在fork...join_none后会立即继续执行后续代码，而子线程会被调度到后台队列，等待父线程遇到阻塞语句（如#delay、wait等）或终止时才开始执行。
20ns时刻的触发条件：
若父线程在fork...join_none后执行了一个阻塞语句（例如#20），则子线程会在父线程进入阻塞状态时开始并行执行。当父线程在20ns解除阻塞时，其后续任务将与子线程的任务在相同仿真时刻竞争执行。

2. 执行场景示例

场景1：父线程与子线程任务时间重叠

initial begin
    $display("[%0t] 父线程启动", $time);
    fork
        #20 $display("[%0t] 子线程任务", $time);  // 子线程在20ns触发
    join_none
    #20 $display("[%0t] 父线程任务", $time);      // 父线程在20ns触发
end

仿真结果：

@0: 父线程启动
@20: 父线程任务
@20: 子线程任务

解析：
父线程在0ns启动子线程后立即进入#20阻塞，子线程被调度但未执行。当父线程在20ns解除阻塞时，子线程的任务与父线程的任务同时就绪。由于仿真器在同一时刻处理事件的顺序不确定，两者可能并行执行，但实际打印顺序可能因仿真器实现不同而变化。

场景2：父线程任务优先

若父线程在20ns的任务需要立即执行（例如关键操作），而子线程的任务是后台计算，可通过以下方式控制优先级：

initial begin
    $display("[%0t] 父线程启动", $time);
    fork
        #20 begin 
            $display("[%0t] 子线程任务", $time);
        end
    join_none
    #20 begin
        $display("[%0t] 父线程任务开始", $time);
        // 父线程执行关键操作
        $display("[%0t] 父线程任务结束", $time);
    end
end

结果：
父线程的任务可能在子线程之前完成，具体取决于仿真器的调度策略。

3. 关键注意事项

阻塞语句触发子线程执行：
子线程在父线程遇到第一个阻塞语句时才会启动。例如，若父线程在fork...join_none后直接执行非阻塞操作（如赋值），子线程可能延迟到后续阻塞点才开始。
时序竞争与同步：
若父线程和子线程在同一时刻修改共享变量，需使用同步机制（如semaphore或mailbox）避免竞争条件。
动态线程管理：
可通过wait fork显式等待所有子线程完成，或在父线程结束时通过disable fork终止未完成的子线程。