• module logic_data_type(input logic rst_h);

•   parameer CYCLE =20;

•   logic q,q_1,d,clk,rst_1;

•   initial begin

•    clk<=0;//procedureal assignment

•    forever #(CYCLE/2) clk=~clk;

•   end 

•   assign rst_1=~rst_h; //continuous assignment

•   not n1(q_1,q); //q_1 is driven by gate

•   my_diff d1(q,d,clk,rst_1); //d is driven by module

endmodule

SystemVerilog引入了几种Two-state数据类型，以提高仿真性能并减少four-state类型变量的内存使用。最简单的数据类型是bit，它是无符号的。byte，shortint，int和longint是有符号数据类型：

  bit b; //2-state,signal-bit

  bit [31:0] b32;//2-state,32-bit unsigned integer

  int i;  //2-state,32-bit signed integer

  byte b8; //2-state, 8-bit signed integer

  shortint s; //2-state,16-bit signed integer

  longint l;  //2-state,64-bit signed integer

  如果你想用byte代替logic [7:0]，需要注意的是一个byte变量数据范围是-128到+127，而不是0~255。虽然可以使用byte unsigned，但这会让代码显得更冗长。

  在验证时，如果不小心将Two-state变量连接到DUT的输出，并且DUT将X或Z值驱动到这些Two-state变量，这些值被转换为两态值。

使用$isunknown运算符，如果该检查位是X或Z，则返回1。

if($isunknown(iport))

   $display("@%0d: 4-state value detected on inputport",$time, iport);

   本文来自于公众号数字芯片实验室。

本文将研究同步和异步复位的优缺点，然后给出正确使用两种复位的一些建议。

1.0复位目的

为什么要关注复位问题呢？为什么要把整篇文章用于这样一个琐碎的话题？使用过加载了某个操作系统的PC的任何人都知道硬件复位非常地方便，它会使计算机迅速地恢复到已知的工作状态。对于单个ASIC，复位的主要目的是强制ASIC设计进入已知的状态。

一般来说，ASIC中的每个触发器都应该是可复位的。在为ASIC选择合适的复位策略之前，必须考虑许多设计的问题：同步复位还是异步复位，部分触发器复位还是全部触发器复位，复位树的布局和缓冲树，如何验证复位树的时序，以及如何跨多个时钟域复位。 

2.0触发器编码风格

2.1具有非复位跟随器触发器的同步复位触发器

每个Verilog语句块都应该只建模一种类型的触发器。换句话说，设计师不应该在相同的语句块中混合使用有复位触发器与没有复位的触发器。

在例1a的Verilog代码中，使用触发器捕获数据然后其输出通过跟随触发器传递。因为两个触发器是在相同的语句块中的，所以复位信号rst_n将用作第二个触发器的数据使能。这种编码风格将产生无关逻辑如图1所示：

建模跟随触发器的正确方法是使用两个Verilog语句块，如图所示实例2a中所示。这些编码生成的逻辑如图2所示：

由例1a中的代码产生的多余逻辑只是使用同步复位的结果。 如果使用了异步复位方法，那么两种编码风格都可以综合成相同的电路而无需任何额外的组合逻辑。

2.2触发器建模风格

作为一种风格问题，所有具有特定功能的功能组件都应该使用单个语句块来描述。例如2.1节中讨论的跟随触发器。

3.0同步复位

同步复位仅仅在时钟有效边沿上影响触发器的复位状态。复位可以作为触发器组合逻辑的一部分，产生触发器的d输入。复位的编码风格应该是if / else优先级样式，仅在if条件满足的情况下进行复位操作。复位可能是相对于时钟周期的“迟到信号”，由于复位树的高扇出，需要限制复位逻辑到达触发器的逻辑层数。例3显示了一个这种同步复位方式的实现。

3.1编码风格和示例电路

示例3的Verilog代码显示了同步复位触发器正确的建模方式。复位信号不是敏感列表的一部分。这也是复位同步的原因。同时使用if-else编码使得复位信号优先于任何其他赋值语句。

同步复位的另一个问题是综合工具不能容易地区分复位和来自其他功能逻辑的信号。综合工具可能将例3的代码综合成图4的电路：

在功能上与图3相同。唯一的区别是MUX之前的组合逻辑。 现在，考虑一下在仿真开始时会发生什么？通过将rst_n置为低电平，两个与门可以将MUX的输出强制为0，但是如果ld未知（X），然后MUX输出值将保持未知（X）而不是被复位。这只是仿真过程中的问题！实际的电路仍然可以正常工作，触发器被复位为0。

3.2同步复位的优点

同步复位逻辑会综合成较小的触发器。如果设计资源紧缺，每个触发器节省一个或两个门，可以大大减小ASIC的面积。但是，在如今的die尺寸不断增大，每个触发器节省一个或两个门通常是无关紧要的。同步复位通常可确保电路100％同步。

同步复位确保复位只能在有效时钟边沿发生。时钟边沿能够滤除掉小的复位毛刺。但是，如果这些毛刺发生在有效时钟边沿附近，则触发器还是可能会变成亚稳态。任何违反setup time要求的信号都会导致亚稳态。通过将同步复位和预定数量的时钟周期作为复位过程的一部分，可以帮助满足复位缓冲树的时序。

使用具有良好编码风格的测试平台，使复位激励仅在时钟边沿产生，异步复位也可以获得和同步复位一样的仿真速度。

3.3同步复位的缺点

并非所有ASIC库都具有同步复位的触发器。但是同步复位只是另一个数据输入，你不需要特殊的触发器。复位逻辑可以在触发器之外轻松地综合出来。同步复位可能还需要脉冲展宽器来保证足够宽的复位脉冲宽度确保在时钟的有效边沿期间复位。

在进行多时钟设计时，可以使用一个计数器来保证复位脉冲宽度为一定数量的周期。

还有一个问题就是，相对于异步复位，同步复位不是那么容易被外部引脚控制。同步复位将至少需要一个周期复位电路。如果你使用门控时钟来节省电量，在这种情况下，只能用异步复位。

 本篇文章来自于公众号数字芯片实验室。

 相互间同步的时钟边沿来源于同一个时钟域，并且在电路工作的过程中所有寄存器的时钟边沿总是对齐的。所以，在采样数据时容易满足电路的建立时间（setup time）和保持时间（hold time）。然而，异步时钟产生的不同节拍可能会在电路工作时产生无法预见的建立和保持时间的违例(violation),从而导致芯片功能的错误。

        跨时钟域问题无法被传统的验证方式，例如动态仿真和静态时序分析（STA）鉴定出来。静态跨时钟域分析是验证跨时钟域正确性的最有效的方式。在数字电路设计的过程中，我们需要在RTL级检查跨时钟域问题，确保合适的同步策略被实施。

亚稳态

        在跨时钟的电路，由于建立时间和保持时间的违例，可能会产生和传播错误的数据，最终导致芯片功能的失败。

图上所示，B处数据存在亚稳态的问题，并且随机地传播B上的每个负载。

防止亚稳态传播的解决方法

  控制信号同步：控制信号的跨时钟域解决方法通常是利用多级触发器进行同步。

  数据信号同步：数据信号通常使用使能进行同步。当数据在跨时钟域路径上稳定时，然后使能数据接收寄存器。

除此之外，在数据跨时钟传输的过程中，尤其是模块之间的数据传递。

还可以采用更加复杂的握手和异步FIFO。

快时钟域到慢时钟域的数据采样问题

  当快时钟域短暂的脉冲传播到慢时钟域中时，可能会错过慢时钟域的时钟边沿，而不能成功采样到数据。如下图：

  通常，我们需要握手电路或者其他特殊的电路将快时钟域的脉冲至少扩展一个周期。当使用使能电路时，所有的快时钟到慢时钟的数据传输都需要进行CDC验证，以确认脉冲信号被扩展。当使用握手电路时，握手协议会保证在发送请求信号之前数据的稳定。

