I don’t understand how this would work. Given that physical latches within the RTL are clocked, how can merely specifying a hierarchical path to the latch result in the testbench being able to “write” the physical latch, in zero time (at least that is implied)? Given there are no concrete examples on the VA site (that I could find) with a testbench/RTL design package to illustrate this, it is difficult to tell what is being implemented.
In reply to krgarvens:
If you have any experience with Modelsim/Questasim you will recognise the “force” feature that allows you to change the value of any signal in the middle of a simulation.
There is nothing to stop the simulator stopping in between delta cycles and changing a value. All the back door access does is provide an api to do something very similar but from a systemVerilog perspective. Reading a value in the middle of the simulation if the hierarchical path of the simulation is known has been around for ages.
To get your path, compile and run your design, then look through the hierarchy browser in the simulation. You really should be able to trace your hierarchy through the VHDL/Verilog DUT without a problem
I believe this section talks a lot about back door access.
In reply to Phill_Ferg:
Most certainly a force can be used from the simulator to change the HW on the fly. I’m not sure how that is relavent here, unless a force is the mechanism UVM uses to do the backdoor write. That isn’t entirely obvious from reading the referenced section. It does mention force in one line, but wouldn’t the effect of a force depend on whether it is a ‘deposit’ or a ‘freeze’? Is this an implied force/release cycle?
In reply to krgarvens:
If the simulator can pause in between delta cycles and change the value of a wire/signal - then what is to stop UVM using the same API to read and write value to a wire/signal?
I’m not saying UVM uses force, but the the same function will be available via an API, FLI or DPI to produce the same result.
I am not sure what you mean by deposit or freeze.
The simulator will know about the entire hierarchy at run time, from all the UVM objects to the static hdl instantiations. It will be language dependent how well parts of a design have visibility of other parts.
The back door path specifies the route to the instance of the register. In the case of a write, the assignment happens to a internal signal of the register instantaneously. If you are driving that register with an input, on the next clock edge that value will change again.
In reply to Phill_Ferg:
Not sure what simulator you are using if you don’t know freeze vs deposit. In Modelsim, you have the choice - a force deposit will merely place the value on the net and that net is then free to change if something else wants to drive that net. A freeze force freezes that net so nothing else can change it until the force is removed. From everything I’ve read (and my experience) a SystenVerilog force acts as a freeze - you need to do a release if you want to allow the HW to control it. Modelsim also has a drive force, but I’ve never used that. As far as the mechanism used by UVM, would that be simulator-dependent? Seems to be that it would necessarily need to be implemented via a SV force/release so as not to impede the HW, unless it directly interacts with the simulator and it thus a tool-dependent implementation.
Sounds to me like back door writes, while possible, could be problematic and should be avoided. I would just a soon do frontdoors, as then you are not bypassing any other HW side-effects. For example, we have registers where, if you write one, others will automatically be written to that same value as well. It obviously depends upon HW implemenation. Seems to be that backdoor accesses are be used at your own peril.
In reply to krgarvens:
The bit(s) are deposited into the register components. I’m sure I see that word go by when I poke registers, and it makes sense not to be a freeze.
Any subsequent write thru normal channels can overwrite the value deposited.
The feature is extremely useful, to setup a register/control-heavy DUT before the real testing - of all its other features - can begin.
Be careful of using this to verify register accesses themselves - that’s not what it’s for.
In reply to gooby:
I do not understand why you are discussing about freeze and force regarding backdoor Access.
Could somebody explain, please?
In reply to chr_sue:
‘force’ is an action which questa supports, which places/drives a value onto a signal/net/reg inside the design.
That value can either be ‘frozen’ - left there forever so that the signal/net/reg will not change value, no matter what - or can be ‘deposited’ - set once, and after that the value might be changed by the DUT, for example when the reg is written to thru a processor interface in the normal way.
A backdoor access to a reg would typically not be a ‘freeze’, since backdoors are used primarily for initial setup of a DUT, or for some very specific register access testing.
HTH
In reply to gooby:
I know what a freeze and a deposit is and I know the UVM backdoor Access very well. The UVM backdor Access is not used only for some Setup. It is an official way to set RO regisres with certain values.
I’d like to understand why you are want to use the deposit and frozen command. These are Simulator commands, which is always a bad solution.
In reply to chr_sue:
I’m not suggesting using the force command for this.
The third post in this thread asked a question.
It is uvm_reg+questa which uses the ‘deposit’ to implement the backdoor.