Search the Community

Hi, Recently I used the following Verilog code in my project: module dff8( input wire CLK, input wire RST, input wire [7:0] D0, output reg [7:0] Q0 ); always @( posedge CLK or negedge RST ) begin if ( RST == 1'b0 ) begin Q0 <= 8'b0; end else begin Q0 <= #10 D0; end end endmodule Is there any way how to model #<DELAY> in SystemC. The example of systemc register that I use is below. SC_MODULE(dff8) { // port declarations sc_in<bool> CLK; sc_in<bool> RST; sc_in<sc_uint<8> > D0; sc_out<sc_uint<8> > Q0; // process declaration void do_dff8() { if (RST.read() == 0) { Q0.write(0); } else { // HOW TO ADD DELAY HERE? Q0.write(D0.read()); } } SC_HAS_PROCESS(dff8); dff8(sc_module_name inst) : sc_module(inst) { SC_METHOD(do_dff8); sensitive << CLK.pos(); sensitive << RST.neg(); } }; Thanks for any help.

In uvm_reg_map::do_bus_read() task, after the call to adapter.bus2reg() function, do_bus_read() function checks for any Xs in data field. Code from uvm_reg_map: uvm_reg_bus_op rw_access; uvm_reg_data_logic_t data; data = rw_access.data & ((1<<bus_width*8)-1); rw.status = rw_access.status; if (rw.status == UVM_IS_OK && (^data) === 1'bx) rw.status = UVM_HAS_X; Here, rw_access.data is of type "bit" and is assigned to data which is of type "logic". and then data is checked for Xs. But, as rw_access.data is "bit" type, it will never contain Xs or Zs. As a result, data will never have Xs, so rw.status will not set to UVM_HAS_X. So even if bus2reg function samples Xs from the bus, those Xs never make upto tasks in uvm_reg_map class. Some supporting code:: uvm_reg_defines.svh: `define UVM_REG_DATA_TYPE bit uvm_reg_model.svh : typedef `UVM_REG_DATA_TYPE unsigned [`UVM_REG_DATA_WIDTH-1:0] uvm_reg_data_t ; uvm_reg_item.svh: typedef struct { uvm_access_e kind; uvm_reg_addr_t addr; uvm_reg_data_t data; int n_bits; uvm_reg_byte_en_t byte_en; uvm_status_e status; } uvm_reg_bus_op; In my testbench, I want uvm_reg_map to set the status to UVM_HAS_X whenever data received for a register read transaction from DUT is X. How do I achieve that?

Why does uvm_reg_map::get_n_bytes() return 0 if you call it on a system level map? That is completely useless and tells me nothing about the system. If on the other hand, I call uvm_reg_map::get_n_bytes() from a lower level map in my register model, then I get the narrowest bus width in the map hierarchy. That makes sense. It seems I should get that same value when calling get_n_bytes() on the system level map. Returning 0 is not useful under any circumstance.

I've run into the following issue using the built-in UVM register tests. The built-in UVM register tests (seem to) start R/W-ing immediately after top-level reset is released. This was fine, initially. See attached image "Capture". We now have some delay between the release of top-level reset and the actual reset going to the register block. This is resulting in a read occurring before reset to the rtl regblock is released, and causes the test to hang. See attached image "Capture2". Without modifying the built-in register tests/sequences, how would anyone suggest that we cleanly delay the stimulus? Perhaps I just need to make the stimulus aware of the different reset when the model/stimulus is generated, or simple add some delay to a phase before the R/W-ing starts. (The former sounds right. If that's the solution, I'll need to figure out how we're generating the model/stimulus.) I've just started hunting around for the built-in UVM register test sequences and will return to it tomorrow, but will anyone tip me off as to what names I should be searching for? thanks This has been useful, https://verificationacademy.com/cookbook/registers/builtinsequences, but it seems I need to do some more reading and hunting before I grasp how the built-in register stimulus is created and used.

Hi, Please help with an issue about backdoor read\write to a register. Is it going to be fixed? When doing backdoor write\read to a register – the code (uvm_reg) uses the default map instead of the map the user gave in the write\read register operation: A. do_write gets rw with the correct map that the user wanted – rw.map. B. When doing backdoor write (1 below) , XpredictX (3 below) is called with rw.local_map (=null). get_access with null map is actually default map. C. Even If XpredictX was called with rw.map – it should make many warnings no matter what is the default map\which map we gave the write. This is because in the do_write, Xcheck_accessX (2 below) is changing rw.map to “Backdoor” – empty map which doesn’t contain any regs. ------------------------------------------------------------------------------------------------------------------------- 1. task uvm_reg::do_write (uvm_reg_item rw); -> with the user specified map - rw.map … if (!Xcheck_accessX(rw,map_info,"write()")) (see Xcheck_accessX below ) return; … // EXECUTE WRITE... case (rw.path) // ...VIA USER BACKDOOR UVM_BACKDOOR: begin .. begin foreach (m_fields) begin uvm_reg_data_t field_val; int lsb = m_fields.get_lsb_pos(); int sz = m_fields.get_n_bits(); field_val = m_fields.XpredictX((rw.value[0] >> lsb) & ((1<<sz)-1), (value >> lsb) & ((1<<sz)-1), rw.local_map); -> local map is null – see XpredictX below …. endtask: do_write ------------------------------------------------------------------------------------------------------------------------------------ 2. function bit uvm_reg::Xcheck_accessX (input uvm_reg_item rw, ->with the user specified map output uvm_reg_map_info map_info, input string caller); … if (rw.path == UVM_BACKDOOR) begin if (get_backdoor() == null && !has_hdl_path()) begin `uvm_warning("RegModel", {"No backdoor access available for register '",get_full_name(), "' . Using frontdoor instead."}) rw.path = UVM_FRONTDOOR; end else rw.map = uvm_reg_map::backdoor(); -> rw map is changed to “Backdoor”, local map is not calculated (for FRONTDOOR it is – below) end if (rw.path != UVM_BACKDOOR) begin rw.local_map = get_local_map(rw.map,caller); … return 1; endfunction ------------------------------------------------------------------------------------------------------------- 3. function uvm_reg_data_t uvm_reg_field::XpredictX (uvm_reg_data_t cur_val, uvm_reg_data_t wr_val, uvm_reg_map map); -> map is null uvm_reg_data_t mask = ('b1 << m_size)-1; case (get_access(map)) -> get access is performed with null map = get access is performed without giving a map and it is using the default map instead of the map that the user specified in the write operation "RO": return cur_val; "RW": return wr_val; … -------------------------------------------------------------------------------------------------------------

The issue I have is the register model has multiple registers of different names but the fields within the registers are named the same. The register model is generated by a tool so getting changes made will take some time and I need a work around. I have a lot of registers so this is a big problem. class reg_0 extends uvm_reg; rand uvm_reg_field x; rand uvm_reg_field y; ...... endclass class reg_1 extends uvm_reg; rand uvm_reg_field x; rand uvm_reg_field y; ...... endclass I need to be able to access the fields in my scoreboard. The problem is the field is not associated to the register so I can't simply call peek on x without associating it with the correct register. Is there a way to associate the register name with the field name and then call peek without hard coding the call to peek? I am using get_registers() and get_fields() to load my queues. Is there a way to get the registers and the fields for that register instead of one or the other? Perhaps I have missed something in the reference manual. reg_fields.peek(status,reg_field_data);