数据相关性和竞争冒险     

 上面提到，同步器可以在跨时钟电路中处理亚稳态问题。假设数据已经稳定了足够长的时间，然后被传输到目的寄存器。然而，对于多比特相关信号（例如状态机向量），由于亚稳态的问题，各个比特位数据的传输可能不会立刻发生，从而导致这些比特位相关性的丢失，最终产生错误的状态位。

复杂同步器

  FIFO和握手机制通常被用来进行跨时钟域的多比特数据传输。

 由于FIFO地址数据的跨时钟域问题，要进行合理地数据传输，需要及时正确地产生“空”和“满”信号。

 握手电路一般需要涉及到2个状态机之间的请求和响应，以在合适的时间稳定和采样数据。

   本文来自于陆科验证团队。

   柠檬口味和椰子口味的彩虹糖混合在一起可以产生柠檬蛋白派（lemonmeringue pie）的味道，草莓和香草口味的彩虹糖混合在一起可以产生草莓酥饼（strawberry shortcake）的味道。组合不同口味的彩虹糖居然可以产生如此多的奇特口味，不得不说很是期待呀。本小节就将会引入virtual sequence，帮助我们在彩虹糖工厂中创造出更多口味独特的彩虹糖。

   另外本小节还会引入Configuration的概念，介绍如何在顶层去配置整个验证环境，从而相应地更改验证环境的结构，进而描述Configuration的产生，传送，接收以及生效的整个过程。利用Configuration机制我们可以根据彩虹糖新口味的需求，快速更改我们彩虹糖工厂的结构和生产流程，创造出新的独特口味的彩虹糖，而不需要重新构建新的工厂。

   上一篇主要介绍了UVM验证环境中的uvm_subscriber，uvm_scoreboard以及整个验证环境uvm_env。还介绍了构造测试场景的测试用例uvm_test，以及我们的验证顶层top。以下是上一篇短文中主要介绍的内容。

• subscriber

class jelly_bean_fc_subscriber extends uvm_subscriber#(jelly_bean_transaction);

class jelly_bean_sb_subscriber extends uvm_subscriber#(jelly_bean_transaction);

• scoreboard

class jelly_bean_scoreboard extends uvm_scoreboard;

• env

class jelly_bean_env extends uvm_env;

• test

class jelly_bean_test extends uvm_test;

• top

module top;

一、验证平台结构图

   如图4.1所示，是更新之后的验证平台结构图。本节中的DUT即我们的彩虹糖评测员升级为可以同时评估两种口味的彩虹糖了。新的彩虹糖评测员也更名为jelly_bean_taster_subsystem，该DUT具有两个相同的interface: jelly_bean_if用来接受彩虹糖工厂生产出来的彩虹糖。为了供给彩虹糖评测员，彩虹糖工厂还新增加了一个小“车间”Agent来生产彩虹糖。为了协调两个彩虹糖车间，创造出更多独特口味的彩虹糖，彩虹糖工厂随之引入了Virtual Sequence: jelly_bean_recipe_virtual_sequence来控制彩虹糖的口味。

具体来说：

• 测试的顶层是uvm_test: jelly_bean_recipe_test。TEST中例化了整个UVM测试环境，预留了uvm_config_db机制来对整个UVM环境ENV和各个Agent进行配置，引入了jelly_bean_recipe_virtual_sequence来构造测试场景。

• ENV中创建了两个jelly_bean_agent分别通过jelly_bean_if去驱动jelly_bean_taster_subsystem。

• 两个jelly_bean_agent完全一致，都具有自己的monitor，sequencer，driver以及subscriber。除此之外，每个agent还具有控制自身结构的配置文件jelly_bean_agent_config，外部可以通过更改这个config文件来控制agent的结构，提高了验证平台的复用性。

图4.1 彩虹糖工厂验证平台结构图。

二、VirtualSequence

     Virtual Sequence定义了三种新彩虹糖口味的配方，分别是柠檬蛋白派（lemonmeringue pie）口味，草莓酥饼（strawberry shortcake）口味，苹果蜜饯（candy apple）口味。每种新口味的配方都是由两种原始口味的彩虹糖配方混合而成的。比如要生产出柠檬蛋白派口味的彩虹糖需要两份柠檬味的彩虹糖和两份椰子味的彩虹糖。自然而然新的配方Virtual Sequence就是由两个基本的原始彩虹糖配方same_flavored_jelly_beans_sequence构成。两个基本的彩虹糖配方被称为sub-sequences。具体的实现代码如代码4.1所示。

• 第2行：定义了三种新口味的配方名称，注释表明了该新口味的具体构成。

• 第8，9行：声明了两个jelly_bean_sequencer句柄，用以把构成新口味的两种基本彩虹糖配方即same_flavored_jelly_beans_sequence传送给相应的driver去生产所需的原生口味的彩虹糖。

• 第11，12行：声明了两个sub-sequence: same_flavored_jelly_beans_sequence分别代表了两种基本口味的彩虹糖配方，用以构成新口味的彩虹糖。

• 第19，20行：在virtual sequence中创建了组成新口味的两种基本口味彩虹糖的配方sub-sequence。

• 第21行：利用case语句，根据每种新口味的配方，选择基本口味的彩虹糖，以及调整每种基本口味配方的数量。举例来说要构成草莓酥饼口味的彩虹糖，需要草莓口味的彩虹糖两份，香草口味的彩虹糖两份。

• 第43，44行：通过预先声明的两个sequencer，同时将两个配置好的基本彩虹糖配方：jb_seq1和jb_seq2发送给各个车间agent中的driver去生产对应基本口味的彩虹糖。

代码4.1 [class] jelly_bean_recipe_virtual_sequence的实现

• [Note 1]virtual sequence的组成

• virtual sequence主要由多个不同内容的sub-sequence构成，其通过组合不同的sub-sequence来构建更加复杂的测试场景。

• virtual sequence中声明了多个sub-sequence对应的sequencer句柄，其选择采用start方式，分别通过相应的sequencer将多个sub-sequence发送出去。

• 本文并未采用将整个virtual sequence挂载到virtual sequenecer的方式来发送，主要是考虑到virtual sequencer会引入一个不必要的UVM组件，影响整个UVM环境的复用性。

三、包含virtualsequence的test

TEST中主要完成了virtual sequence的创建和随机，并将virtual sequence中声明的sequencer句柄链接到构成UVM环境的真正sequencer上。如此virtual sequence中的jb_seq1就会挂载到jb_agent1中的sequencer上，而jb_seq2则会挂载到jb_agent2中的sequencer上。最后通过start方式触发virtual sequence的发送，注意virtual sequence本身没有挂载到一个具体的sequencer上，所以start函数中的sequencer参数值为NULL。如代码4.2所示，是test的具体实现。

• 第9行：声明了一个用来产生新口味的配方virtual sequence: jelly_bean_recipe_virtual_sequence。

• 第12行：创建了该virtual sequence。

• 第13，14行：分别将virtual sequence中的两个sequencer句柄链接到了UVM环境中的两个agent中的sequencer上，用以完成两个基本sub-sequences的发送。

• 第15行：随机化已创建的virtual sequence，随机该virtual sequence中的配方种类，用以随机选择不同新口味的配方。

• 第16行：利用start方式触发该virtual sequence的发送。

代码4.2 [class] jelly_bean_recipe_test的实现

• [Note 2]virtual sequence的start函数中sequencer参数为NULL。

• 由于virtual sequence没有一个sequencer可以挂载该sequence，所以sequencer参数为NULL。

• 调用start函数时并非真正的去发送该virtual sequence，而只是触发该virtual sequence的body()任务，从而触发其中各个sub-sequences的自行发送。

四、使用virtual sequence构成的test的运行结果

   如图4.2所示，是该virtual sequence构建的测试场景，即利用该virtual sequence提供的新口味彩虹糖配方，彩虹糖工厂生产出来的新口味彩虹糖。

