Hi,
How do I verify an ALU in UVM?. In my SV test benches, I used to have mailbox drv2sb and mon2sb to check my transactions and expected output pass & fail. And when it comes to UVM
1)Should I use predictor and comparator to verify? If yes, should I have an analysis port for the driver in which I predict the output and send them to my scoreboard and then compare it with that of received monitor outputs in the scoreboard? Will this be a good solution? .Should I be implementing this by using uvm_tlm_analysis_fifo?
2)Any other solution to verify it?
In reply to sai_pra99:
it is good to have a predictor and comparator for scoreboarding since it would simplify the logic and also increases the debugging of the testbench.
And to send a transaction from monitor to the scoreboard or to any other part of testbench use analysis_port, the reason is that analysis_port can be connected with one or more analysis_export or no connection at all.
Always send a transaction to any part of the testbench(i.e. scoreboard) from monitor. don’t use a driver for this purpose, because sometimes you need to configure testbench agent to acts as a passive device(means it would not has driver component, the only thing it has is monitor component). So try to send a transaction from the monitor only, not driver.
In reply to sai_pra99:
Hi,
How do I verify an ALU in UVM?. In my SV test benches, I used to have mailbox drv2sb and mon2sb to check my transactions and expected output pass & fail. And when it comes to UVM
1)Should I use predictor and comparator to verify? If yes, should I have an analysis port for the driver in which I predict the output and send them to my scoreboard and then compare it with that of received monitor outputs in the scoreboard? Will this be a good solution? .Should I be implementing this by using uvm_tlm_analysis_fifo?
2)Any other solution to verify it?
Generate automatically a UVM environment using a UVM Framework Generator like the one from Doulos (https://www.doulos.com/knowhow/sysverilog/uvm/).
Then add ascorboard and a functional coverage collector.
In reply to voraravi:
Ok in order to simplify can I do this
class monitor extends uvm_monitor;
`uvm_component_utils(....)
function new(.......);
endfunction
function void build_phase(uvm_phase phase)
Packet pkt=Packet::type_id......;
mon_analy_port=new("mon_analy_port",this);
endfunction
task run_phase(uvm_phase phase)
..
..
..
mon_analy_port.write(pkt)
endclass
class scoreboard extends uvm_scoreboard;
`uvm_componen....
function new(string name,uvm_component parent);
super.new(name,parent);
endfunction
function void write(Packet pkt);
if(pkt.sel==3'b000)
begin
if(pkt.op_a+pkt.op_b!=pkt.y_out)
`uvm_error(.......,ADD Error) ///As per in my DUT
else
`uvm_info(.....SUCCESS ADD......)
end
else if(pkt.sel==3'b001)
begin
if(pkt.op_a-pkt.op_b!=pkt.y_out)
`uvm_error(.......,SUB Error) ///As per in my DUT
else
`uvm_info(.....SUCCESS SUB......)
end
else if(pkt.sel==3'b010)
begin
..
..
.. // All my operations
endfunction
endclass
?
If I am not wrong the above snippet should provide me with design correctness but this not an industry-standard for a VIP?
As there might be a change in driven inputs and the inputs seen in the monitor after being driven right(Not sure of this). And that’s why I thought of inferring inputs from the driver and predict my output
Something like this…
The thing I am confused about is from where can I get my driven transaction to predict my output and put them in drv_port.write(pkt) and send them through FIFO to scoreboard.
class scoreboard extends uvm_scoreboard;
`uvm_componen....
function new(string name,uvm_component parent);
super.new(name,parent);
endfunction
uvm_analysis_tlm_fifo#(Packet) drv_export;
uvm_analysis_tlm_fifo#(Packet) mon_export;
task run_phase();
super.run_phase(phase)
Packet pkt1,pkt2;
drv_export.get(pkt1)
mon_export.get(pkt2)
compare();
endtask
task compare(Packet pkt1,Packet pkt2);
if(pkt1.y_out==pkt2.y_out)
`uvm_info (..."ADD SUCESS",UVM_LOW)
..
..
endtask
endclass
The UVM Framework comes with a generator tutorial that takes you through the steps to verify an ALU module from start to finish. This includes using a scoreboard and a predictor.
You can download the UVM Framework from Verification Academy.
Look inside the docs/generator_tutorial folder.
There is a PDF that walks you through the steps
In reply to sai_pra99:
In reply to voraravi:
If I am not wrong the above snippet should provide me with design correctness but this not an industry-standard for a VIP?
As there might be a change in driven inputs and the inputs seen in the monitor after being driven right(Not sure of this). And that’s why I thought of inferring inputs from the driver and predict my output
Something like this…
The thing I am confused about is from where can I get my driven transaction to predict my output and put them in drv_port.write(pkt) and send them through FIFO to scoreboard.
I believe predictor is a bad word, because we are using this wrt RAL.
What you mean is a reference model which converts your input transactions into the result transactions. The best place is to instantiate this in your scoreboard.
In reply to sai_pra99:
Hi this should be your template while implementing monitor scoreboard communication through analysis port
//monitor class
uvm_analysis_port #(Packet) mon_analy_port;
.
.
task run_phase();
Packet pkt=new();
if(...)
pkt.cmd = vif.cmd;
.
.
mon_analy_port.write(pkt);
endtask
//scoreboard class
uvm_analysis_imp #(Packet, scoreboard) sb_ap;
uvm_tlm_anlysis_fifo #(Packet) expected_op;
uvm_tlm_anlysis_fifo #(Packet) actual_op;
function void write(Packet req);
if(..)
void'(expected_op.try_put(req));
if(..)
void'(actual_op.try_put(req));
endfunction
task run_phase();
Packet exp,act;
expected_op.get(exp);
actual_op.get(act);
.
. //Compare logic here
.
endtask
Hope this answer your question