Xilinx and VHDL · Why is this INOUT port undefined

iseschematicssignalvhdl

I'm using Xilinx ISE 13.1 x64 WebPack for a college assignment and I'm implementing a BCT for the sake of it. It's a Binary Coded Ternary. Like a BCD, but with only three digits (0, 1 and 2), to decrease the amount of logic gates. I did all the equations and came up with the circuit.

It looks weird because, apparently, Xilinx ISE doesn't allow nets to have more than one name. So, as a convention, I used the letter 'i' as a semicolon and gathered all the names together in a single net. The nets starting with 's' are the segments of a seven segment display. 'A' and 'B' are the inputs. 'Bisg' is INOUT because the segment 'g' follows the value of input 'B'. Segment 'b' is always '1'. Segment 'c' is 'NOT B'. And so on.

I'd rather not use a buffer to separate inputs from outputs and create nets with different names, because I want to see if it's possible to do this this way. The net 'Bisg' as INOUT makes sense because the external circuit that will feed it will also feed the circuit that needs the segment 'g' signal.

However, when I tested this, it didn't worked as expected. I remembered to zero the values at the start, but when it was supposed to invert its value, it went to 'undefined' and stayed there. Here's the testbench:

-- Vhdl test bench created from schematic C:\Xilinx\projects\RelogioDigital\BCT.sch - Sat Mar 22 00:30:41 2014
--
-- Notes: 
-- 1) This testbench template has been automatically generated using types
-- std_logic and std_logic_vector for the ports of the unit under test.
-- Xilinx recommends that these types always be used for the top-level
-- I/O of a design in order to guarantee that the testbench will bind
-- correctly to the timing (post-route) simulation model.
-- 2) To use this template as your testbench, change the filename to any
-- name of your choice with the extension .vhd, and use the "Source->Add"
-- menu in Project Navigator to import the testbench. Then
-- edit the user defined section below, adding code to generate the 
-- stimulus for your design.
--
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
LIBRARY UNISIM;
USE UNISIM.Vcomponents.ALL;
ENTITY BCT_BCT_sch_tb IS
END BCT_BCT_sch_tb;
ARCHITECTURE behavioral OF BCT_BCT_sch_tb IS 

    COMPONENT BCT
    PORT( Bisg  :   INOUT   STD_LOGIC; 
             A  :   IN  STD_LOGIC; 
             Bnisc  :   OUT STD_LOGIC; 
             sf :   OUT STD_LOGIC; 
             saisdise   :   OUT STD_LOGIC; 
             sb :   OUT STD_LOGIC);
    END COMPONENT;

    SIGNAL Bisg :   STD_LOGIC := '0';
    SIGNAL A    :   STD_LOGIC := '0';
    SIGNAL Bnisc    :   STD_LOGIC;
    SIGNAL sf   :   STD_LOGIC;
    SIGNAL saisdise :   STD_LOGIC;
    SIGNAL sb   :   STD_LOGIC;

BEGIN

    UUT: BCT PORT MAP(
        Bisg => Bisg, 
        A => A, 
        Bnisc => Bnisc, 
        sf => sf, 
        saisdise => saisdise, 
        sb => sb
    );

-- *** Test Bench - User Defined Section ***
    A <= not A after 10 ns;
    Bisg <= not Bisg after 20 ns;
    tb : PROCESS
    BEGIN
        WAIT; -- will wait forever
    END PROCESS;
-- *** End Test Bench - User Defined Section ***

END;

I messed around ISim and found an option to show the drivers for a given signal. It says that both the testbench and the VHDL description are driving this signal to 'U'. In case it's useful, here's the generated VHDL:

--------------------------------------------------------------------------------
-- Copyright (c) 1995-2011 Xilinx, Inc.  All rights reserved.
--------------------------------------------------------------------------------
--   ____  ____ 
--  /   /\/   / 
-- /___/  \  /    Vendor: Xilinx 
-- \   \   \/     Version : 13.1
--  \   \         Application : sch2hdl
--  /   /         Filename : BCT.vhf
-- /___/   /\     Timestamp : 03/22/2014 00:31:07
-- \   \  /  \ 
--  \___\/\___\ 
--
--Command: sch2hdl -intstyle ise -family spartan3 -flat -suppress -vhdl C:/Xilinx/projects/RelogioDigital/BCT.vhf -w C:/Xilinx/projects/RelogioDigital/BCT.sch
--Design Name: BCT
--Device: spartan3
--Purpose:
--    This vhdl netlist is translated from an ECS schematic. It can be 
--    synthesized and simulated, but it should not be modified. 
--