图4.2 包含virtual sequence的test的运行结果

   具体来看，该virtual sequence随机生成的是一个苹果蜜饯口味（candyapple）彩虹糖的配方。可以看出构成新口味的一个基本配方是苹果口味（apple）的彩虹糖，其份数是2份。另一个基本配方是肉桂口味（cinnamon）的彩虹糖，其份数是1份，符合我们的配方要求。

五、Configuration

  新的彩虹糖工厂中有两种配置信息jelly_bean_agent_config和jelly_bean_env_config。agent_config主要来配置彩虹糖工厂中的Agent小车间：jelly_bean_agent，影响Agent的结构和功能，我们可以通过agent_config来决定Agent中是否包含monitor，driver，fc_subscriber等组件。env_config主要来配置整个UVM验证环境jelly_bean_env的结构，可以通过env_config来决定验证环境中agent和scoreboard的数量。

六、agent的配置（agent configuration）

     jelly_bean_agent_config主要来配置jelly_bean_agent。agent_config中有两个配置开关：active和has_jb_fc_sub。

   active配置决定agent是一个active模式还是一个passive模式。在active模式下，会在agent(jelly_bean_agent)中额外创建sequencer(jelly_bean_sequencer)和driver(jelly_bean_driver)，但是若agent被配置为passive模式，agent中只会包含一个monitor(jelly_bean_monitor)而不会再额外创建sequencer和driver。

      has_jb_fc_sub配置决定是否会在agent中创建一个功能覆盖率收集组件jelly_bean_fc_subscriber。

配置文件中还包含一个virtual interface句柄virtual jelly_bean_if，用来向monitor和driver中传递virtual interface句柄。具体的实现如代码4.3所示。

• 第4行：创建了一个uvm_active_passive_enum枚举类型的变量active，并将其赋初值为UVM_ACTIVE。默认将agent配置成active模式，在其中创建除monitor外的driver和sequencer。

• 第5行：创建了一个bit类型的变量has_jb_fc_sub，并将其赋初值为1。默认在agent中创建功能覆盖率收集组件jelly_bean_fc_subscriber。

• 第7行：创建了一个virtual jelly_bean_if的句柄jb_if，便于后续virtual interface的传递。

代码4.3 [class] jelly_bean_agent_config的实现

  根据agent中的配置信息，agent可以被配置成如下4种结构的agent。如图4.3所示

图4.3 agent的4种可能配置结构图

七、验证环境的配置（Environment Configuration）

  与agent的配置文件jelly_bean_agent_config相类似，UVM验证环境的配置jelly_bean_env_config会影响jelly_bean_env的结构。env_config设计了4个配置开关，并且还分别为两个agent创建了一个agent_config配置信息的句柄。4个配置开关has_jb_agent1，has_jb_agent2，has_jb_sb1，has_jb_sb2分别决定UVM验证环境uvm_env中是否包含1号jelly_bean_agent，2号jelly_bean_agent，1号jelly_bean_scorboard以及2号jelly_bean_scorboard。agent_config的具体实现如代码4.4所示。

• 第4，5行：分别创建了一个bit类型的变量has_jb_agent1，has_jb_agent2并分别将其赋初值为1，表明jelly_bean_env中默认包含1号和2号jelly_bean_agent。

• 第6，7行：分别创建了一个bit类型的变量has_jb_sb1，has_jb_sb2并将其分别赋初值为1，表明jelly_bean_env中默认包含1号和2号jelly_bean_scoreboard。

• 第9，10行：分别声明了两个jelly_bean_agent的配置信息句柄jb_agent_cfg1和jb_agent_cfg2，便于后续在ENV中对agent进行配置。

代码4.4 [class] jelly_bean_env_config的实现

八、验证顶层模块（Top Module）

验证顶层对整个验证环境的配置主要在于interface的传递。Top模块中例化了两个jelly_bean_if，用来连接DUT(jelly_bean_subsystem)和整体验证环境。同时将这两个interface：jb_if1，jb_if2通过uvm_config_db::set的方式以virtual interface的形式存储在uvm_config_db库中，以便于后续在其他UVM验证组件中读取。具体的实现如代码4.5所示。

• 第17-20行：将interface以virtuali nterface的形式存储在了uvm_config_db库中，便于monitor和driver来调用，来监测和驱动DUT和ENV的数据传输。由于topmodule是一个verilog模块并非一个uvm_component。所以set()函数中的cntx参数是NULL。而run_test()任务会创建uvm_test_top实例，所以inst_name参数是uvm_test_top。

  
  

代码4.5 [module] top的实现

九、基础测试用例（BaseTest）

本文对验证环境的配置主要发生在base test中。Base Test中创建了配置ENV的jelly_bean_env_config以及两个配置Agent的jelly_bean_agent_config。并将jelly_bean_agent_config的句柄传递给了env_config的配置信息中，这样就可以在ENV的配置信息中索引到下层Agent的配置信息。最后将保存有ENV配置信息的jelly_bean_env_config通过uvm_config_db::set的方式存储在uvm_config_db库中，便于整体验证环境jelly_bean_env在构建自身的时候索引到该配置信息，并根据配置信息来创建ENV。

另外Base Test还会以uvm_config_db::get的方式，从uvm_config_db库中读取在TopModule中上传的两个virtual interface，并将其赋给相应的Agent配置信息。具体的实现如代码4.6所示。

• 第16-18行：分别创建ENV的配置文件和两个Agent的配置文件。

• 第20-27行：利用uvm_config_db::get()从uvm_config_db库中读取virtual interface: jb_if1和jb_if2，并将其分别赋值给两个agent_config中的jelly_bean_if，完成了interface从topmodule到agentcomponent的传递。

• 第29-30行：分别将创建的Agent的配置文件的句柄赋给ENV配置文件中定义的jb_agent_cfg1和jb_agent_cfg2，使得我们可以从jb_env_cfg中读取到各个Agent的配置信息。

• 第32-33行：将已经创建好的ENV的配置信息，通过uvm_config_db::set()的形式，存储到uvm_config_db库中，便于jelly_bean_env在建立自身内部结构的时候读取ENV的配置信息，并按配置信息创建jelly_bean_env中的各个组件。

代码4.6 [class] jelly_bean_base_test的实现

十、UVM验证环境（Environment）

      UVM验证环境jelly_bean_env会先读取上层test对ENV的配置信息，根据配置信息在build_phase中创建ENV内部的各个组件。如果ENV的配置信息里面表明jelly_bean_env中需要创建1号或者2号Agent，则就在ENV的build_phase中创建相应的Agent，并将相应Agent的配置信息通过uvm_config_db::set()的方式上传到uvm_config_db库中，便于Agent在创建自身的时候读取该配置信息，并根据配置信息创建其内部相应的组件。

  最后在connect_phase中根据配置信息完成各个Agent和Scoreboard的连接。具体的实现如代码4.7所示。

• 第17-20行：从uvm_config_db库中，使用get()方式读取ENV的配置信息jb_env_cfg。

• 第22-40行：根据获取的配置信息jb_env_cfg，创建内部的各个组件进而构成整个jelly_bean_env。

• 第22-25行：创建jelly_bean_agent。如果jb_env_cfg中的配置开关has_jb_agent1为1，表明需要在ENV中创建1号Agent。则先将1号Agent的配置信息jb_agent_cfg1使用uvm_config_db::set()的方式上传到uvm_config_db库中，然后再实际创建1号Agent：jb_agent1。

• 第27-29行：创建jelly_bean_scoreboard。如果jb_env_cfg中的配置开关has_jb_sb1为1，表明需要在ENV中创建1号Scoreboard。则使用type_id::create的方式实际创建1号Scoreboard：jb_sb1。

