Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by tudor.timi

  1. This is a pretty uncommon scenario, that you won't be able to implement without some extra code. This reminds me of a situation a colleague of mine faced, where different registers shared the same address, but they were differentiated based on some extra bits in the bus transaction objects. In your case, you differentiate using another register. It might be problematic to map multiple registers to the same address (you get warnings, but I'm not sure if nothing else gets busted). The first thing I can think of is that you can define your IP regs in a separate block (as you probably already
  2. See this thread: http://forums.accellera.org/topic/5062-uvm-sequence-for-slave-implementation/
  3. You listed your alternatives in decreasing order of complexity, i.e. option 1 needs more code than option 2 which needs more code than option 3. The problem is that the more stuff you throw away, the less flexible your whole solution becomes. I'd stick with option 1 because it provides the most controlability and it's not significantly more difficult to implement.
  4. A1: You can start your simulation with the +UVM_CONFIG_DB_TRACE plusarg to see messages for set(...)/get(...) in the log file. A2: You can have both use models. You can either tell the sequencer to start a sequence of a certain type by providing a type wrapper (like you did and the sequencer will instantiate it itself) or you can directly provide an instantiated sequence which you randomized/configured to your heart's desire (and the sequencer will start it). If you run your simulation with UVM_FULL (at least on the sequencer) you should see a message saying that it started the phase seque
  5. Even if two classes reference each other, you just need to add a forward typedef: typedef class ip_packet; class igmp_packet; // ... ip_packet ip_pkt; endclass This tells the compiler, "whenever you see 'ip_packet' treat it as a class and I'll describe it later". This is the class prototype feature you were looking for.
  6. In Specman there was a special event that happend at the end of a delta cycle, tick_end, which you could use for this. In SV/UVM there is a task that simulates this, uvm_wait_for_nba_region(), which you could call once you get your IGMP packet. This way you'd be sure that the write_ip(...) would also get called by the time you return from the wait. It's not pretty, but it's pragmatic. Another thing you could do is define some field in your IGMP packet where you'd reference the originating transaction, in your case IP. You could make it of type uvm_sequence_item if you intend to be able to
  7. I guess the only thing left is to show us how you start your sequence.
  8. Seems to me that you're starting it on a component of type uvm_sequencer_base instead of Sequencer. I'd check the type of your 'uvm_test_top.t_env.Seqncr' component.
  9. The item doesn't get deleted after the call to `uvm_do. If the VIP updates data, then your code should work.
  10. For a read transfer, it's your driver's job to fill the data field (I'm assuming you have one) of the item with the value present on the PRDATA bus. This way you know that once your item is finished (i.e. you return from `uvm_do_*(...)) you rely on the contents of it.data. I don't really see why you need the case statement in there, though.
  11. As far as I remember, using `uvm_sequence_utils(...) isn't fashionable anymore. To avoid using deprecated features, change it to `uvm_object_utils(Sequence0) and `uvm_declare_p_sequencer(Sequencer). Now, with respect to your problem, are you sure the sequencer you're starting the sequence on is of type Sequencer?
  12. Not much has changed. I've tried to declare a checker in all 3 BigEDA simulators and all of them complained of syntax errors (granted, for some I didn't have the latest and greatest versions).
  13. I guess for this you're going to have to open the hood and have a look (into the BCL source code).
  14. @Alan I'm not sure if this is going to affect reporting. I think supplying a parent when creating an object will only set the context used by the factory. I had a quick look through the code and when calling uvm_report_*(...) inside an object, you'll actually be calling the global methods which route the report to the top component (uvm_root). You should try making your object inherit from uvm_report_object instead, as this class contains its own report handler. If you also set the context of the object (by specifying a parent or a full path), then you'll be able to distinguish it from oth
  15. Do you need to know exactly how an engine works to be able to drive a car? The whole point of using libraries is that you don't need to care how they're implemented, rather how to use them. Coming back to the car analogy, the UVM user guide isn't a service manual, so it won't describe the parts the car is made of and how they're connected. It will tell you what buttons to press to turn on the radio, to turn on the AC, start the engine, etc.
  16. You can use enum_var.name() to return a string of the literal stored in enum_val (section of the LRM).
  17. You can foreach all registers and store the value of the whole register. Extracting the fields you do afterwards.
  18. You're going to have to implement your own copying scheme. It might get tricky because of all the 'local' fields in the register classes, but there's no way around it. At the same time, you could just store the register values at a certain point in time and when you need to do something with them, you can unpack those values in a temporary register of that type to extract the individual fields.
  19. Depends on how paranoid you are. It won't hurt to cover the reply as well, but my view is that you generally want to cover stimulus that you drive into the design. That's not a hard rule, though, since sometimes you want to cover that you reached certain states, for example, regardless of how you got there.
  20. I don't really remember what the Verification Academy cookbook said (it's a long time since I've seen it). I can tell you how I've started writing my plans. For your small little feature, I'd structure it like this: ARP interface -- The DUT should reply to an ARP request addressed to it ---- <map some cover item where I show I did ARP requests to the DUT> -- The DUT should drop ARP requests not addressed to it ---- <map some cover item where I show I did ARP requests to some other device> -- The DUT should drop ARP replies ---- <map some cover item where I know I did ARP re
  21. This has nothing to do with sequences or anything else. The Cadence simulator doesn't support using queues inside constraints. You'll have to use dynamic arrays. You don't need an additional field for the array size as you can just use tx_err_bytes.size() == 3. You do have to pass in the size of the array which is annoying, but there's no way around it.
  22. When you start your config sequence, that's when you can also update you agent's config.
  23. I'm guessing your device can only be in one mode at a time and this is configured via some fields in some configuration registers. It doesn't make sense to start sending OCTA frames when the device is configured for DUAL mode operation, hence there's no point in having mode a field in your sequence/item. When you configure your device for a certain mode (via some register/bus sequence) you need to reach into the configuration for your SPI agent and update that with the appropriate value (e.g. write registers to configure the device for QUAD, set the config field in the SPI agent to QUAD as wel
  24. Well it's telling you clearly that you can't use a queue in that context. Why can't you use a simple dynamic array instead?
  • Create New...