Jump to content

tudor.timi

Members
  • Content Count

    289
  • Joined

  • Last visited

  • Days Won

    33

Everything posted by tudor.timi

  1. As per section E.6.3.6 Numbers, only formats legal in SystemVerilog are allowed for constants. The sample XML in annex I.5 contains the numbers "0x40000000" and "0x1000" which aren't legal SystemVerilog constants.
  2. The designConfigurations tag isn't properly closed. It should be: <ipxact:designConfigurations> <ipxact:ipxactFile> <ipxact:vlnv vendor="accellera.org" library="Sample" name="SampleDesignConfiguration" version="1.0"/> <ipxact:name>./SampleDesignConfiguration.xml</ipxact:name> </ipxact:ipxactFile> </ipxact:designConfigurations>
  3. The examples in Annex I use the namespace http://www.accellera.org/XMLSchema/IPXACT/2.0 instead of http://www.accellera.org/XMLSchema/IPXACT/1685-2014
  4. The value that you pass in is of type time, which is essentially just an integer scaled to the timescale of the code where you the function. You're going to have to pre-scale it yourself to the appropriate value. UVM itself doesn't have a timescale defined (which is unfortunate because it makes use of #(...) delays), but you can usually set a default timescale for packages from the compiler command line.
  5. Some tools ignore modports when using them in virtual interfaces. Also, some tools might not implement any checks for multiple drivers if one of those drivers is procedural code that's doing it's thing through a virtual interface. This is because this would be a run time check and it would be too expensive in terms of performance.
  6. If you have that many registers you need to customize the way you access, why don't you just create your own sub-class of uvm_reg_map that can handle this? You'll just need to override the do_read/write(...) tasks. The best part is that you'll only have one object handling this (the map to which you add the registers) as opposed to many (the frontdoors you would add to the registers).
  7. The "doesn't sound like a good idea in terms of memory usage" line seems like premature optimization. Did you try adding a different instance of the frontdoor to each register and see that memory is an issue?
  8. I tried the code on EDAPlayground and it worked as expected (c.a was 10 and then 50).
  9. Next up, what do you mean with write_valid and write_data are in arrays. Do you have more signal pairs that you need to check?
  10. I'd start off with comments on your current assertion. You shouldn't use write_valid inside the disable iff block of the assertion. That's because it won't do what you probably think it does (at least not in SV 2012). The disable iff is for asynchronous resets, but I'm guessing that write_valid is a synchronous signal. What I think you want is: write_valid |-> !$isunknown(write_data) If for some reason you don't like the fact that this property accepts vacuous successes (i.e. it's true when write_valid is 0), then you can use disable iff to disable it in those case, but you need to m
  11. I don't think it's just readability. When you cover stuff like this I'd assume you don't want to see vacuous hits (when A is false); you want to see that you had A and B high at the same time. In any case, they're not the same.
  12. Not sure where you got the idea from that you can do this for uvm_reg_single_access_seq. First of all, there isn't any field called maps defined in the sequence. The only place I see any reference to any maps is in body(), where it's a local variable. Second, you can't constrain object handles like that, since only integral expressions are allowed by the LRM. Coming back to your question, you can't use these sequences to do what you want them to do. This is because they're poorly written. Instead of having one big loop inside the body() task of uvm_reg_single_access_seq, a better way would
  13. What you can also do is define your own "indirect data register" class that is more tailored to your situation: class some_indirect_data_reg extends uvm_reg_indirect_data; ctrl_reg ctrl; data0_reg data0; data1_reg data1; // override configure function void configure (ctrl_reg ctrl, data0_reg data0, data1_reg data1, uvm_reg_block blk_parent, uvm_reg_file regfile_parent = null); // ... m_tbl = new[2]; m_tbl[0] = data0; m_tbl[1] = data1; endfunction virtual
  14. There's a section in the User Guide talking about indexed registers. Have a look at that.
  15. I've written about this topic here: http://blog.verificationgentleman.com/2015/11/accessing-multiple-registers-at-once.html The post covers both using an extension and an alternative way of doing it.
  16. You could still implement it as a callback, but just attach it to any of the registers' fields: class my_cb extends uvm_reg_cbs; `uvm_object_utils(my_cb) virtual task post_predict(input uvm_reg_field fld, ...); uvm_reg my_reg = fld.get_parent(); // everything else stays the same // ... endtask:post_predict endclass:my_cb ----------------------// IN REG BLOCK //--------------------- virtual function void build(); my_cb cb_reg = new(); // Now create all registers REG1 = REG_1::type_id::create("REG_1", , get_full_name()); REG_1.configure(this, null, ""); REG_1.build(); // Si
  17. I wouldn't use post_write(...) since that is only called when you call reg.write(...), i.e. when you are driving the registers. If you do any kind of vertical reuse, you might not be driving the registers from sequences, but other parts of the RTL will be doing this. Explicit prediction and post_predict(...) are the scalable way to go.
  18. I've already commited my thoughts on the topic to the Interwebs: http://blog.verificationgentleman.com/2015/03/why-i-favor-short-tests.html
  19. I don't think you can get any better than what you already plan to do. One note, you want to update the other registers using the mirrored value, i.e. the value returned by uvm_reg::get_mirrored_value().
  20. From the quote above I take it you registered your callback with the register and not the fields. The problem is that there isn't any post_predict(...) hook defined for uvm_reg, just for uvm_reg_field. They both use the same callback class though (which is misleading). If you look at the BCL code you'll see that uvm_reg::do_predict(...) only calls predict(...) on each of the register's fields. You have to add the callback to each of these in a loop (as I've done in the example above). Here it is again: uvm_reg_field flds[$]; some_reg.get_fields(flds); foreach (fl
  21. If you've worked with vr_ad or some other register package in the past, you have to keep in mind that UVM REG works differently. There aren't mirror registers and temporary registers you use for sequences. There are only the model registers. These registers have 2 values they keep track of: desired value and mirrored value. The desired value is what you want to drive into the RTL and the mirrored value is what you think is in the RTL. Calling 'set()' doesn't update the mirrored value (i.e. the model), just the desired value. The user guide has a section on this that you should read for more de
  22. Calling 'set(...)' only updates the desired value. Prediction means updating the mirrored value. If you look in 'do_write(...)', you'll see there's some code referencing 'system_map.get_auto_predict()' and calling 'do_predict(...)' based on that. This is the way it's supposed to work.
  23. I don't think it's supposed to work for enums. To get a config field you need to call uvm_config_db #(field_type):: (....), where field_type must be known at compile time. It's not possible for the field macros to generate code that expands to this, even though the field type is passed as an argument. Looking at the source code, the only types which are supported are: uvm_bitstream_t, int, int unsigned, string, uvm_config_object_wrapper and uvm_object.
  24. You can get a handle to the 'phase' argument that gets passed to 'main_phase(...)' using: uvm_hase main_phase = phase.find(uvm_main_phase::get(), 0); This works if you call it from 'end_of_elaboration_phase(...)' (or I guess any function-based phase), but for some reason it returns null when called in 'run_phase(...)'. I don't know why and I also don't want to dig around the source code to find out. You could store this 'main_phase' inside a class field and use in 'run_phase'. It's not clean, but it's pragmatic.
  25. You have to be reaaaaaally patient. I've sent an email to Mr. Alsop more than a year ago and still haven't gotten any response.
×
×
  • Create New...