joniale

From http://www.asic-world.com/systemverilog/literal_values4.html string a; a = "This is multi line comment \n and this is second line"; /* Outputs: a = This is multi line comment^M and this is second line */ //You will have ^M which is the dos character for new line. if you write to a file with this line. If you want to avoid that, then the next solution should be used string tmg ={" \n" , "//periodic signal intf.KEYCONTROL_CLK \n" , "fork\n"

A good tutorial to understand how to embedd Python in C https://www6.software.ibm.com/developerworks/education/l-pythonscript/l-pythonscript-ltr.pdf Then you can search how to use DPI with C to be able to use C in systemverilog. Sure, There is a lot of DPI examples in your vendor EDA simulator folder.

Hi again, I want to report another minor issue. the issue is applicable in case you want a layering sequence for registers in AXI. I mean what is described here: https://www.mentor.com/products/fv/resources/overview/a-new-class-of-registers-2e32ca83-d5ee-4e34-8880-c006be7e537f As you can see a layering sequence allows you to create randomized register accesses that are not possible with the adapter and the default uvm_reg_map. This is needed to test that registers are written/read correctly with different AXI accessed than the fix accesses done by the uvm library.

Hi experts, I have the following question about vertical reusability and null sequencers. I have a sequence that stimulates a sub block inside a TOP block. I have verified first the separated sub block. Therefore, i had a testbench for the sub block that has of course VC interfaces and registers. I would like to have a clear way of coding to allow vertical reusability of the sequence that test the sub block. In other words, i would like how to code the sub sequence so that i can start that sequence from a TOP module afterwards. I see the following problems 1)The TOP te

Here my two cents, In my opinion, it would be good that UVM would do the backdoor access not as it currently does. It would be good that once provided the hdl_path to a field, the UVM library somehow would be able to generate an unique interface for that hdl_path and a bind that correspond to that interface. That generated interface should be published to the config data base and would be available in any part of your design through the ConfigDB. Of course, the UVM backdoor functions would still be able to do the checks they do now, for example, check that the register is not being acces

Hi, Here my two cents. Cloning of register blocks is not intended in UVM. Therefore, there are several checkers that warns you about that. One way to do this is implementing a custom clone function inside the register block for each field. This is something that can be done with some perl scripting (if you have many registers and fields). See a small snip on how to do that (only with one register and field EXPECTED_SUM_2) class hmac_sha256_regblock extends uvm_reg_block; `uvm_object_utils(hmac_sha256_regblock) //This function has been included in the au

Hi , To whom may correspond I think there is some kind of error in the UVM 1.1d register model. I have been experimenting with the UVM register model and i have seen the following code in uvm_reg_map.svh task uvm_reg_map::do_bus_write (uvm_reg_item rw, uvm_sequencer_base sequencer, uvm_reg_adapter adapter); uvm_reg_addr_t addrs[$]; uvm_reg_map system_map = get_root_map(); int unsigned bus_width = get_n_bytes(); uvm_reg_byte_en_t byte_en = -1; uvm_reg_map_info map_info;