inout pin problem

[sagar g]

Greetings,
I'm using data_line as inout pin to implement SDI-12 protocol,
but it works fine until pre-synthesis simulation and shows 'X' value in post-synthesis simulation(through out the simulation),
I've used a tri-state buffer to change the state of inout pin from in to out and vice-versa.
while pre-synthesis simulation when data is driven on inout pin (i.e., when used as out) it shows 'X' for '0' and works fine for '1'.
help needed,
just check the top module code

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity top_module is
Port ( clk : in STD_LOGIC;
reset : in STD_LOGIC;
data_line : inout STD_LOGIC;
sensor_data : in STD_LOGIC_VECTOR (13 downto 0));
end top_module;

architecture Behavioral of top_module is
COMPONENT test
PORT(
clk : IN std_logic;
reset : IN std_logic;
data_line1 : IN std_logic;
data_line2 : OUT std_logic;
oe : OUT std_logic;
sensor_out : IN std_logic_vector(13 downto 0)
);
END COMPONENT;
signal data_in,data_out,oe : std_logic;

begin
u1: test port map (clk,reset,data_in,data_out,oe,sensor_data);
data_line<=data_out when oe='1' else 'Z';
data_in<=data_line;
end Behavioral;

 

[KJ]

Greetings, I'm using data_line as inout pin to implement SDI-12 protocol,but it works fine until pre-synthesis simulation and shows 'X' value in post-synthesis simulation(through out the simulation), I've used a tri-state buffer to change the state of inout pin from in to out and vice-versa. while pre-synthesis simulation when data is driven on inout pin (i.e., when used as out) it shows 'X' for '0' and works fine for '1'. help needed, just check the top module code

1. Type 'drivers /data_line' and verify that there really is only one driver for 'data_line'. If more than one driver, then either eliminate the interloper or if there are supposed to be more than one, the 'drivers' command will tell you who is driving the signal and what they are trying to drive it with. Verify that there is only one driver trying to drive anything other than 'Z', 'H' or 'L'.

2. If #1 is OK, then type 'drivers /data_out' and verify that there really is only one driver for 'data_out'. If more than one, remove the intruder.

3. If #2 is OK, then run your simulation up to the point where 'data_line' is an 'X'. At that point, 'data_out' must also be 'X' so you have to dig into the 'test' component.

The above process is called debugging and is best performed with a tool. The simulator is the tool and has all of the information you need to debug the problem. Look into the features such as 'Dataflow' which allows you to navigate quickly to the code that drives signals and graphically shows whatthe inputs are to each signal. The 'drivers' command is useful when (by design) there are multiple potential drivers for a signal and you're trying to figure out who is driving when you don't want them.

Kevin Jennings