library ieee;
use ieee.std_logic_1164.ALL;
use ieee.numeric_std.ALL;
library UNISIM;
use UNISIM.Vcomponents.ALL;

entity BCT is
    port ( A        : in    std_logic; 
             Bnisc    : out   std_logic; 
             saisdise : out   std_logic; 
             sb       : out   std_logic; 
             sf       : out   std_logic; 
             Bisg     : inout std_logic);
end BCT;

architecture BEHAVIORAL of BCT is
    attribute BOX_TYPE   : string ;
    signal An          : std_logic;
    signal Bnisc_DUMMY : std_logic;
    component INV
        port ( I : in    std_logic; 
                 O : out   std_logic);
    end component;
    attribute BOX_TYPE of INV : component is "BLACK_BOX";

    component AND2
        port ( I0 : in    std_logic; 
                 I1 : in    std_logic; 
                 O  : out   std_logic);
    end component;
    attribute BOX_TYPE of AND2 : component is "BLACK_BOX";

    component OR2
        port ( I0 : in    std_logic; 
                 I1 : in    std_logic; 
                 O  : out   std_logic);
    end component;
    attribute BOX_TYPE of OR2 : component is "BLACK_BOX";

    component VCC
        port ( P : out   std_logic);
    end component;
    attribute BOX_TYPE of VCC : component is "BLACK_BOX";

begin
    Bnisc <= Bnisc_DUMMY;
    XLXI_1 : INV
        port map (I=>A,
                     O=>An);

    XLXI_5 : INV
        port map (I=>Bisg,
                     O=>Bnisc_DUMMY);

    XLXI_20 : AND2
        port map (I0=>An,
                     I1=>Bnisc_DUMMY,
                     O=>sf);

    XLXI_41 : OR2
        port map (I0=>An,
                     I1=>Bisg,
                     O=>saisdise);

    XLXI_42 : VCC
        port map (P=>sb);

end BEHAVIORAL;

So, is there a mistake in what I did, or it's just impossible to overcome ISE's "lack of feature" and have to resort to additional logic gates?

Best Answer

Bisg is an INPUT signal not an INOUT despite the fact that it has other uses (driving segment G on the top level).

To see this; reflect that NOTHING in your component actually drives BISG.

So your component is regarded as driving it with an undefined initial level; that is, 'U', and the combination of that 'U' with any external driving level is - as ISIM says - 'U'.

You have 2 options to fix it:

(1) make BISG an INPUT since you aren't driving it. This is the simplest and in this case correct.

(2) Drive BISG in your component with 'Z' - that is, remove the 'U' output from the component. 'Z' means "high impedance : i.e. don't fight whatever external source (your testbench) is driving the pin. This is typically done to allow 2-way communication on a signal. The two ends must agree (somehow) which end is allowed to drive the signal and the other end must drive 'Z'.

In your case, adding the line

BISG <= 'Z';

(after the "begin") to your component BCT should resolve the problem. (Yes, you are modifying the file labelled "do not modify", and the modification WILL disappear when you next compile the schematic to VHDL).

Then re-run the simulation and all should be well.

I do not know if there's a way to implement solution 2 in the schematic - and I don't care : these days the schematic approach is an utter waste of time. Your whole schematic comes down to (the original entity, and)

architecture HDL of BCT is
begin
   Bisg     <= 'Z';
   Bnisc    <= not Bisg;
   sf       <= not Bisg and not A;
   saisdise <= Bisg or not A;
   sb       <= '1';
end HDL;

And simplifies further if Bisg is an input...

Which do you think is faster to create, and easier to read?

EDIT : if you need an output to drive segment G, there's nothing wrong with a separate port G, driven directly from input B, as G <= B; or a wire on the schematic.

Related Solutions

Electronic – Why is the simple counter VHDL not working? Where did the signals go

the rising_edge() parameter is only really for clock signals. One option would be the following:

clk_proc: process( clk, switch1, switch0 )
begin
    if switch1 = '1' then
        counter <= ( others => '0' );
    elseif rising_edge( clk ) then
        if switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

This is known as an asynchronously reset process, which means that it'll reset the counter whenever reset (switch1) is high, regardless of clock state. A synchronously reset process would look the same as your second example:

clk_proc: process( clk, switch1, switch0 )
begin
    if rising_edge( clk ) then
        if switch1 = '1' then
            counter <= ( others => '0' );
        elsif switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

You did state though that your second example didn't work as expected. My suspicion is that this is because the signals driving it are switches rather than clocked logic signals. Switches don't actually switch instantaneously, instead bouncing between on and off a few times before settling. You need to implement some sort of debounce process to produce a signal which is synchronous with your clock and can control your timer.

It's also worth mentioning that FPGA design is a lot easier if you simulate stuff first. Xilinx ISE includes a simulator - create a testbench and use it! That lets you easily see what's happening in your implementation before you ever get near hardware.

Bidirectional bus in vhdl

Take the following VHDL design description:

library ieee;
use ieee.std_logic_1164.all;

entity bidir is
    port (
        Z  : inout std_logic;
        Y  : out   std_logic;
        OE : in    std_logic;
        A  : in    std_logic
        );
end;

architecture behave of bidir is
begin

    Z <= A when OE = '1' else
         'Z' when OE = '0' else
         'X';

    Z <= 'H';                           -- pullup

    Y <= TO_X01(Z);

end behave;

There are potentially three or more drivers for the net connected to the mode inout port Z. There are two local drivers - the two concurrent signal assigments one driving from port A depending on the output enable OE (and propagating unknowns), the other a pullup.

There can be some some number of external drivers on the net Z is connected to, potentially none. The value of that signal net is determined by a resolution function.

This introduces the distinction between the driven value from a driver and the effective value of signal net. The value of the signal net in an expression is the output of the resolution function, and not the nearest driver.

In a timed simulation, or in the case of the output enables of two of these buffers with the output enable being delivered on different delta cycles (a second signal for one of the output enables derived from the other by a signal assignment), there can be overlap between active drivers. You typically logically AND a chip select with the output enable to prevent overlapped enables on multiple drivers. If the driven values of the multiple drivers are different (e.g. one '1', the other '0') you'll see a resolution of 'X' during VHDL simulation for the overlap.

The pullup implies that the default value of the signal net is 'H' when there are no 'active' drivers providing strong values ('1' or '0'). You'd typically 'filter' the 'H' to a '1' by using a conversion function (e.g. TO_XO1) on the signal being used internally on the theory that un-driven signals floating in the switching region for an input buffer is a bad thing, potentially causing high transient current loads and potential latch up.

With std_logic there are two ways to insure a driver doesn't interfere with another driver. std_logic is a resolved type, using a resolution table to determine the effective value, taking two signals at a time (a result value and each driver in turn, the result initialized to 'Z.

  constant resolution_table : stdlogic_table := (
    --      ---------------------------------------------------------
    --      |  U    X    0    1    Z    W    L    H    -        |   |  
    --      ---------------------------------------------------------
             ('U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U'),  -- | U |
             ('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X'),  -- | X |
             ('U', 'X', '0', 'X', '0', '0', '0', '0', 'X'),  -- | 0 |
             ('U', 'X', 'X', '1', '1', '1', '1', '1', 'X'),  -- | 1 |
             ('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X'),  -- | Z |
             ('U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X'),  -- | W |
             ('U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X'),  -- | L |
             ('U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X'),  -- | H |
             ('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X')   -- | - |
             );

The two axis of the resolution table are the two inputs. You might note that every intersection of 'Z' on one input results in the unchanged value of the other input. 'Z' is a safe value.

Specifying a 'Z' output for an 'inactive' driver is the correct thing to do for a pure behavioral model.

A structural model can use a disconnection specification on a guarded signal, specifying how long after an event a signal is driven. When it's not driven (disconnected) it's not involved in resolution.

Without disconnecting a driver the only way to have a driver uninvolved in the resolution value for a multi driver net is to drive it to 'Z'.

Best Answer

Related Solutions

Electronic – Why is the simple counter VHDL not working? Where did the signals go

Bidirectional bus in vhdl

Related Topic