Jump to content

gordon

Members
  • Content Count

    12
  • Joined

  • Last visited

  1. 1,304 downloads

    UVM Connect is a package providing complete SystemC interop support for SystemVerilog UVM/OVM via TLM1/TLM2 to easily integrate models in either language, supports any compliant simulator, and works with both UVM and OVM. Donated to Accellera by Mentor Graphics. The UVM Connect package builds on existing standards: SystemVerilog, SystemC and UVM, allowing TLM models in each language to communicate with each other. The package also includes an API that allows SystemC to interact with, and control the execution of, UVM testbenches. With version 2.2, the UVM Connect package supports OVM as
  2. 1&2: Yes, exactly. you can choose whether the container has the coverage inside or outside. I would add an analysis port, and put the coverage outside for a degree of decoupling (e.g. vertical reuse might want some predict/scoreboard functionality but not reuse of coverage). Not essential though. 3: no 'magic' configuration mechanisms for this - just make your own controls - you would use the standard UVM mechanisms for set/get config using the config/resource database, and have control over what coverage is turned on or off, across all the coverage in your bench. Vertical reuse also bene
  3. No problem, you are welcome: 1 & 2: you would need to draw a box around the {multi-stage predictors and scoreboard} and put them in a single 'container' component, and give that component an analysis port. The transaction emitted would need to be a compound of the various original traffic transactions processed by your predictors (not the 'converted' items sent to the scoreboard, but more likely need to be the 'original' items), and also have a handle to the register model. 3: interesting idea. I think the way forward might be to get the software tools we use to generate the register mod
  4. I think Adiel addressed the first part of your question: coverage for register testing, but not the main point which is coverage for functional testing. The kind of coverage that comes 'for free' with the UVM Register model and generator tools is for register testing only. The main thing to think about for functional testing is that it is insufficient to measure what the register bits are set to, and separately measure some functional activity on an interface of your DUT. Instead, we have to combine those together, and measure (a) that the registers were set a certain way and ( that some suf
  5. Accellera are still developing the use models and APIs for new UVM phasing as it relates to sequences, transactors. In the mean time, our recommendation is to wait until that work is done and the API is stable. For VIP design, code your driver and monitor to use only run_phase() and take care of reset separately - there are normally only 2 situations: (1) the driver/monitor is aware of reset as part of the protocol interface, and adjusts driven signals and monitored reports accordingly (to avoid the kind of signal conflict problem you refer to), and (2) the driver and monitor ignore reset, an
  6. Hi, thanks for your bug report, we will take a look.
  7. The text is just referring to the fact that 'new' is not just an ordinary function method, it does two entirely different things at once: (context 1) when you 'call' it, it acts as an R-value of an expression, appearing to act like a static function method which 'returns' a handle for the new object. It's role appears to be just 'allocate some memory and return a handle' (context 2) but under the hood, the object is created FIRST by the simulator and then the new() method is called with that object as 'context'. The role here is to set up the initial dynamic state of the new object, includin
  8. Hi Mike, Are you calling uvm_top.print() too soon? build_phase() is top-down. Try calling uvm_top.print() from end_of_elaboration_phase() which will give you the complete picture!
  9. I had a gut feel this might be a package problem, I've seen this `include problem before - but I was thrown off by the 5 fields discrepancy. This is a common problem - and note that a simulator would not normally emit a warning for duplicate class names (that's what package namespaces is intended to allow). And by $cast time the relevant information is often optimized out. I wish it were easier to spot this. My recommendation for package management on your UVC: have two packages: one for the UVC structure and one for its data: Data package: //my_data.svh package my_data; class my_ite
  10. Please see http://go.mentor.com/uvm1-0-questa for instructions for running Questa 10.0a with the UVM.
  11. 3) Agent's driver can be configured as a Master or Slave, and in both cases operates autonomously with the interface pins without taking any direction from the monitor. Monitor remains independent and aloof. Yes, that means you might have some duplicate code in monitor and {slave, or master} driver. Shared code in configuration objects referred to by both may help. But important that both remain autonomous. Think of 'Slave Driver' as just another protocol, same as 'Master Driver'. Monitor should be common to both though. A driver of the Slave end of a protocol could use configuration either
  12. The OVM/UVM factory automation / macros have limitations; it is unfortunate that the presence of a macro implies that the technique you're experimenting with is useful or appropriate. I don't think parameters are the right solution for you here for what is really a runtime soft configuration requirement. The best advice I can give you is to keep your data/sequence objects un-parameterized and use soft configuration instead. They are intended to be abstractions after all. Only parameterize your structural elements (i.e. the DUT, its interfaces, the env/agents/monitors/drivers that connect to
×
×
  • Create New...