johannes.walter
Members-
Posts
13 -
Joined
-
Last visited
johannes.walter's Achievements
Member (1/2)
0
Reputation
-
hey! i have got a problem with a fifo register in UVM. there are two interfaces. one can write to the fifo register and the other can read from it. at first i tried to solve this by using a virtual sequencer and choose the right sequencer for every sequence. but UVM just ignores this and uses the sequencer associated with the register model's address map. so i tried to implement two address maps - one for each interface - and add all the registers to both maps. but on adding the fifo registers to both maps i get the following errors: # UVM_ERROR /home/walterjo/uvm-1.1/src/reg/uvm_reg_field.svh(938) @ 0: reporter [RegModel] Shared register 'reg_model.global_processing_call_reg' containing field 'value' is not shared in map 'reg_model.spi_map' # UVM_ERROR /home/walterjo/uvm-1.1/src/reg/uvm_reg_field.svh(938) @ 0: reporter [RegModel] Shared register 'reg_model.global_processing_status_reg' containing field 'value' is not shared in map 'reg_model.spi_map' # UVM_ERROR /home/walterjo/uvm-1.1/src/reg/uvm_reg_field.svh(938) @ 0: reporter [RegModel] Shared register 'reg_model.global_processing_call_reg' containing field 'value' is not shared in map 'reg_model.porc_map' # UVM_ERROR /home/walterjo/uvm-1.1/src/reg/uvm_reg_field.svh(938) @ 0: reporter [RegModel] Shared register 'reg_model.global_processing_status_reg' containing field 'value' is not shared in map 'reg_model.porc_map' # UVM_FATAL @ 0: reporter [BUILDERR] stopping due to build errors has anyone an idea how to deal with multiple interfaces on fifo registers correctly? any help would be highly appreciated! regards, johannes
-
Hi! I tried all the suggested solutions. Implementing a custom backdoor worked best for me. This way its possible to use UVM combined with VHDL without problems and without modifying any uvm_dpi C functions. Here is my code for QuestaSim: class my_reg_backdoor extends uvm_reg_backdoor; virtual function void read_func(uvm_reg_item rw); rw.value[0] = $root.top.dut.my_reg; rw.status = UVM_IS_OK; endfunction virtual task write(uvm_reg_item rw); string data; data.bintoa(rw.value[0]); $sformat(data, "%012d", data); // bit width = 12 $signal_force("/top/dut/my_reg", data, 0, 1); endtask endclass Thank you all! Uwe, you just made my day! Regards, Johannes
-
Hi, thank you for your reply. I didn't know that this is not working with VHDL. What I did now for the time being is to mirror the VHDL signals to a SystemVerilog module using QuestaSim's Signal Spy. When I change the HDL path to this module DPI/VPI is working fine. We are also thinking about adding some Mentor FLI functionality to uvm_hdl.c - although this will only work with QuestaSim. Regards, Johannes
-
Hey! The last couple of days I am trying to get the UVM backdoor for my register model working. I have my DUT's register file written in VHDL utilizing many std_ulogic_vectors as registers. Now I would like to set a HDL path to access these std_ulogic_vectors via the DPI/VPI mechanisms of UVM. For example one of the std_ulogic_vector registers has the path "top.dut.sfr_adc_conf_reg_s". I experienced many different behaviours while trying to get this working. 1. With registers that have only 1 bit and are mapped to a std_ulogic everything is working. "sfr_adc_conf_reg_s" is std_ulogic: adc_conf_reg.add_hdl_path('{ '{"sfr_adc_conf_reg_s", -1, -1} }); 2. With bigger registers which are mapped to std_ulogic_vectors it is not working. "sfr_adc_conf_reg_s" is std_ulogic_vector(15 downto 0): adc_conf_reg.add_hdl_path('{ '{"sfr_adc_conf_reg_s", -1, -1} }); Result is a segmentation vault in QuestaSim: # ** Fatal: (SIGSEGV) Bad handle or reference. # Time: 1531 ns Iteration: 0 Process: /uvm_pkg::uvm_sequence_base::start/#FORK#299_2a96e47e7 File: /home/walterjo/uvm-1.1/src/dpi/uvm_hdl.svh # Fatal error in Module uvm_pkg at /home/walterjo/uvm-1.1/src/dpi/uvm_hdl.svh line 121 3. When I add a range to the HDL path the C function in uvm_hdl.c tries to access each bit independently. The segmentation fault disappears but then QuestaSim cannot find the according VHDL signal. "sfr_adc_conf_reg_s" is std_ulogic_vector(15 downto 0): adc_conf_reg.add_hdl_path('{ '{"sfr_adc_conf_reg_s[15:0]", -1, -1} }); Result in QuestaSim: # UVM_ERROR: get: unable to locate hdl path top.dut.sfr_adc_conf_reg_s[0] # Either the name is incorrect, or you may not have PLI/ACC visibility to that name In my uvm_env I set the HDL root path to "top.dut" and I also added +acc=rnb to the vcom and vlog parameters. Has anyone an idea how to set the HDL path correctly to get access to the VHDL vector registers? Any help would be appreciated! Regards, Johannes
-
Segmentation fault using DPI
johannes.walter replied to johannes.walter's topic in UVM SystemVerilog Discussions
This problem disappeared during development ... but now there is another one with accessing std_ulogic_vectors using the DPI/VPI. I will open another thread for this: http://www.uvmworld.org/forums/showthread.php?327-Valid-HDL-path-using-DPI-VPI-to-access-std_ulogic_vectors Regards -
Segmentation fault using DPI
johannes.walter replied to johannes.walter's topic in UVM SystemVerilog Discussions
Hey! The segmentation fault has gone away. I had to add the range of the std_ulogic_vector to the HDL path. adc_conf_reg.add_hdl_path('{ '{"sfr_adc_conf_reg_s[6:0]", -1, -1} }); ... did the trick.But now I have got another error. The uvm_hdl.c function tries to access each bit of the vector indiviually. But QuestaSim cannot find these paths. Here is the error: # UVM_ERROR: get: unable to locate hdl path top.dut.sfr_adc_conf_reg_s[0] # Either the name is incorrect, or you may not have PLI/ACC visibility to that name What am I doing wrong? I also compiled every source file with +acc=rnb. Regards, Johannes -
Segmentation fault using DPI
johannes.walter replied to johannes.walter's topic in UVM SystemVerilog Discussions
Okay. I did some more debugging. I forgot to mention that my DUT is written in VHDL. So I would like to access some VHDL std_ulogics and std_ulogic_vectors using the UVM backdoor. So here is what I found out: The function "uvm_hdl_get_vlog" in uvm_hdl.c works well when I am trying to access a std_ulogic register. But the segmentation fault occurs when I try to get access to the value auf a std_ulogic_vector register. Seems like the DPI/VPI extension cannot handle VHDL std_ulogic_vectors. Has anyone had such a problem before? Regards, Johannes -
Hey! I'm about to implement some register tests. So first of all I wanted to run all the UVM built-in test sequences. But when I run the uvm_reg_access_seq I get the following error in QuestaSim: ** Fatal: (SIGSEGV) Bad handle or reference. Time: 1531 ns Iteration: 0 Process: /uvm_pkg::uvm_sequence_base::start/#FORK#285_2a96f3307 File: /opt/questasim_10.0b/questasim/verilog_src/uvm-1.0p1/src/dpi/uvm_hdl.svh Fatal error in Module uvm_pkg at /opt/questasim_10.0b/questasim/verilog_src/uvm-1.0p1/src/dpi/uvm_hdl.svh line 121 I had a look at uvm_hdl.svh, line 121. It imports a C function from uvm_hdl.c which I cannot debug. Has anyone an idea how I could fix this? Regards, Johannes
-
Hey! I've got a compilation error in QuestaSim bugging me for days now. That's the error: Error: (vsim-3978) ../src/reg_sequence.sv(27): Illegal assignment to class type uvm_component [in mtiUvm/uvm_pkg::uvm_component] from class type reg_sequence [in work/top_sv_unit::reg_sequence] There is a register model which I'm trying to pass to a sequence by using the uvm_config_db. The register model is derived from uvm_reg_block and uses the uvm_object_utils macro. In my environment I create an instance of the register model and pass the handle to the uvm_config_db. reg_model rm; ... // create reg_model ... uvm_config_db#(reg_model)::set(this, "*.*reg_sequence*", "register_model", rm); In the sequence I've got a variable of type reg_model and I would like to use the handle from the uvm_config_db for this variable. reg_model model; ... uvm_config_db#(reg_model)::get(this, "", "register_model", model); Can anyone tell me why this is not working and the error occurs? Thanks in advance! Regards, Johannes
-
Sequence stops suddenly
johannes.walter replied to johannes.walter's topic in UVM (Pre-IEEE) Methodology and BCL Forum
Hi! Thank you for your reply. It's working now! Regarding the other small things. I'm currently reading a lot about UVM and try to figure out how to use it correctly. Although some hints would be nice. Regards, Johannes -
I'm new to UVM. So I wanted to implement a small basic example to get used to the techniques. Basically I followed the instructions in the UVM 1.0 User Guide. So here is what i've got: - An agent including driver, monitor and sequencer - My driver inherited from uvm_driver - My monitor inherited from uvm_monitor - A sequencer: uvm_sequencer itself - An item inherited from uvm_sequence_item - A custom sequence inherited from uvm_sequence The driver requests the new item using the get_next_item() function (port and export to sequencer are connected by agent). Everything so far is working fine. But only one time. After he got the first item and trys to get the next one the whole simulation stops. No warnings, no errors. I'm searching for the problem for days now and I would be pleased if someone could help me. I attached the whole source code to this post. Regards, Johannes