Search the Community
Showing results for tags 'register'.
Found 6 results
-
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_
-
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 -
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 -
Backdoor read\write to a register
Rina301 posted a topic in UVM (Pre-IEEE) Methodology and BCL Forum
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 -
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
