第四章 约束进阶：权重约束、条件约束、内嵌约束、solve…before

各位同学，欢迎来到约束进阶的环节。说实话，基础约束就像学开车时的直线行驶，而今天要讲的这些，才是真正的山路弯道和夜间驾驶。我在项目里见过太多人，基础约束写得飞起，一到复杂场景就抓瞎。嗯，今天咱们就把这些硬骨头啃下来。

4.1 权重约束：让随机更有“倾向性”

先问大家一个问题：如果你要随机生成一个数据包，希望大部分是正常包，偶尔来几个异常包，你会怎么做？

有人可能会说：我写两个约束块，分别控制。但这样太死板了。更好的办法是用权重约束。

class Packet;
  rand bit [7:0] length;
  
  constraint c_length {
    length dist {
      [64:128] := 80,   // 80%的概率落在64-128
      [256:512] := 15,  // 15%的概率落在256-512
      1024      := 5    // 5%的概率是1024
    };
  }
endclass

这里有两种写法要注意：:= 表示每个值的权重相同，:/ 表示总权重均分。我个人习惯用 := 做范围约束，用 :/ 做单值约束，这样逻辑更清晰。

我在项目中遇到过这样一个坑：有个同事用 dist 约束地址范围，结果仿真跑了一整天都没覆盖到边界值。后来发现他把权重写反了，边界值权重设成了1，正常范围设成了99。你想想看，随机一万次才可能碰到一次边界，这覆盖率能上去才怪。

4.2 条件约束：if-else 的随机艺术

条件约束，说白了就是让约束“看人下菜碟”。不同的模式，走不同的约束路径。

class Transaction;
  rand bit [3:0] mode;
  rand int      data;
  
  constraint c_mode_data {
    if (mode inside {[0:3]}) {
      data inside {[0:255]};
    } else if (mode inside {[4:7]}) {
      data inside {[256:511]};
    } else {
      data == 0;
    }
  }
endclass

这里有个容易犯的错误：条件约束里的变量，必须保证在所有分支下都有定义。我曾经见过一个案例，某位同学在 else 分支里忘了给 data 加约束，结果仿真器报了个随机化失败。排查了半天，才发现是约束不完整。

另外，条件约束可以嵌套。但我不建议超过三层。为什么呢？因为可读性会急剧下降。你想想看，三个月后你自己回来看这段代码，可能都要琢磨半天。

4.3 内嵌约束：临时加戏的利器

有时候，我们不想修改类定义，只想在某个测试用例里临时加一条约束。这时候内嵌约束就派上用场了。

class Packet;
  rand int addr;
  constraint c_default {
    addr inside {[0:1023]};
  }
endclass

// 在测试用例中
Packet p = new();
p.randomize() with {
  addr inside {[512:1023]};  // 临时覆盖默认约束
};

内嵌约束的语法是 randomize() with { ... }。注意，花括号里写的是约束表达式，不是代码块。我刚开始用的时候，老想着在里面写 if-else，结果编译都过不了。

我个人习惯把内嵌约束用在两种场景：一是构造特殊测试用例，比如制造一个超大包；二是调试时临时限制随机范围，快速复现某个bug。

4.4 solve…before：解决约束求解的顺序问题

这个知识点，说实话，是很多人的盲区。先看个例子：

class Example;
  rand bit [3:0] a, b;
  
  constraint c_ab {
    a inside {[0:15]};
    b inside {[0:15]};
    a + b == 10;
  }
endclass

这个约束看起来没问题，对吧？但如果你希望 a 先随机，b 根据 a 的值再决定，就需要 solve...before 了。

constraint c_order {
  solve a before b;
  a inside {[0:15]};
  b inside {[0:15]};
  a + b == 10;
}

加了 solve a before b 之后，仿真器会先确定 a 的值，再根据 a 的值去求解 b。这样 a 的分布会更均匀，不会因为约束求解器的优化策略而出现偏差。

我在项目中遇到过这样一个场景：要生成一组地址，要求地址对齐到4字节，同时地址范围在0-1023。如果不加 solve...before，仿真器可能会优先满足对齐条件，导致地址分布不均匀。加了之后，地址先随机，再对齐，分布就合理多了。

4.5 知识体系总览

说了这么多，咱们用一张图来梳理一下今天的内容：

4.6 综合实战：一个完整的例子

最后，咱们把今天学的知识串起来，写一个完整的例子：

class ComplexPacket;
  rand bit [7:0] length;
  rand bit [15:0] payload[];
  rand bit [3:0] priority;
  rand bit       is_error;
  
  // 权重约束：长度分布
  constraint c_length_dist {
    length dist {
      [64:128] := 70,
      [256:512] := 25,
      1024      := 5
    };
  }
  
  // 条件约束：优先级与长度的关系
  constraint c_priority_length {
    if (priority inside {[0:3]}) {
      length inside {[64:128]};
    } else if (priority inside {[4:7]}) {
      length inside {[256:512]};
    } else {
      length == 1024;
    }
  }
  
  // solve...before：先确定优先级
  constraint c_order {
    solve priority before length;
  }
  
  // 动态数组约束
  constraint c_payload_size {
    payload.size() == length;
  }
  
  // 错误包约束
  constraint c_error {
    if (is_error) {
      length inside {[512:1024]};
    }
  }
endclass

// 测试用例中使用内嵌约束
module test;
  initial begin
    ComplexPacket p = new();
    // 生成一个高优先级的大包
    p.randomize() with {
      priority inside {[8:15]};
      is_error == 0;
    };
  end
endmodule

这个例子涵盖了今天讲的所有知识点。你想想看，如果没有这些进阶约束，要实现同样的随机效果，得写多少冗余代码？

好了，今天的课就到这里。记住，约束不是越复杂越好，而是越精准越好。我在项目里见过有人把约束写得像天书，结果自己都看不懂。嗯，咱们的目标是：用最简洁的约束，覆盖最全面的场景。