• 第47-48行：根据ENV的配置信息，连接我们的Agent和Scoreboard。如果配置信息中has_jb_agent1和has_jb_sb1都为1，表明ENV中会创建相应的Agent和Scoreboard，则相应地需要在connect_phase中连接这两个组件的TLM通信端口。

  
  

代码4.7 [class] jelly_bean_env的实现

十一、Agent

Agent会根据上层ENV对其设计的配置信息来创建自身的结构。具体的实现如代码4.8所示。

• 第19行：利用uvm_config_db::get()的方式从uvm_config_db库中读取Agent的配置信息。

• 第24-27行：如果Agent的配置信息中active配置开关为UVM_ACTIVE，表明该Agent为active模式。则为其创建相应的jelly_bean_sequencer和jelly_bean_driver。

• 第29-31行：如果Agent的配置信息中has_jb_fc_sub的配置开关为1，表明该Agent中含有功能覆盖率收集组件jelly_bean_fc_subscriber。则为其实际创建相应的subscriber组件。

• 第42-45行：如果Agent被配置成active模式，必然有Sequencer和Driver，则相应地需要在connect_phase中完成Sequencer和Driver的连接。

• 第47-49行：如果Agent被配置成具有jelly_bean_fc_subscriber，则也需要相应地在connect_phase将其和monitor连接起来，才能完成功能覆盖率的收集。

代码4.8 [class] jelly_bean_agent的实现

十二、配置信息在整个验证环境中的流动

  如图4.4所示，表示了各个配置信息包括virtual interface：jb_if，ENV的配置信息：jb_env_cfg，Agent的配置信息：jb_agent_cfg等在整个验证环境中的产生，传递过程。

图4.4 配置信息在验证环境中的流动

  以virtual interface：jb_if为例来说明此图。

   jb_if首先在top中创建，并被上传到uvm_config_db中，如虚箭头setjb_if所示。然后被读取到jelly_bean_agent_cfg中，如图中虚箭头get jb_if所示。所以可以看出jb_if在top module中产生，继而被存储到uvm_config_db中，然后从uvm_config_db中读取出来赋给jelly_bean_agent_cfg供其使用。

  本文来自于陆科验证团队。

  这一篇主要为大家介绍验证环境中的信息收集组件uvm_subscriber，数据结果比较组件(计分板)uvm_scoreboard，UVM环境uvm_env，测试用例uvm_test，配置验证环境的configuration以及验证顶层top，最后还将会给出一个仿真的结果。其在整个UVM验证平台中的结构如图3.1中的红色箭头所示。

图3.1 UVM验证平台整体结构

上一篇短文主要介绍了彩虹糖验证平台中的Sequencer，Driver，Monitor和Agent。以下是上一篇短文中主要介绍的类。

• sequencer

class jelly_bean_sequencer extends uvm_sequencer#(jelly_bean_transaction);

• driver

class jelly_bean_driverextends uvm_driver#(jelly_bean_transaction);

• monitor

class jelly_bean_monitor extends uvm_monitor;

• agent

class jelly_bean_agent extends uvm_agent;

一、功能覆盖率收集组件（function coverage subscriber）

功能覆盖率组件jelly_bean_fc_subscriber会对产生的彩虹糖作一个整体的记录。如第21行所示，jelly_bean_fc_subscriber在wirte函数中对从monitor中传递过来的transaction进行采样从而判断各种属性例如口味，颜色，甜度，酸度的彩虹糖是否都有产生，以及不同属性组合的彩虹糖是否也都有产生。如代码3.1所示，是jelly_bean_fc_subscriber的实现。

• 第7-10行：利用coverpoint建立功能覆盖率，分析彩虹糖的口味，颜色，甜度，酸度，确保各种属性的彩虹糖是否都有产生。

• 第11行：利用cross来建立功能覆盖率，分析彩虹糖各种属性的不同组合情况是否都有产生。

• 第19行：定义uvm_subscriber中的成员方法write函数，在write函数中进行功能覆盖率的采样。使得jelly_bean_fc_subscriber通过TLM端口和jelly_bean_monitor相连接之后可以使用monitor检测到的彩虹糖信息来判断各种属性的彩虹糖是否都有产生。

• 第21行：触发功能覆盖率的采样行为。

代码3.1 [class] jelly_bean_fc_subscriber的实现

二、记分板（scoreboard）

数据收集组件uvm_subscriber内设计了write函数和一个TLM端口analysis_export用来完成uvm_subscriber和其他组件之间数据的通信传输。uvm_subscirber的主要功能就是在write函数中体现的。在功能覆盖率收集组件jelly_bean_fc_subscriber中的write函数中触发功能覆盖率的采样，同样的记分板数据收集组件（scoreboardsubscriber）会在其write函数中调用jelly_bean_scoreboard的check_jelly_bean_taste函数来检查收集到的彩虹糖信息。check_jelly_bean_taste主要来检查DUT即我们的彩虹糖评测员（jelly_bean_taster）的反馈信息是否正确。jelly_bean_sb_subscriber的实现如代码3.2所示。

• 第10-15行：定义write函数，在write函数中调用jelly_bean_scoreboard的check_jelly_bean_taste函数。当jelly_bean_sb_subscriber与jelly_bean_monitor之间的TLM端口连接好之后便可以在monitor一侧调用该write函数，对monitor监测到的彩虹糖信息进行检查。

代码3.2 [class] jelly_bean_sb_subscriber的实现

• [Note 1]为什么需要一个$cast?

• 第11行只声明了jb_sb为jelly_bean_scoreboard类型，而未对其赋值，所以jb_sb是NULL值，无法索引到check_jelly_bean_taste函数。

• 第13行m_parent是每一个uvm_component所具有的。其是一个uvm_component类型，指向了一个子类对象jelly_bean_scoreboard。由于jb_sb是jelly_bean_scoreboard类型，所以把父类句柄复制给子类句柄时使用$cast来转换，使得jb_sb也可以指向jelly_bean_scoreboard对象，进而索引到check_jelly_bean_taste函数并完成预期的检查功能。

  我们通过check_jelly_bean_taste函数来检查monitor监测到的信息是否正确。我们期望DUT即我们的彩虹糖评测员，收到酸的巧克力口味的彩虹糖时会表现出负面评价，收到其他口味的彩虹糖时都给出积极的评价。通过对比DUT的反馈信息和监测到的彩虹糖信息来判断彩虹糖评测员是否给出了正确的评价。如果DUT评价正确，彩虹糖的口味和颜色信息都会被打印出来。当DUT评价错误，错误指示信息会被打印出来。如代码3.3所示是jelly_bean_scoreboard的具体实现。

• 第4行：在jelly_bean_scoreboard中声明一个uvm_analysis_export用来和jelly_bean_sb_subscriber中的analysis_export相连接进行TLM通信，传输jelly_bean_transaction。

• 第14行：在jelly_bean_scoreboard中创建了jelly_bean_sb_subscriber。

• 第19行：在jelly_bean_scoreboard中将创建的uvm_analysis_export和sb_subscriber中的analysis_export连接起来，进行通信。

• 第21-41行：定义check_jelly_bean_taste函数，实现具体的检查行为。其中定义了一个uvm_table_printer来对jelly_bean_transaction中的内容进行规范化的打印。

代码3.3 [class] jelly_bean_scoreboard的实现

• [Note 2] 为什么jelly_bean_scoreboard中使用uvm_analysis_export而不是uvm_analysis_imp?

• jelly_bean_scoreboard并不是TLM通信的终点，Monitor监测到的数据需要经过jelly_bean_scoreboard送给jelly_bean_sb_subscriber去做检查，所以jelly_bean_sb_subscriber才是信息传送的终点，其内部的端口才是uvm_analysis_imp。

• uvm_subscriber作为jelly_bean_fc_subscriber和jelly_bean_sb_subscriber的基类，其预定义有一个analysisimport被称为analysisexport。uvm_analysis_imp#(T, class_name) analysis_export。

