Bidirectional Connections

Proposal Information

• Who Updates: KevinCameron, ...
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Proposal

A. Support flat resolution by just using terminals for all connecctions and moving (discrete) driver type declarations to the architecture.

B. Allow a process to ask for the resolved value of all other drivers of a signal. E.g. an implicit signal "<signal>'others".

[per Kevin's note: this is already in the language:] C. Add "<signal>'driving" implicit signal to recover current driven value for a process.

D Add "alias" statement (as SystemVerilog) for direct short-circuiting

-- JimLewis - 2013-07-22: How are C and D different than the features already in VHDL with the same name?

-- KevinCameron - 2014-03-16 - missed that 'driving got added (have not been keeping up to date) - it's probably sufficient. "alias" in VHDL is a more like a typedef than a short-circuit (by my reading).

Related Issues:

ISAC IR 2007

Competing Issues: None at this time

Requirement Summary

Most basic electronic components are bidirectional, so you can't really have a "hardware description language" without supporting it.

-- JimLewis - 2013-07-22

Do you need a simple attachment type connection that permanently connects busses:

BusA <=> BusB ;

Or do you need a conditional type attachment:

BusA <=> BusB when Enable ; 

Or perhaps a selected type attachement:

with BusSelect select
    BusA <=> BusB when "00", BusC when "01", BusD when "10", NULL when others ; 

-- DanielKho - 2013-11-10 :

It will be good if there are examples for Proposals A - D.

Does this help simplify existing VHDL implementations? Existing VHDL already models bidirectional ports very well. In fact, there are already existing models of passgates in VHDL, but they are all not part of the standard. Perhaps it's a good idea to standardize some of these implementations, or at least provide recommendations.

My view is when we connect bidirectional ports between two different components together, we could do it by simple port mapping:

signal bidirSignal: resolved std_ulogic;

componentA: entity work.compA(rtl) port map(a=>bidirSignal);
componentB: entity work.compB(rtl) port map(b=>bidirSignal);

This assumes that both components A and B are in the same design (good for ASICs but not FPGAs - FPGAs don't allow internal bidirectionals), so the bidirectional signal "bidirSignal" must be of a resolved type. We can implement resolution functions for driver resolution. For a bidirectional port that connects to an external device, there should be no problems with driver resolution - we can even keep it unresolved.

Are we proposing to simplify this process? If this is the aim of this proposal, I am for it. Otherwise, I believe existing VHDL already does a really good job at modelling bidirectional components.

To model bidirectional signals, it's good to model the behaviour of each end separately:

entity compA is port(a: inout std_ulogic); end entity compA;

architecture rtl of compA is
    signal s: std_ulogic;    -- data to write to compB.
    signal r: std_ulogic;    -- data that was read from compB.
    signal writeEn: boolean; -- handshaking between compA and compB.
begin
    a <= s when writeEn else 'Z';

    -- read data from bidir port only when port has been released (high-Z)
    -- for reading.
    r <= a when not writeEn;
end architecture rtl;


entity compB is port(b: inout std_ulogic); end entity compB;

architecture rtl of compB is
    signal s: std_ulogic;    -- data to send to compA;
    signal r: std_ulogic;    -- data that was read from compA;
    signal writeEn: boolean;
begin
    b <= s when writeEn else 'Z';

    -- read data from bidir port only when port has been released (high-Z)
    -- for reading.
    r <= b when not writeEn;
end architecture rtl;

Another approach to do the same thing without doing port maps, is to place the behavior of compA and compB together in the same entity, and connect the signals directly:

architecture rtl of top is
    signal s: resolved std_ulogic;      -- bidirectional signal between processes A and B. Resolved signal.
    signal s_a: std_ulogic;    -- data to send from prcsA to prcsB.
    signal s_b: std_ulogic;    -- data to send from prcsB to prcsA.
    signal r_a: std_ulogic;    -- data from prcsB, and read by prcsA.
    signal r_b: std_ulogic;    -- data from prcsA, and read by prcsB.
    signal writeEn_a, writeEn_b: boolean;
begin
    prcsA: process(all) is begin
        s <= s_a when writeEn_a else 'Z';
        r_a <= s when not writeEn_a;
    end process prcsA;

    prcsB: process(all) is begin
        s <= s_b when writeEn_b else 'Z';
        r_b <= s when not writeEn_b;
    end process prcsB;
end architecture rtl;

If the intent of this proposal is to simplify any of these existing methods, I am for it.

-- KevinCameron - 2014-03-16

Simple switch -

entity switch is port(a:    inout std_ulogic, 
                      b:    inout std_ulogic,
                      ctrl: in    boolean); end entity switch;

architecture rtl of switch is
begin
    a <= b'others when ctrl else 'Z';
    b <= a'others when ctrl else 'Z';
end architecture rtl;

-- JimLewis - 2014-03-16

Updated version of Kevin's switch example, uses a process to be consistent with the definition of 'others and using an if to clairify that it is a switch as opposed to a transceiver:

process(a, b, ctrl)
begin
  if ctrl then   
    a <= b'others ;
    b <= a'others ;
  else 
    a <= 'Z' ;
    b <= 'Z' ;     
  end if; 
 end process ; 

A transceiver (similar in coding to above - should work now without 'others although, with 'others it should settle faster):

process(a, b, ctrl)
begin
  if ctrl then
    a <= b'others ;
    b <= 'Z' ; 
  else 
    a <= 'Z' ;
    b <= a'others ;    
  end if; 
end process ; 

Rationale

Without the ability to model simple switches VHDL is pretty much toast.

Requirement details

Model a pass gate.

Use Model

Just describe your circuit and have it work.

Arguments FOR

Long overdue.

Arguments AGAINST

?

General Comments

Prior attempts at adding this support didn't get as far as a vote.

Supporters

-- DanielKho - 2013-11-10 (if proposal intends to simplify existing approaches)

Add your signature here to indicate your support for the proposal