Electronic – Verilog – connecting multiple bidirectional buses

bidirectionalfpgaprogrammable-logicverilog

I've been designing a retro computer in verilog as an exercise and so far have a simple 8-bit CPU that communicates directly with a single RAM chip via a bidirectional data port. This works great in my testing, however the need has arisen to include a second RAM on a different bus, as video RAM that both the CPU and a graphics processor can interact with. To achieve this, I implemented a memory controller module. This module connects directly to both RAM chips on separate buses, and reads/writes to/from the CPU now have to go through this module.

Simplified module connections:

module memcontroller(inout[7:0] CPUdataBus, inout[7:0] RAMdataBUS, inout[7:0] VRAMdataBus)

When connecting the CPU directly with the RAM, I would just set the data bus to Hi-Z to use it as an input and read data from RAM. However, now I do this on the "RAMdataBUS" port and need a way to "connect" the input to the CPUdataBus port, which I can't figure out.

Perhaps naively, I thought something like this would work:

assign CPUdataBus = write ? CPUdataBus : RAMdataBUS;
assign RAMdataBUS = write ? CPUdataBus : 8'hZZ;

Which produces during synthesis:

RAMdataBus[7]" has multiple drivers due to the always-enabled I/O buffer "CPUdataBus[7]"

for each bit

There's likely a really obvious reason why this is invalid, but nonetheless I can't find a solution to the problem or fully understand the error.

Best Answer

Think of this in terms of hardware. RAMdataBUS outputs data or is tri-stated. But CPUdataBus is a mux. You can't connect a tristate to a mux. You can connect a tri-sate bus to anther tri-state bus.

Assuming write is the CPU write the CPU bus should be driven when writing, but tri-state when reading:

assign CPUdataBus = write ? CPUdataOut : 8'hZZ;

The memory bus should be driven (by the memory) when reading, but tri-state when writing:

assign RAMdataBUS = !write ? memory_data_out :  8'hZZ;

But that is not correct if you have multiple memories. Then it becomes:

assign RAMdataBUS = !write && this_mem_selected ? memory_data_out :  8'hZZ;

Related Solutions

Electronic – Birectional I/O pin in verilog

Inouts are actually "wire" so you can't use any procedural/sequential assignments (where the left hand side must be a reg). Generally speaking:

input : internally must always be of type net, externally the inputs can be connected to a variable of type reg or net.
output : internally can be of type net or reg, externally the outputs must be connected to a variable of type net.
inout : internally or externally must always be type net, can only be connected to a variable net type.

A common approach is to have an "enable" signal for the output of your inout, and to drive to high impedance if the output is not enabled. In your case direction is playing that role.

So try this instead:

module test(
    input  clk,      // The standard clock
    input  direction,  // Direction of io, 1 = set output, 0 = read input
    input  data_in,    // Data to send out when direction is 1
    output data_out,   // Result of input pin when direction is 0
    inout  io_port     // The i/o port to send data through
    );

    reg a, b;    

    assign io_port  = direction ? a : 1'bz;
    assign data_out = b;

    always @ (posedge clk)
    begin
       b <= io_port;
       a <= data_in;
    end

endmodule

The hardware corresponding to the above code would look something like this:

enter image description here

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 – Birectional I/O pin in verilog

Bidirectional bus in vhdl

Related Topic