• 所以jelly_bean_scoreboard中是uvm_analysis_export而jelly_bean_sb_subscriber中是uvm_analysis_imp。

三、UVM环境（Environment）

UVM环境包含了所有创建的验证组件，并在其中完成了各个组件之间的通信端口的连接。UVM环境的具体实现如代码3.4所示。

• 第14-16行：在env中创建了构建环境的各个组件，包括jelly_bean_agent，jelly_bean_fc_subscriber，jelly_bean_scoreboard。

• 第21-22行：将jelly_bean_agent中的uvm_analysis_port分别与功能覆盖率收集组件jelly_bean_fc_subscriber和记分板jelly_bean_scoreboard中的analysis_export相连接。便于monitor将监测到的jelly_bean_transaction分别送去分析功能覆盖率以及判断DUT的反馈是否正确。

代码3.4 [class] jelly_bean_env的实现 

四、测试用例（Test）

以下测试用例表示的是让彩虹糖工厂生产若干礼品盒装的无糖彩虹糖。该测试用例的具体实现如代码3.5所示。

• 第19行：使用set_type_override将所有jelly_bean_transaction替换成了sugar_free_jelly_bean_transaction，这样彩虹糖工厂生产出来的彩虹糖都是无糖的。

• 第20行：在测试用例中创建整个UVM环境jb_env。

• 第10-22行：为测试用例build_phase的部分。在该build_phase主要完成UVM环境配置文件的传递和基础transaction类型的替换即直接使用无糖彩虹糖配方，最后完成整个UVM环境的创建。

• 第28行：创建一个礼品盒装的彩虹糖配方即产生一个gift_boxed_jelly_beans_sequence。

• 第29行：随机礼品盒装彩虹糖的配方内容。

• 第31行：使用start方式将sequence交由sequencer发送出去。

• 第27和33行：使用objection机制来控制仿真的停止。在第27行提起一个objection防止仿真结束，在第33行在发送完sequence之后等待10ns撤销objection允许仿真结束。

• 第24-34行：为测试用例的run_phase部分。主要完成sequence的创建，随机和发送。

代码3.5 [class] jelly_bean_test的实现

五、配置（configuration）

将控制验证平台的各种参数集合在一起构成一个配置块，然后在创建验证平台之前将配置信息传递下去，这样就可以很方便地根据实际情况来配置整个验证平台。如代码3.6所示，是配置块的实现。在本文中，该配置块没有产生任何作用，仅仅是为了方便后续验证平台的复用。

代码3.6 [class] jelly_bean_configuration的实现

六、顶层（Top）

建立好测试用例，搭建好UVM环境之后，还需要建立一个Top模块，在其中例化待测设计，传递interface从而将硬件形式的待测设计和软件形式的验证平台连接起来以及通过run_test来启动uvm仿真。如代码3.7所示是Top模块的具体实现。

• 第5行：例化一个具有某一时钟频率的interface。

• 第6行：例化待测设计，并使用interace将其和验证平台连接起来。

• 第8-12行：产生时钟，为待测设计和验证平台提供100M频率的时钟。

• 第15-16行：使用uvm_config_db，以virtualinterface的形式将interface传递给验证环境中的各个组件，比如monitor，driver使得其分别可以监测接口上的信号值以及通过接口驱动待测设计。

• 第17行：使用run_test()来启动UVM仿真。

代码3.7 [module] top的具体实现

七、仿真（Simulation）

如图3.1所示，是运行jelly_bean_test后EDA工具打印出来的部分log。可以看出整个UVM验证平台功能正常，DUT即彩虹糖评测员反馈的信息正确无误。

图3.2 仿真部分log图

八、总结

我们按照开头的图3.1所示的结构搭建了整个UVM验证平台。在前几节，描述了UVM的基本运行过程，简单介绍了其中的一些运行机制。接下来的小节将会更深入的介绍一些例如virtual sequence等的UVM细节。

本文来自于陆科验证团队。

   这一篇主要会为大家介绍整个验证环境中一个小的子“环境”Agent，及构成这个小“环境”的Driver, Sequencer, Monitor等验证组件。Agent之于整个验证环境就相当于一个一个小车间之于整个工厂一样。

   上一篇短文主要介绍了彩虹糖验证平台中的interface和DUT。以下是上一篇短文中主要介绍的内容：

interface

interface jelly_bean_if(input bit clk);

clocking master_cb@(posedge clk);

modport master_mp(inputclk, taste, output flavor, color, sugar_free, sour);

DUT

module jelly_bean_taster(jelly_bean_if.slave_mp jb_slave_if);

一、Sequencer

    之前提到的彩虹糖的Sequence也就是包含彩虹糖口味颜色以及数量的配方，在我们的验证环境中会首先发送给Sequencer，然后再由Sequencer将配方Sequence传送给Driver，由Driver生产出相应的彩虹糖。彩虹糖验证平台中的Sequencer直接使用的是UVM提供的uvm_sequener没有添加任何新的内容。在下面的代码中jelly_bean_transaction作为参数来创建我们的Sequencer的类型，表明我们定义的Sequencer只能收jelly_bean_transaction类型的配方。例如jelly_bean_sequencer声明如下。

     typedef  uvm_sequencer #(jelly_bean_transaction)  jelly_bean_sequencer;

二、Driver

    Driver通过内部例化的seq_item_port这样一种UVM内部通信的TLM端口，从Sequencer获取配方内容jelly_bean_transaction。然后通过虚拟的接口(virtual interface)来驱动DUT，即将彩虹糖的内容解析出来转换成interface上端口的信号值并输出给DUT。virtual interface的传递是通过一种类似于共享资源池的机制uvm_config_db来完成的。如下面的代码所示：

• 第12-13行：使用uvm_config_db获取从TB顶层发送过来的virtual interface。

• 第22行：通过seq_item_port内置的[Task] get_next_item从Sequencer处获得item。

• 第24-24行：将激励内容解析之后驱动到端口上。

图1. [uvm_driver] jelly_bean_driver

三、Monitor

    Driver的数据流向是从TB流向DUT，而Monitor的数据流向正好与此相反。Monitor也是通过从uvm_config_db中获取virtual interface进而使得其能够监测DUT端口上的信号。Monitor会在每个时钟周期都检查接口jelly_bean_if上的信号值，当监测到我们生产出了一个无味（NO_FLAVOR）的有问题的彩虹糖时，就会立刻将此时interface上的信号值按彩虹糖配方的形式打包成jelly_bean_transaction。新创建的监测配方jelly_bean_transaction将通过另外一种TLM通信端口analysis_port经由Agent发送给客服中心的受理平台Subscriber来进行进一步的分析。如下面的代码所示：

• 第23行：在每个时钟周期的上升沿，通过interface检测生产出来的彩虹是否是无味的。

• 第24-28行：将采样到的信号打包成jelly_bean_transaction。

• 第16行：创建一个uvm_analysis_port用来和Agent中的相应的端口连接。

• 第31行：将打包好的jelly_bean_transaction通过uvm_analysis_port的[Task] write发送出去。

图2.[uvm_monitor] jelly_bean_monitor

 四、Agent

      Sequencer, Driver, Monitor被封装在Agent里面，可以构成一个独立的小整体，完成DUT的驱动以及信号的监测。这些uvm_component在Agent的build_phase中创建，在connect_phase中完成Driver和Sequencer等TLM通信端口的连接。

• 第18-20行：在build_phase中创建了Driver, Sequencer以及Monitor。

• 第25行：在connect_phase中完成了Driver中的seq_item_port和Sequencer中的seq_item_export端口的连接。

• 第26行：完成了Monitor的uvm_analysis_port和Agent的uvm_analysis_port的连接。

图3.[uvm_agent] jelly_bean_agent 

五、总结 

    Sequence, Sequencer, Driver之间的数据流动

