Is it possible to drive a port or signal from code and test bench in VHDL?

[biju4u90]

Is it possible to assign some value to a port or signal from VHDL code and test bench simultaneously. For example, I have a port named 'sda'. For some conditions, I need to drive this 'sda' from the code. At some simulation time, I need to make sda = '0' from test bench. Is it possible to do this?? I tried by defining sda as inout port. But since the value assigned to sda in code and value assigned in test bench drives the port simultaneously, my sda value goes to undefined state. In short, I want to control sda from code for some time, then i have to override the current sda value using test bench, and again after some time sda should get updated by the code. Is it possible to do this?

 

[FvM]

You should read about signal forcing.

 

[dpaul]

As FvM has mentioned, signal forcing is available from your simulator. That would be kind of analogous to the TB driving the port/signal to a constant value. This feature is available in ModelSim and VCS.
If you are using VHDL 2008 then try out the functions 'force' and 'release'. They are available for signals to be used from RTL.

 

[TrickyDicky]

I think the main question is Why? Forcing a signal isnt really meant for anything other than testing error conditions. If you are having to force a signal down into the hierarchy to complete your tests then your testing strategy is wrong, and should be redefined or fixed.

So why do you need to force this signal, and not drive it normally? Forcing cannot be done inside an FPGA.

 

[K-J]

Is it possible to assign some value to a port or signal from VHDL code and test bench simultaneously. For example, I have a port named 'sda'. For some conditions, I need to drive this 'sda' from the code. At some simulation time, I need to make sda = '0' from test bench. Is it possible to do this?? I tried by defining sda as inout port. But since the value assigned to sda in code and value assigned in test bench drives the port simultaneously, my sda value goes to undefined state. In short, I want to control sda from code for some time, then i have to override the current sda value using test bench, and again after some time sda should get updated by the code. Is it possible to do this?

Yes, a testbench and a design can both drive the same signal, but not simultaneously. If that is really what you're doing then I think you have a basic misunderstanding of electronics.

Two different sources driving the same signal occurs on bi-directional signals, but at no time should more than one source be actively driving the signal to a logic level. A driver should only be driving the signal when they are supposed to be driving it, otherwise the signal should be tri-stated. This has nothing to do with VHDL, this is electronics. For example, a static RAM memory chip will typically have an OE input. When OE is active, the chip will drive the data bus; when OE is inactive the drivers will be put in a high impedance state. When the memory chip is not actively driving the data lines, there can be another source driving those lines. The VHDL model for this behavior is:

data <= Memory_Data when (OE = '1') else (others => 'Z');

In your case, you have this bi-directional signal 'SDA' which means you'll have to have something like this in your design:

sda <= sda_internal when (OE = '1') else 'Z';

In a typical FPGA design the 'OE' signal is generated internally, not necessarily directly controllable from a testbench. But if sda is meant to be an I/O signal, then there must be some protocol that defines when sda is to be driven by the design and when it should be tri-stated. During the time that the design is tri-stating sda would be when the testbench can actively drive sda to a logic level as it so chooses.

Kevin Jennings

 

[std_match]

The sda pin should be "open drain"/"open collector" and have an external pull-up. Only drive '0' or 'Z' from the FPGA and the test bench.
As a pull-up, connect an additional 'H' driver in the test bench. 'H' is weak, so sda will go to '0' when either side drives it to '0'.
Make sure that your code treats sda = 'H' as sda = '1' when simulated. Do sda_input <= to_UX01(sda_pin) or similar to translate 'H' into '1'.