tudor.timi

Members
  • Content count

    246
  • Joined

  • Last visited

About tudor.timi

  • Rank
    Member

Contact Methods

  • Website URL
    http://blog.verificationgentleman.com

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

354 profile views
  1. The philosophy behind nested classes is that they have access to private members of the parent class. If you want to do scoping, you're better off using packages (though it's not possible to define a nice hierarchical structure of packages).
  2. Are you trying to compile it on Windows? I don't think QuestaSim supports DPI under Windows (or at least not easily). At the same time, you don't really need to compile UVM itself when running QuestaSim, because the simulator comes packaged with the library and can reference that. * You can change the Makefile to not compile UVM anymore, only the testbench code for the example. * You can also disable DPI by adding the UVM_NO_DPI define (here you might also need to remove the lines from the Makefile that try to compile the C code). * Finally, what's missing there is the path to 'vpi_user.h'. You can add a '-I /path/to/vpi/user/h/inside/questa/installation/' to the GCC call, to tell it explicitly where it can find the file.
  3. The second argument for new(...) is the number of memory locations. You should call: new(..., 2048, 64, ...);
  4. It's not clear in this case what 'valid' means. I don't understand why in your case, when the model would generate '0100', the DUT will respond with '0101' after a '0101'.
  5. The "env.spi_m[0].reg2spi_adapter.*" won't work in there, because the adapter doesn't know under which env it was instantiated. You can check this by calling get_full_name() from the adapter. That's what you need to pass as a context.
  6. When using RAL like this, items aren't created by your agents, but by the adapters interfacing with those agents. If you set up the contexts properly when creating items inside your adapters, it's going to be possible to do instance-based overrides: class spi_adapter extends uvm_reg_adapter; function uvm_sequence_item reg2bus(...); // notice the 'get_full_name()' here spi_item bus_item = spi_item::type_id::create("bus_item", null, get_full_name()); // ... endfunction endclass The extra argument to create(...) sets the context for items create under the adapter as being "<adapter_name>.*". In your environment code, you can set instance overrides like this: class some_tb_env; spi_adapter adapter0; spi_adapter adapter1; function void end_of_elaboration_phase(...); spi_mem_tr::type_id::set_inst_override(spi_mem_tr_0::get_type(), null, "adapter0.*"); spi_mem_tr::type_id::set_inst_override(spi_mem_tr_1::get_type(), null, "adapter1.*"); endfunction endclass Your adapters need to have different names otherwise you won't be able to differentiate between items create by one and ones created by the other. Note: Don't confuse the context passed into create(...) with instance paths of uvm_components. The two are closely related, but aren't the same thing.
  7. Your links are broken (there are some extra characters after the '4Tyw' part in the URL). The code is OK and Riviera-Pro does support it.
  8. It's not sufficient that all the blocks work properly, because it might be the case that they aren't properly connected to each other. Outputs from some block are left hanging and the corresponding inputs are tied to some values. Cascaded block level checks can't really find this, if your observation points for each block level environment are its corresponding design block. Example: A can start read or write transactions, but the direction signal doesn't get passed to B, where it's tied to read. The A or B env checks won't fail, but the whole system is buggy.
  9. Correction to picture 1: it does verify block level functionality, but you get poor visibility in case something doesn't work, it's available late, etc. (all the disadvantages of not splitting up design/verification into blocks). For the whole system to be working properly it's necessary (but not sufficient) for the blocks to work properly. If you have a system that is a simple cascade like this, the only thing you'd want to check is that everything is stitched together properly (e.g. outputs from A get routed properly to B's inputs and so on). You could do this via a formal app for connectivity. You could also make sure do it in simulation by having your agents tap on the other side of the connection. What I mean by this is that, for example, your B interface agent for the A env gets connected to the B block's signals and not to the ones in the A block. This way you implicitly check that stuff coming out of A reaches B. If you want to have an end-to-end check like this, you'd need to build the chain yourself. This shouldn't be a big problem, since your "models" (or predictors or whatever you call them) should have some kind of predict(...) function that only returns the expected output transaction given some input transaction. This means you only need to do: class e2e_scoreboard; // ... virtual function void write_input(input_trans_type input_trans); expected_trans_fifo.try_put(c_model.predict(b_model.predict(a_model.predict(input_trans)))); endfunction // push output transaction to actual FIFO // pop from both FIFOs and compare endclass
  10. There's a 'recording_detail' configuration property that all UVM components have. I'd use this to enable/disable recording, since you can configure it via the command line.
  11. I'm being overly pedantic here, but p_INT: sc_in<bool> doesn't really seem all that TLM to me. TLM would be stuff like sockets and ports. You seem to have two RTL-ish views, one in VHDL and one in SystemC.
  12. The </ipxact:generatorChain> closing tag is missing at the end of the file.
  13. There is acomment in the sample design: <!-- Export Master interface -- will be used for TLM to RTL conversion --> According to the XML specification, it's illegal to have '--' inside comments (except when followed immediately by '>'), which causes parsing to fail.
  14. There is a TODO comment in the example component: <!-- TODO: MISSING definition of resetType in document --> I'm not sure what this refers to, since there is a definition for 'resetType' in the standard and there is also an example resetType defined.
  15. The verilog file set of the component example lists the same file (component.v) twice: <ipxact:name>VerilogFiles</ipxact:name> <!-- LINK: file: see 6.15.2, file --> <ipxact:file> <ipxact:name>../src/component.v</ipxact:name> <ipxact:fileType>verilogSource</ipxact:fileType> <ipxact:isStructural>true</ipxact:isStructural> </ipxact:file> <ipxact:file> <ipxact:name>../src/component.v</ipxact:name> <ipxact:fileType>verilogSource</ipxact:fileType> </ipxact:file> </ipxact:fileSet>