Jump to content

tudor.timi

Members
  • Content Count

    289
  • Joined

  • Last visited

  • Days Won

    33

Everything posted by tudor.timi

  1. If you want to access only one register that is wider than the bus, then it's even easier. I'd for sure implement a custom frontdoor for that register. While trying to use the adapter you'll run into the limitation that the register map will chop the big access into pieces and you won't get a burst, but multiple individual transfers.
  2. I'd also advise against using assert for casts and randomization because when you disable such an assertion, your simulator might decide to not do the randomize or $cast at all (some sims do it, some don't, not sure if it's an LRM gray area).
  3. Instead of creating your own event_holder class, you should just use uvm_event. It does the same thing and has some extra goodies. You could pass this through your config DB.
  4. You wont' be able to implement such a thing using a reg adapter. You're going to have to use the frontdoor mechanism. What I could imagine is that you could use some static member in the frontdoor to store multiple register items (that come from register reads and writes). Once you have enough to form a bigger burst, you could collect them into one big bus transfer and send them to the bus sequencer. Have a look in the UVM user guide for more details.
  5. That's not the one, but it's also a pretty cool article. The one I meant was the October 2013 issue: https://s3.amazonaws.com/verificationhorizons.verificationacademy.com/volume-9_issue-3/complete-issue/stream/volume9-issue3-verification-horizons-publication-lr.pdf
  6. There was an article on exactly this in an older edition of Verification Horizons. I can't find it at the moment, unfortunately. SVA sequences provide a nice way of describing your protocol and end up being much cleaner than procedural code in a monitor. It would be cool if SVAs could also somehow be used to offload tasks from the driver (the complementary of the monitor). This would lead to less redundancy.
  7. What if you have to verify an SPI master using the same UVC? In that case you can't rely that the design is driving Z when in a certain mode. This is exactly what you need to verify. I'd avoid making such assumptions.
  8. I'd rather suggest to have a configuration field that states in which mode you are (single, dual, quad, octa). This field could be part of a configuration object that is shared by both objects: typedef enum { SINGLE, DUAL, QUAD, OCTA } mode_t; class spi_config extends uvm_object; rand mode_t mode; // ... endclass class spi_driver extends uvm_driver #(...); spi_config cfg; // ... endclass class spi_monitor extends uvm_monitor #(...); spi_config cfg; // ... endclass class spi_agent extends uvm_agent; spi_config cfg; spi_driver driver; spi_monior monitor; virtual fun
  9. From what I know, SPI doesn't specify things such as addresses and data, just frames. It's not a memory-mapped bus. How you interpret those frames depends on your device, so writing a register adapter is also a project specific task.
  10. I'm trying to use the $past sampled value function, whose prototype is: $past ( expression1 [, [number_of_ticks ] [, [expression2 ] [, [clocking_event]]] ] ) I've made a small example in which I use the 'expression2' argument: module top; bit clk; logic enable; logic [7:0] a; always #1 clk = ~clk; always @(posedge clk) begin $display("past(a) = %x", $past(a, , enable)); end initial begin @(posedge clk); enable <= 1; a <= 'hf; @(posedge clk); enable <= 0; a <= 'ha; @(posedge clk); @(posedge clk); enable <= 1; a &l
  11. Yes, you'll just need the post_predict(...) callback. Whether or not you have explicit prediction turned on only changes who calls the register's predict(...) function. For auto-prediction, predict(...) gets called by the address map in response to a register read(...) or a write(...). In explicit prediction mode, the reg predictor calls predict(..) when it receives a bus transaction. The pre/post_read/write(...) callbacks only get called in response to a call to read/write(...) inside a register sequence. I haven't really found any use for them yet. Long story short: read/write(...) for stimu
  12. The post_read(...) function is only called when you do an actual rg.read(...) inside a sequence. If you have explicit prediction set up (where the contents of a register are computed based on transactions coming from the bus monitor and not from the register sequences), then you'll need to implement this using post_predict(...). I've written on the topic of how to implement fields with custom access policies here. The concepts should transfer over to your problem (you'll just need different implementations of the post_predict(...) method to handle your behavior). Try it out yourself and if you
  13. Is there any particular reason why uvm_reg doesn't have an associated post_predict function or post_predict callbacks defined? A use model could be, for example, to check bus responses of register accesses. This is an aspect that applies to the whole register and not an individual field.
  14. You don't find it there because it's not meant to be used by UVM users. Messages flagged with UVM_DEBUG are intended for UVM base class library development and debugging.
  15. As David already mentioned, you don't have to keep your model and the DUT in exact lockstep. Most of the times you don't need to care about such micro-architectural aspects that can be verified through other means (like SVAs). Your goal isn't to re-implement the design in all its glory in your testbench.
  16. I don't see why you need to support both deprecated and non-deprecated. Usually when you're developing a testbench you choose a UVM version and stick with it. You can always change your code to only use non-deprecated constructs and ride with that. It only gets more complicated if you're developing VIP that's supposed to be used in multiple projects, but there the scope is more limited and focused and you won't get into such situations that you need to care about deprecated features (speaking as an internal VIP developer).
  17. @David In some cases it actually makes sense to create virtual classes instead of interface classes, because you want to provide some fields and implementations to some of the methods the class to be extended defines.
  18. Is your adapter configured with the provides_responses switch? That would explain why you get bus2reg called twice. One call would be from the sequencer-driver-sequencer path and the other would be from the monitor. If this is the case, it might be that you aren't updating the response item for reads inside the driver with the appropriate data, which would explain why you get 0.
  19. I'd say that that define is kinda broken. This is in part because because begin/end_tr trigger these begin/end_events which are used for other stuff too. Whether transaction recording is or is not enabled shouldn't affect the behavior of other aspects.
  20. You showed us code code for a reg adapter, but then you also showed a vanilla bus sequence. What are you running there? Read section 5.9 of the UVM user guide for details about integrating a register model.
  21. After looking at a bit more at the code, I think the branch for wide transfers (n_bytes > bus_width) is also broken. See my fork of the repo: https://github.com/tudortimi/freecellera-uvm/blob/bug_blitz__mantis_0005258/distrib/src/reg/uvm_reg_map.svh
  22. I'm guessing acc+=rw:* means "give me read/write access to all signals in the design". What you need to find out is how to say "give me access only to the registers" using 'acc'.
  23. Optimizations like that are done at elaboration time, so you can't say you want to enable them later during the simulation. The simulator simply does't track the values of some intermediary signals to make the simulation faster. You'll have to search in the manual how to turn on access only for for the signals you need for the backdoor. I think the switch is +acc in Questa. No idea about VCS.
  24. I think that's what the big X means, that just some of the bits are unchecked. The little x's probably mean that all the bits of that nibble are unchecked. Are you sure you don't have another field between [31:28]?
×
×
  • Create New...