UVM——Fun with UVM Sequences - Coding and Debugging
0. 介绍
今天早上，发现Mentor Verification给我发了一封推送邮件，说有关于验证的最新研究。我是要做验证工程师的男人，看到这，能不打开吗，找了一篇关于UVM sequence的文章—— Fun with UVM Sequences - Coding and Debugging。哇，这个外国人写得确实不错，一上午拜读，也自己跑了其中的一些东西，顺便也整理了一下这篇文章的东西。原文都是复制的，中文的地方是我自己的理解。
CREATING A SEQUENCE
The test below creates a sequence inside a fork/join_none. There will be four sequences running in parallel. Each sequence has a LIMIT variable set and starts to run at the end of the fork/join_none. Once all of the forks are done, the test completes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
class test extends uvm_test; `uvm_component_utils(test)
my_sequence seq; ... task run_phase(uvm_phase phase); phase.raise_objection(this); for (int i = 0; i < 4; i++) begin fork automaticint j = i; //automatic自动变量，每隔进程中都不同 seq = new($sformatf("seq%0d", j)); seq.LIMIT = 25 * (j+1); seq.start(sqr); join_none end waitfork; phase.drop_objection(this); endtask endclass
RUNNING A SEQUENCE — CREATING AND SENDING A SEQUENCE ITEM
Within the for-loop, a transaction object is constructed by calling new () or using the factory. Then start_item is called to begin the interaction with the sequencer. At this point the sequencer halts the execution of the sequence until the driver is ready. Once the driver is ready, the sequencer causes ‘start_item’ to return. Once start_item has returned, then this sequence has been granted permission to use the driver. Start_item should really be called “REQUEST_TO_SEND”. Now that the sequence has permission to use the driver, it randomizes the transaction, or sets the data values as needed. This is the so-called “LATE RANDOMIZATION” that is a desirable feature. The transactions should be randomized as close to executing as possible, that way they capture the most recent state information in any constraints.
class my_sequence extends uvm_sequence#(transaction); `uvm_object_utils(my_sequence)
transaction t; int LIMIT; ... task body(); for (int i = 0; i < LIMIT; i++) begin t = new(“t”); start_item(t);/// t.data = i+1; if (!t.randomize()) `uvm_fatal(get_type_name(), "Randomize FAILED") finish_item(t);// end endtask endclass
EXECUTING A SEQUENCE ITEM — THE DRIVER
The driver code is relatively simple. It derives from a uvm_driver and contains a run_phase. The run_phase is a thread started automatically by the UVM core. The run_phase is implemented as a forever begin-end loop. In the begin-end block the driver calls seq_item_port.get_next_item (t). This is a task which will cause execution in the sequencer – essentially asking the sequencer for the next transaction that should be executed. It may be that no transaction is available, in which case this call will block. (There are other non-blocking calls that can be used, but are beyond the scope of this article, and not a recommended usage). When the sequencer has a transaction to execute, then the get_next_item call will unblock and return the transaction handle in the task argument list (variable ‘t’ in the example below). Now the driver can execute the transaction.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
class driver extends uvm_driver#(transaction); `uvm_component_utils(driver)
Sequences can have handles to other sequences; after all, a sequence is just a class object with data members, and a “task body()”, which will run as a thread.
Virtual Sequences
The so-called “virtual sequence” – a sequence which may not generate sequence items, but rather starts sequences on other sequencers. This is a convenient way to create parallel operations from one control point.
A virtual sequence simply has handles to other sequences and sequencers. It starts them or otherwise manages them. The virtual sequence may have acquired the sequencer handles by being assigned from above, or by using a configuration database lookup, or other means. It may have constructed the sequence objects, or have acquired them by similar other means. The virtual sequence is like a puppet master, controlling other sequences.
A self-checking sequence is a sequence which causes some activity and then checks the results for proper behavior. The simplest self-checking sequence issues a WRITE at an address, then a READ from the same address. Now the data read is compared to the data written. In some ways the sequence becomes the GOLDEN model.
class write_read_sequence extends my_sequence; `uvm_object_utils(write_read_sequence) ...
task body(); for (int i = 0; i < LIMIT; i++) begin t = new($sformatf("t%0d", i)); start_item(t); if (!t.randomize()) `uvm_fatal(get_type_name(), "Randomize FAILED") // 可以用get_type_name()这里就返回write_read_sequence类名 t.rw = WRITE; finish_item(t); end
for (int i = 0; i < LIMIT; i++) begin t = new($sformatf("t%0d", i)); start_item(t); if (!t.randomize()) `uvm_fatal(get_type_name(), "Randomize FAILED") t.rw = READ; t.data = 0; finish_item(t);
// Check if (t.addr != t.data) begin `uvm_info(get_type_name(), $sformatf("Mismatch. Wrote %0d, Read %0d", t.addr, t.data), UVM_MEDIUM) `uvm_fatal(get_type_name(), "Compare FAILED") end end endtask endclass
WRITING A TRAFFIC GENERATOR SEQUENCE
A video traffic generator can be written to generate a stream of background traffic that mimics or models the amount of data a video display might require. There is a minimum bandwidth that is required for video. That calculation will change with the load on the interface or bus, but a simplistic calculation is good enough for this example. The video traffic will generate a “screen” of data 60 times a second. Each screen will have 1920 by 1024 dots. Each dot is represented by a 32 bit word. Using these numbers, the traffic generator must create 471MB per second.
class video extends my_sequence; `uvm_object_utils(video)
int xpixels = 1920; int ypixels = 1024; int screendots; int rate; bit [31:0] addr;
int x; int y;
video_transaction t;
task body(); screendots = xpixels * ypixels; rate = 1_000_000_000 / (60 * screendots); //周期是1ns，1s内10^9个周期，每隔rate周期发送一个数据。 foreverbegin addr = 0; for (x = 0; x < xpixels; x++) begin for (y = 0; y < ypixels; y++) begin t = new($sformatf("t%0d_%0d", x, y)); start_item(t); if (!t.randomize()) `uvm_fatal(get_type_name(), "Randomize FAILED") t.rw = WRITE; t.addr = addr++; t.duration = rate; finish_item(t); end end end endtask endclass
有用-WRITING SEQUENCES THAT ARE SYNCHRONIZED WITH EACH OTHER
Sequences will be used to synchronize other sequences (so called virtual sequences). Often two sequences need to have a relationship between them formalized. For example they cannot enter their critical regions together – they must go single-file. Or they can only run after some common critical region has passed.
The code below declares two sequences which are to be synchronized (synchro_A_h and synchro_B_h). It also declares a synchronizer. There is nothing special about these classes – they have simply agreed to use some technique to be synchronized.
class vsequence extends uvm_sequence; synchro synchro_A_h; synchro synchro_B_h; synchronizer s;
task body(); s = new(); //declares two sequences which are to be synchronized synchro_A_h = new("synchroA"); synchro_B_h = new("synchroB");
//The synchronized sequences get a handle to //the synchronizer and a starting address. synchro_A_h.s = s; synchro_A_h.start_addr = 2; synchro_B_h.s = s; synchro_B_h.start_addr = 2002; //The synchronizer control is rather simple. //It just says “GO” for 20 ticks and “STOP” for 100 ticks. fork//通过控制s.state来控制两个seq的运行 foreverbegin #100; s.state = GO;//运行seq #20; s.state = STOP;//停止运行 end join_none //The synchronized sequences are started. //They run to completion and then simply get restarted. //They run forever. fork//不停地尝试启动，当s.state为GO的使用产生tr foreverbegin synchro_A_h.start(sqr); end foreverbegin synchro_B_h.start(sqr); end join_none endtask endclass
The simple synchronizer with two states — GO and STOP.
1 2 3 4 5
typedefenumbit { STOP, GO } synchro_t;
class synchronizer; synchro_t state; endclass
The class that uses a synchronizer to NOT execute until told to do so.
class synchro extends my_sequence;// 子sequence `uvm_object_utils(synchro)
bit [31:0] start_addr; bit [31:0] addr; synchronizer s;
synchro_transaction t;
task body(); //子sequence中的body任务 foreverbegin addr = start_addr; // Is it safe? while (s.state == STOP) begin//如果STOP则一直在这里阻塞 #10; `uvm_info(get_type_name(), "Waiting...", UVM_MEDIUM) end //state为GO，跳过阻塞，发送seq t = new($sformatf("t%0d", addr)); start_item(t); if (!t.randomize()) `uvm_fatal(get_type_name(), "Randomize FAILED") t.rw = WRITE; t.addr = addr++; finish_item(t); end endtask endclass
In simulation, the sequence waits until the synchronizer is in the GO state. Once in the GO state, then the synchronized code generates a transaction using new, and then calls start_item/finish_item to execute it. After waiting for access to the driver and then executing, the synchronized sequence comes back to the top of the loop and checks the synchronizer state. It will either GO again, or STOP/WAIT
有用-IMPLEMENTING AN INTERRUPT SERVICE ROUTINE WITH SEQUENCES
Sequences will be used to provide an “interrupt service routine”. Interrupt service routines “sleep” until needed. This is a unique kind of sequence. In this example implementation it creates an “interrupt service transaction” and does start_item and finish_item. In this way, it can send that ISR transaction handle to the driver. The driver is then going to hold that handle UNTIL there is an interrupt.
As part of the drivers’ job of handling the SystemVerilog Interface, it will handle the interrupts. In this case, handling the interrupt means that some data is put into the “held handle” and then the handle is marked done. Meanwhile, the interrupt service sequence has been waiting for the transaction to be marked DONE. In some parlance（说法） this is known as ITEM REALLY DONE. In the UVM, there are other mechanisms for handling this kind of thing, but they are unreliable and more complicated than this solution.
if ($cast(isr, t)) begin//如果是isr transaction，则进入ISR，ISR是否执行还要看后面的 //transaction是否触发中断。 fork interrupt_service_routine(isr);//SIR join_none end elsebegin//如果是普通 transaction ... // REGULAR driver processing ... if (AN INTERRUPT OCCURS) begin//如果发生了中断，那么进行一些操作 done = 1; // 并将done置一，上面的ISR就会执行完。 value = mem[t.addr]; end //如果没有发生中断，那么ISR不会执行 end seq_item_port.item_done(); end endtask endclass
有用-SEQUENCES WITH “UTILITY LIBRARIES”
Sequence “utility libraries” will be created and used. Utility libraries are simple bits of code that are useful for the sequence writer – helper functions or other abstractions of the verification process.
The open_door sequence below does just as its name implies. It opens the door to the sequencer and driver. Outside calls can now be made at will using the sequence object handle (seq.read () and seq.write () for example).
The open_door is constructed and then started using normal means. Then a test program can issue reads and writes simply as in the RED lines below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
open_door open_door_h;
open_door_h = new("open_door"); fork open_door_h.start(sqr); begin bit [31:0] rdata; for (int i = 0; i < 100; i++) begin open_door_h.write(i, i+1); open_door_h.read(i, rdata); if ( rdata != i+1 ) begin `uvm_info(get_type_name(), $sformatf("Error: Wrote '%0d', Read '%0d'", i+1, rdata), UVM_MEDIUM) //`uvm_fatal(get_type_name(), "MISMATCH"); end end end join_none
task run_phase(uvm_phase phase); sequence1 seq1; seq1=new("seq1"); fork begin seq1.starting_phase = phase; seq1.start(env0.sqr); end begin for(int i=0;i<10;i++) begin seq1.write();//手动调用任务发送transaction seq1.read(); end end join_none endtask endclass