Jump to content


  • Content Count

  • Joined

  • Last visited

  1. My guessing is that you have not called set_auto_predict(1) on the register map and then you need to have an explicit monitor to update the field value.
  2. Well I was under the impression that the uvm_tlm_time class was created for taking care of exactly this problem and I there fore thought it would be a good idea to use it here. If it is not I think we should try to create a new type that does take care of this to make life easier for people writing test benches. The naming of the class uvm_tlm_time is not so good since it is not only when using TLM you have problems with the stupid way SystemVerilog represents time.
  3. Well the problem is that i do use an time literal to calculate the time out value and that is exactly what I want to do. In any case I need to know which time unit was used when UVM was pre compiled which is wrong. If the uvm_tlm_time type was used this would not be the case. We could still end up in problems with precision but that is less likely to be a problem for the use it is intended for where only large values of time should be specified. The need to know what time unit the last receiver of the time you send has been compiled with is a bad thing and should be avoided when ever possible.
  4. So using kill on the virtual sequence is not really an option here. I guess I could implement an stop function in both the virtual sequence and the sequence sending packages forever. The virtual sequence stop function will call the child sequence stop function. The child sequence stop function can set an internal bit that to stop sending more packages and make an while(stop_bit) instead if an forever. I thought that UVM already had an way to nicely stop sequences but apparently not.
  5. I have an virtual sequence that sets up the dut and then send either an specified number of packages or send packages infinitive. In the later case I want to be able to kill the sequence when I have simulated enough time. The problem is that it seems that only the virtual sequence is killed and none of the children sequence is killed. Since it is a child sequence running on an other sequencer that send package infinitive this is not good. In my test I would like to call virt_seq.kill() and make everything that sequence do stop.
  6. The method uvm_root::set_timeout() is now using time as data type which means that the time out you do get when specifying it in an test case depends on the time scale used in both UVM and your test case. Since UVM most often in pre compiled you do not really now what time scale is used there. Hopefully some day some one will wake up and understand that SystemVerilog needs a way to pass time that is consistent regardless of time scales but until the uvm_tlm_time is the best we do have.
  7. 3) should of course have been top_seg_cfg_length dist { 63:=1, 127:=1, 255:=1, 511:=1, [0:511] :/ 1, }; to much copy and paste. The problem with this is that other constrains can affect the distribution quite a lot. lets say we have the constrain x dist {[0:3]:=1, [0:511]\=1} and then in some test case adds the constrains x < 5; That will boost the probability for [0:3] quite a lot. This would not be a problem with an others clause. In my case this is not a problem and I might never have any problem with it but it is something you have to keep in mind.
  8. Is there any good way of doing an distributed randomization with dist for a few values that I know will be used and a lot of other values that could be good to test. I have a field that can take the value 0-511 where the values 63, 127, 255 and 511 will be used in the product but the other values should work. I therefore want to specify that the values 63, 127, 255 and 511 should be generated much more often then other values. What I have come up with is. 1) top_seg_cfg_length dist { 63:=4, 127:=4, 255:=4, 511:=4, [0:62] :/ 1, [64:126] :/ 1, [128:254] :/ 1, [256:510] :/ 1 }; which I think is ugly and a lot of unnecessary code. What I really would like to specify is 2) top_seg_cfg_length dist { 63:=4, 127:=4, 255:=4, 511:=4, others :/ 1, }; What will be the result if I would write 3) top_seg_cfg_length dist { 63:=4, 127:=4, 255:=4, 511:=4, [0:511] :/ 1, };
  9. The test case could create an derived class of the item class and do the constrain there and then do a type override on the sequence to make sure it uses the new item. I think this should be doable I am not to familiar with the type override. It seems to be a little complex to write thought.
  10. Would the randomize still use the constrained defined in repeate_seq and repeate_seq_tc_01?
  11. Yes you are right. I had done something wrong In my test bench where I use this approach but with more complex sequences so it did not get randomize properly in the test case. It would not work if some test case decides that it does not need to randomize the sequence before sending it which should be perfectly valid.
  12. After getting some more information on how constrain solving is done in Can-t-randomize-members-of-class-derived-from-uvm_sequence it seems that my proposal might not bee that good. Doing an randomisation on it self with only some parameters turned on might lead to unexpected constrains solver errors. Since constrains on all member variables is checked when doing the randomization. The question how should you do this then?
  13. Well for starter I have to set is_randomized to 1 else the assert(this.randomize(ph_num, pkt_size)); Will fail. It also seems a little dangerous to do an randomization on your self where you turned of all but two members. Depending on how constrains is set up when used this could lead to unexpected constrain solver errors. I guess it is better to take this discussion in the other thread.
  14. Well I did a read up on the LRM and it states that it is perfectly valid to constrain none random members and use them as a checker. That unfortunately makes my way of using constraining repeated sequence to be not so good.
  15. Does this mean that I can constrain an member that is not declared as rand and have the randomize fail if the member does not contain an valid value for the constrain because that is exactly what we doing here? The reason I asks is because of my question here constraining repeated sequence