图4.Seqence, Sequencer以及Driver之间的数据传输

       在UVM环境中一个uvm_sequence_item基本上就代表了我们激励的最小单元，一个item的产生到被消耗是UVM中主要的数据流动。item的生命周期起始于Sequence的body()任务中。在Sequence中完成激励item的创建与发送。Sequencer主要完成Sequence发送过程中的仲裁，并完成与Driver的握手传输，起的是连接Sequence与Driver的桥梁作用。Driver在接受到Sequencer传送过来的item之后会解析item中的内容，然后按照一定的时序将内容驱动到接口上进而驱动DUT。

    如上图所示one_jelly_bean_sequence在其[Task] body()任务中创建好一个item也就是jelly_bean_transaction。然后Sequence调用start_item()方法去向Sequencer申请仲裁并试图获取可以传输给Driver的授权。Sequnencer会查看Driver是否有需要Sequence的需求并且结合设定的仲裁模式授予某个Sequence可以通过的权限。Sequence在获得授权之后，将要发送的item进行随机化，继而调用finish_item()方法将随机好的item发送出去，然后等待Driver返回一些反馈信息。在Driver一侧，其通过与Sequencer相连接的TLM端口获取传送过来的item，完成item的驱动，最后产生一些反馈信息，重新通过TLM端口经有Sequencer返回给Sequence。Sequence在接受到反馈信息之后完成整个item的发送。一次完整的数据传输过程也就结束了。

本文来自于陆科验证团队。

  这一篇我们主要会介绍一个非常重要的概念interface, interface作为SV中唯一的硬件和软件环境的媒介交互，它的地位不可取代哦。另外，interface连接了我们生产彩虹糖的验证平台和我们的糖果爱好者，没有它我们也不可能吃到好吃的彩虹糖。

  上一篇短文主要介绍了彩虹糖验证平台中的transaction和sequence。以下是上一篇短文中主要介绍的一些类。

·  transaction

      class jelly_bean_transaction extends uvm_sequence_item;

      class sugar_free_jelly_bean_transaction extends jelly_bean _transaction;

·   sequence

       class one_jelly_bean_sequence extends uvm_sequence#(jelly_bean_transaction );

       class same_flavored_jelly_beans_sequence extends uvm_sequence#(jelly_bean_transaction );

       class gift_boxed_jelly_beans_sequence extends uvm_sequence#(jelly_bean_transaction );

一、接口(interface)

我们首先会对interface做一个大概的介绍。jelly_bean_if（我们彩虹糖验证平台中的接口）的主要作用就是来连接我们的验证组件和我们的待测设计(DUT)。jelly_bean_if内的主要代码如下图所示。总体上来说jelly_bean_if内包含的大部分的信号都是从jelly_bean_transaction中提取出来的。

图1.jelly_bean_if

相应信号的时序信息是由时钟块(clockingblock)来定义的。master_cb时钟块是从主控总线（bus-master）的角度来定义时序的，而slave_cb时钟块是从受控总线（bus-slave）的角度来定义时序的。

该接口还定义了一些modport列表，规定了interface中一些信号的方向。总计有4个modport列表。如下所示。DUT使用的是异步的modport(master_mp和slave_mp)，测试平台使用的是异步的modport(master_sync_mp和slave_sync_mp)。

表1.modport列表

 二、DUT

下面的代码描述的是一个简单的DUT也就是我们的彩虹糖评测员，会反馈彩虹可口程度的jelly_bean_taster.第一行使用了我们上面定义的接口jelly_bean_if来作为module的端口信号，slave_mp这个modport来定义信号的输入输出方向。从代码中可以看出，彩虹糖评测员只会给酸巧克力口味的彩虹糖差评，其他口味的都是好评。也就是当从interface输入给DUT的flavor信号是巧克力口味，并且sour信号是1的情况下，jelly_bean_taster的输出taste会输出YUCKY值，其他情况都是YUMMY值。

图2.jelly_bean_taster

当然，我们也不一定需要在module定义的时候指定modport，也可以在例化module并进行连接的时候指定modport信息。

图3. 在例化的时候指定modport

    我们也可以同时在定义和例化module的时候指定modport，但是前提是这两个modport得完全一样。如果在interface中没有定义任何modport来指定信号的方向，那么这些信号默认就是inout类型的方向。

• 总结interface,clocking, modport, 采样以及驱动

• interface

1. interface的创建使用关键词interface/endinterface。在interface的端口列表中只需要定义时钟、复位等公共信号，或者不定义任何端口信号，转而在变量列表中定义各个需要跟DUT和TB连接的logic变量。为了简单易用，我们推荐使用logic来定义变量。例如在jelly_bean_if中我们只定义了clk这一个端口信号“input bit clk”. 在变量列表中定义了TB和DUT要交互的一些信号例如flavor,taste, color等信号。

2. interface在例化时，同module的例化方式一样。对于有对应interface的DUT和TB组件（例如stimulator），在其例化时，也只需要传递匹配的interface变量名即可完成interface的变量传递。例如我们只需要在图3的moduleTOP中将jelly_bean_if例化成jb_slave_if，然后将jb_slave_if.slave_mp传递给例化的DUT即可完成连接interface与DUT的连接。如下图也是一种连接方式。

  3.interface中可以声明一些modport来将信号分组，并定义一些信号的方向信息。可以定义一些时钟块(clockingblock)来做一些同步的驱动和采样。

• modport

1. 使用modport来规定interface中定义的信号的方向。比如jelly_bean_if中master_mp将flavor,color定义为output，而在slave_mp中又将其定义为input。这两个moport的使用场景不一样，对于master生产彩虹糖的一方来说，会口味以及颜色等信息是作为输出来表明彩虹糖的属性。对于slave接受并评估彩虹糖可口程度的一方来说，需要口味和颜色这一些信息作为输入，这样才能评估生产出来的彩虹糖是否符合要求。

•  时钟块(clocking block)

1. interface中可以使用时钟块来指定一些同步信号相对于时钟的时序，使得我们可以在TB中使用和DUT相同的时钟来进行同步的驱动和采样。可以很大程度上避免DUT和TB的竞争状态。

2. clocking在声明完名字之后，应该伴随着定义默认的采样事件，即“defaultinput/output event”。如果没有定义，则会默认地在clocking采样事件前的1step对TB输入进行采样，在采样事件后的#0对TB输出进行驱动。在jelly_bean_if中master_cb定义了在clk上升沿前1个step采样DUT输入给彩虹糖测试平台的taste信号的值，在当前clk上升沿后的1ns驱动给DUT的输出flavor,color等信号。

• 采样和驱动

1. 一般来说时钟块只在TB中使用，用来做一些同步的驱动和采样，因为这也代表着一种对时序信息的模拟。而不在DUT的端口上使用时钟块，因为design内部自己会定义好同步异步的时序信息。

2. TB中使用clocking对input进行采样，对output进行驱动的，相对于clock的关系大致如下

1. 3. 对于驱动和采样，我们设计了一个更加详细的例子来说明这个问题。

具体的波形图如下所示

TB通过时钟块去采样DUT的output的值来作为TB的input，如sig1到sig3所示：

• sig1是TB通过时钟块采样到的信号值。

• sig2是TB时钟块的定义的input的信号值。

• sig3是DUT输出的值。

TB通过时钟块去驱动TB的output去作为DUT的input，如sig4到sig6所示：

• sig4是TB内部产生的激励，通过时钟块驱动给DUT

• sig5是时钟块内部的定义的output的信号值。

• sig6是DUT输入的值。

