How do I force a DUT signal from inside a class extending uvm_driver ? I have to use ‘force’ systemverilog keyword.
I cannot access it hierarchically from inside a class as it gives me compile error. I need some way to reference the internal DUT signal from inside the class so that I can force it to some value.
In reply to AMARDEEP R PALURU:
Hi,
You can add this signal in your interface, and access it in class using virtual interface.
In reply to AMARDEEP R PALURU:
If you want to access an internal signal in your DUT you have 2 options:
(1) access this signal through the hierarchical path in the toplevel module of your UVM environment.
(2) use the bind construct. This happens also in the toplevel module.
In reply to chr_sue:
If you need to do a ‘force’ statement, then what I would do is this:
a) create a 2-bit GPIO agent/driver at top-level testbench that you from your UVM test environment. One bit selects between ‘drive’ and ‘release’, the other is the value to be driven.
b) the GPIO output will trigger a bit of code that will do the ‘drive’ and ‘release’.
c) that bit of code will do a cross-module reference and drive your internal signal.
I’ve not tried doing ‘forces’ from within ‘bind’ statements - not saying they won’t work, but I’ve found that the tool vendors don’t rigorously test things that nobody uses. So I try to stick to the usual methods. And you’ll have to do the same GPIO and bit of force/release logic.
In reply to erik.k.jessen@raytheon.com:
What do you mean with an agent/driver at top-level testbench? Is this a class-based driver in the top-level testbench?
I disagree with using the bind. The bind is often used for SV assertions regarding the DUT.
In reply to chr_sue:
I agree that ‘bind’ is used for doing assertions - I do it all the time.
Normally testbenches have the driver at the top-level of the testbench. In fact, I don’t know anyone doing anything different. Even if you’re doing ‘harnesses’, the driver is instanciated in the top-level testbench.
My note was that I suspect that (in theory) there would be a way to do the ‘force’ from within the bind, I also suspect that the vendors haven’t verified their SW does it properly, so I’d not use it. I try to stick to the “main path” on tool features. Just because a feature is in the LRM, doesn’t mean it’s well-supported by the vendor(s).
So I think we are in “violent agreement” on the use of ‘bind’ and where to put UVM drivers.
In reply to chr_sue:
bind is used for many things besides assertions. It’s just that the one example of using it in the LRM happens to be with an assertion. This is no coincidence because the construct came out of a requirement for people adding assertions.
See this link for another example as well as my DVCon paper which shows how to integrate a UVM testbench with a bound interface.
In reply to erik.k.jessen@raytheon.com:
My question was what you mean with top-level of the testbench. Do you mean the top-level module. Then your statement is not true and its is even not on the top-level of the daynmic part of your UVM environment. Siganls are driven on the lowest level of your UVM environment, because the other parts are modeled TL constructs.
In reply to chr_sue:
“top-level of the testbench” as in: the top of the testbench. Whatever module contains the top-level instance of the DUT.
In reply to erik.k.jessen@raytheon.com:
OK, but in the toplevel module you should never instantiate an object of a driver class explicitly.
Regarding the bind and force. In my eyes there is no dependency. If your simulator is supporting force/release etc., it can be used in the bind construct.
BTW I’m teaching my customers never to rely on simulator features. They might be away after a major release. Always use language constructs.
In reply to chr_sue:
OK, hopefully this will clarify what I’m saying:
“driver” in the top-level testbench module is a module/interface. not a class instance.
“driver” in the top-level testbench environment is a class instance.
The two talk via multiple methods.
I’m using UVMF if that helps any. I’ve seen some very ‘interesting’ code out there, so I’m sure if it’s possible, someone somewhere has implemented it.
I have to be realistic: EDA vendors are businesses, and they’re going to address first issues with the features most commonly used. So combinations of language constructs (like bind+force) that are not typically done, might not generate the same results across vendors. Either because it simply wasn’t tested by each vendor, or because it’s a corner case, the LRM is ambiguous.
I ran into several of those when transitioning at one company from one EDA vendor’s simulator to another, and I know people at other companies who have had the same problems.
I practice defensive-programming when developing architectures. Of course, there are other people who are braver than I.
In reply to erik.k.jessen@raytheon.com:
You mewan with UVMF the Mentor UVM Framework generator. Right?
But moving from 1 company to another on makes the problem when you are relying on tool features. If the new company has a different simulator you are runninmg into serious problems. And you will n ot do this using language features.
In reply to chr_sue:
Hi,
- UVMF is not a tool feature; it’s a library of source-code classes. So it will run in Cadence, Synopsys, etc.
- My proposal doesn’t rely on UVMF anyways - I just happened to mention it, in case that helped clarify things. I’m sorry to have brought it up - please ignore it.
- Do you agree that drivers are implemented with a class-instance in an environment, and a module/interface instance in a testbench?
In reply to AMARDEEP R PALURU:
I recommend to read other thread about this. They recommend to use the SV force command on an interface.
https://verificationacademy.com/forums/uvm/how-force-dut-internal-signals-uvm-environment