对于TB而言其时钟块的值发生变化都是在时钟上升沿，只不过对于采样而言，采样点是在时钟上升沿之前；对于驱动而言，实际驱动值变化会在时钟上升沿叠加一个偏移量之后发生，这样可以保证DUT的输入能够准确无误。

   北京百瑞互联技术有限公司是百瑞互联是一家蓝牙及无线智能硬件服务提供商，专注于无线互联和音频智能硬件解决方案，主营业务有蓝牙模块产品的研发、WiFi模块产品的研发、无线方案定制等。目前已与多家蓝牙和WiFi芯片原厂保持深度合作关系。是蓝牙国际组织的高级会员，国内唯一参与蓝牙规格制定的公司，拥有自主知识产权的蓝牙射频和协议栈算法两大IP，聚焦物联网和汽车电子两大领域。（汽车电子、智能家居、无线音频、智慧医疗、智能工业） 

   百瑞互联持续不断的开发并发布行业领先的产品。它拥有四条产品线：
   1）Bluelet产品线：该产品线提供蓝牙核心协议栈软件。该蓝牙协议栈IP兼容从版本1.1到版本5的所有蓝牙核心规范，其具有消耗资源少，代码量小，效率高以及优异的互联互通性等特点。全球著名的蓝牙芯片厂商都与我司合作或者配套我们的软件支持他们的客户，这些厂商包括CSR（Qualcomm），华为，Ralink（MTK）和ISSC（Microchip）等。
   2) 汽车电子产品线：该产品线提供汽车级的蓝牙/Wi-Fi解决方案，并提供车载级别的声学处理技术。我们服务主要的Tier1厂商，包括Pioneer，德赛西威，华阳，好帮手，远特，天派，索菱等。
   3) 物联网产品线：该产品先提供“云-管-端”的整体解决方案，包括i和br系列无线模块，网关模块，iBridge中间件以及云接入服务。客户群包括Mitac（神达）, Magellan（麦哲伦）, Inventec（英华达）, SNBC(山东新北洋), Contec(康泰)，Lakala(拉卡拉) 等。
   4) 音频产品线：该产品线主要聚焦在创新性蓝牙耳机和蓝牙会议电话产品，我们提供带有传感器算法的蓝牙耳机，TWS蓝牙耳机，主动减噪（ANC）蓝牙耳机以及蓝牙会议电话。我们目前客户包括宝利通（Polycom），中创视讯（Hexmeet）和Maxway等。

   公司总部位于中国硅谷中关村上地国际创业园，在深圳拥有分公司，在上海、韩国首尔、日本东京、台湾台北等地拥有公司的销售代表处。

  公司已获知名机构投资（腾业创投），工作满一年的员工可参与股权激励，公司致力于为员工提供有竞争力的事业发展平台。提供餐补、加班补贴、年度体检、年度旅游、团队建设、加班零食等。 

核心价值

    全球三大蓝牙协议栈IP供应商之一，国内唯一参与蓝牙规格制定的公司

    全球成本最低的最通用蓝牙物联网芯片设计公司

  大陆第一的汽车电子蓝牙WiFi方案，高速多连接蓝牙方案(小米)独家提供商

创始团队专注于蓝牙通讯技术

        • 10年聚焦专注

        • 射频、基带、协议栈算法专家

        • 蓝牙发明专利16项

致力于成为全s球最值得信赖的短距离无线通信公司 

模拟集成电路设计工程师

岗位职责：

1、负责新模拟IP的定义，仿真，设计；

2、负责模拟IP的数据手册文档更新，编写，维护；

3、负责模拟IP的测试，评价，维护；

4、参与SOC芯片规格定义，芯片测试和量产支持

5、参与电源管理方向或者audio codec方向，IC规格定义,项目开发,芯片测试和量产支持

相关技能要求：

1、了解半导体器件物理与工艺等相关基础知识；

2、能够独立分析并设计如下模块或其中之一：

OP;PGA;OSC;ADC;DAC;DCDC;LDO;CODEC等IP模块；

3、会使用实验室基本测试设备进行IP测试，评价与分析。

4、有低功耗CODEC设计经验者优先考虑

5、有高速ADC/DAC IP设计经验者优先考虑

6、有高精度Sigma-Delta ADC/DAC IP设计经验者优先考虑

7、DC/DC 设计经验者优先考虑

8、良好的文档能力，能够高质量撰写各类工作报告

9、要求具备团队合作精神，自我激励，能够按进度及计划完成任务

ASIC设计工程师

Job Description

·        Independent block and SoC RTL design and verification

·        Analog and digital IP integration

·        RTL handoff quality check using EDA tools

·        Prepare signoff quality full chip SDC file

·        Prepare signoff quality full chip UPF file

·        Support ASIC implementation

·        Support FPGA prototyping

·        Support DFT integration

·        Support software and system production

·        Write design documents

Qualifications

·        5+ years hands-on experience in ASIC RTL design. Experience in Bluetooth, Mobile Computing or IoT is a plus

·        5+ 年 实践 经验 ASIC RTL 有蓝牙、移动计算或物联网经验者优先

·        Familiar with popular ASIC solutions (including specification and architecture)

·        Familiar with ASIC design verification and implementation flow

·        Familiar with relevant QA tools (for example Spyglass)

·        Strong debugging and analytical skills, generate ideas, and provide innovative solutions to solve technical problems

·        English documents reading

·        Good programming in Perl/Python, TCL and Shell programming

·        Self-motivated, team work, and good communication skills

联系方式： 微信 chipist1  邮箱bluesky123362@sina.com. 

Location

      Room 310, No.500, Bibo Road, Pudong, Shanghai

上海黄浦区碧波路310,500

AI算法工程师

职位描述：

1. 深度学习算法的实现、调参和优化；

2. 训练/验证数据的搜集和整理；

3. 算法文档的编制；

4. 向其他研发人员提供相关的技术支援。

职位要求：

必要项：

1. 有以下经验之一：

  a. 机器学习，

  b. 图像/视频处理、计算机视觉；

2. 熟练掌握C/C++、Python；

3. 具有良好的沟通、表达能力；

4. 能够熟练阅读英文资料，独立工作能力强；

5. 具有团队合作精神，积极主动，有责任心，能够在一定压力下工作。

加分项

1. 熟悉任意深度学习框架；

2. 有深度学习硬件加速、模型压缩经验。

FPGA工程师

职位描述：

1.参与项目需求分析，将用户需求转化为FPGA设计需求；

2.制定FPGA开发计划；

3.负责编写FPGA方案设计和通信协议；

4.负责FPGA编程；

5.负责FPGA的调试和测试，参与系统测试；

6.负责编写FPGA相关开发文档；

7.参与制定FPGA设计规范、开发流程、评审流程

职位要求：

1.熟悉FPGA开发环境，熟练掌握一种硬件描述语言（Verilog、VHDL等）；

2.至少熟练使用一种FPGA仿真工具；

3.熟练使用Xilinx等主流厂商的FPGA芯片；

4.熟悉FPGA原理和常用的接口设计；

5.熟悉数字电路，有一定的硬件电路基础；

6.大学本科以上学历，电子，信息，计算机相关专业，6年以上工作经验。

SOC Design Engineer

职位描述：

Define chip specification and chip architecture refinement;

Top level integration including CPU, DDR, Video processors, bus fabrication and miscellaneous interface IPs;

Front-end flow including RTL design, synthesis, verification and static timing check;

Co-work with verification and physical design team;

Support FPGA validation and silicon bring-up;

职位要求：

必要项：

BS degree in a related technical field (e.g., EE or CS) , at least 5 years of industry experience

Extensive hands-on experience covering front-end flow: RTL design, verification, synthesis, DFT and timing closure

Experience with using ARM IP ecosystems (e.g., Cortex A-series CPUs, AMBA3/4, etc.) in the context of SoC

Strong knowledge of low power design fundamentals

Good communication skills and fluent in both Chinese and English

Self-motivated in solving problems

Good team player

加分项

Experience with silicon bring up (from reset to boot to high-level OS)

Knowledge of production/manufacturing flow is a plus

Experience on video/audio products is a plus

Experience with Perl/Tcl/Python/Shell/Makefile scripting strongly desired

芯片设计工程师

职位描述：

1. 分析数字芯片设计需求，定义模块架构，撰写设计文档。

2. 完成数字芯片前端RTL设计，并满足时序要求。

3. 规划验证计划，验证用例，完成模块和系统仿真。

4. 芯片综合、形式验证、STA、DFT等流程实现。

5. 配合系统团队完成FPGA平台和芯片平台的调试工作。

职位要求：

必要项：

1. 硕士及以上学历，电子，信息和计算机等相关专业毕业。

2. 芯片设计领域3年以上的工作经验.

3. 熟悉数字芯片设计流程，具备优秀的verilog编程能力。

4. 熟悉验证方法学，有较强的分析能力。

5. 熟悉FPGA基本原理与设计实现。

6. 积极主动，学习能力强。

加分项

1. 有ISP设计经验者优先。

2. 有CPU/DSP/GPU等处理器设计经验者优先。

3. 有深度学习算法知识者优先。

职位信息

职位描述：

Work closely with the SoC design team on understanding the system features being designed;

Develop and execute test plans for system level functional features

SoC DV test bench and infrastructure development and maintenance

Implement directed and random test cases in C++/SV, as well as checkers and assertions

Support integration and qualification of all the IPs for SoC

SOC Verification Engineer

职位要求：

必要项：

- Work closely with the SoC design team on understanding the system features being designed;

- Develop and execute test plans for system level functional features

- SoC DV test bench and infrastructure development and maintenance

- Implement directed and random test cases in C++/SV, as well as checkers and assertions

- Support integration and qualification of all the IPs for SoC

加分项

- 3+ years DV experience with good understanding on IP level verification and system level verification;

- Familiar with knowledge of methodology and industry standard tools for verification

- Experience on video/audio products is a plus

- Good communication skills and fluent in both Chinese and English

- Self-motivated in solving problems

嵌入式软件工程师

职位信息

1.针对IPC的嵌入式linux应用程序设计、开发、移植、调试和维护；

2.设计并开发公司相关平台的SDK;

3.负责撰写软件开发相关文档；

4.与其他相关部门沟通协调产品在每个阶段遇到的问题;

职位信息

职位描述：

1 设计和开发ASIC固件

2 配合测试硬件平台，包括优化和调试

固件研发工程师

职位要求：

必要项：

- B.S. or above in CS/CE/EE

- A minimum of 3+ years' experience on driver or embedded SW development and closely interact with HW designers

- Extensive C programming experience in embedded system development

- Familiar with Linux, knowledge and experience of device driver or firmware development is required hands-on

- Solid knowledge of industry standards including ARM, MEMORY, ISP, DMA, SDIO, USB, I2C, SPI, and UART, etc

- Experience of ASIC firmware development is a strong plus.

- Must have excellent communication skills and be comfortable interacting with hardware, firmware, FPGA engineers, and customer support engineers

- Working knowledge of version control system such as SVN or Git

- Strong verbal and written communication skill

- Good communication model and ability to follow up assignment actively with open mind

加分项

有ASCI固件开发经验，有linux驱动开发经验 

上海齐感电子信息科技有限公司 

国内机器视觉领域先行者及智能芯片研发公司， 致力于打造机器视觉的核心处理器芯片，提供各类智能终端以及智能服务机器人的解决方案。具有行业内领先的完备智能芯片生态和成熟产品。

公司核心产品有低功耗人工智能芯片、高性能智能感知模组、世界领先的神经网络算法等，以EI（边缘智能）为核心理念，为智能家居、智慧商业、智慧工业、智慧医疗、智慧行车、智慧城市及政府项目-雪亮工程等提供机器视觉的解决方案。

联系方式： 微信 chipist1  邮箱bluesky123362@sina.com. 

联系方式： 微信 chipist1  邮箱bluesky123362@sina.com

公司于2006年在上海成立公司，于2012年8月10日在无锡成立公司，注册资本1111万元。公司扎根无锡后致力于研发和产业化推广适用于移动智能终端的无线多媒体芯片。拥有自主研发的国内领先的CMMB项目产品MXD0265、硅调谐器产品MXD1516及国标数字电视项目产品MXD1325等；

公司于2013年开始战略调整，根据智能手机，4G时代的兴起，公司的主打产品从CMMB产品，转变为GPS LNA低噪声放大器芯片，4G LTE LNA低噪声放大器芯片，4G高阶射频开关芯片，还有BLE低功耗蓝牙芯片。关注于移动终端无线连接芯片市场，除了手机市场，还涉及到物联网市场，智能家居，智能医疗，智能交通等领域。

公司团队成立已经有10年之久，起起伏伏，跌跌宕宕。公司有过短暂的辉煌，但由于忽视了市场，经历了一段痛苦的低谷时期。但是金子总是会发光的，我们的研发团队非常优秀，也非常团结，在痛苦转型后，找准了产品市场方向。从GPS LNA产品开始，再到 SWITCH开关，公司业绩飞机式上升。

公司注重人才，为员工提供氛围和谐舒适的工作环境。希望有理想有冲力的每一个你加入我们卓胜Family。 

上海市浦东新区博霞路50号202室

数字IC设计高级工程师

职位信息

工作职责： 

本职位研发的芯片属于物联网领域，无线连接MCU芯片研发。

本职位主要是芯片数字电路设计开发，根据MRD和系统工程师/算法工程师一起制定芯片架构和模块划分，核心模块RTL实现及验证，并且参与到芯片的各个设计阶段，包括系统分析，时序分析，形式验证，DFT等，配合完成FPGA测试，芯片测试等。

职位要求： 

1、 电子，通信等相关专业硕士或以上学历，三年以上数字电路设计工作经验;

2、精通Verilog HDL和前端数字设计流程，具备时序分析能力;

3、熟悉C/C++语言，熟悉Perl/shell脚本语言;

4、英语CET-4以上，能够熟练阅读英文开发资料;

5、具有良好的设计文档编写能力和习惯;

6、具有出色逻辑思维，良好沟通能力，积极主动，有责任心和进取心;

7、具备以下一项或多项经验者优先:

- 有MCU设计，外设设计经验

- 有数字信号处理，安全加减密经验

- 有蓝牙modem和baseband设计或集成经验

- 有低功耗设计经验

射频设计工程师

职位信息

1、 射频电路模块的设计开发，包含并不限于以下电路：

  a、 PA Module、LNA、Switch等射频电路及模块

  b、 IPD、Filter、Duplexer和封装等电磁场仿真设计

  c、 RFCMOS模拟电路模块设计

2、 负责射频电路及模块的测试验证及实验室调试

3、 负责RF器件和电路版图设计及后仿和封装仿真验证

4、 负责射频模块的可靠性测试及分析

5、 参与RF器件的建模及材料设计

职位要求：

1、 熟练使用ADS、Cadence、MMSIM和电磁仿真等设计工具

2、 较强的版图设计经验和电路测试分析能力

3、 突出的动手和主动学习能力

4、 良好的沟通/团队协作能力

5、 研究生及以上学历，半导体物理和微电子专业

有下列经验的优先：

1、 有过完整的PA Module 或LNA产品开发经验

2、 熟练掌握RFCMOS、RFSOI及GaAs HBT的设计及调试方法

3、 熟悉半导体器件、材料及工艺

4、 了解大功率封装设计及可靠性分析方法

5、有工作经验优先，应届生亦考虑。

模拟设计工程师

职位信息

1、 模拟集成电路的设计开发

2、 指导版图设计及后仿验证

3、 负责电路调试及性能验证

职位要求：

1、 熟练使用Cadence设计工具

2、 良好的版图设计经验和电路测试分析能力

3、 较强的动手和主动学习能力

4、 良好的沟通/团队协作能力

有下列经验的优先：

1、 有过Buck 和Boost DCDC开发经验

2、 有高精度delta-sigma ADC/DAC开发经验

3、 熟悉超低功耗模拟电路设计方法

4、 熟悉IO及ESD设计方法

5、应届生优先考虑