Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Mux INOUT port in VHDL

Hi all!

Currently I'm trying to connect my I2C master module to one of four I2C slaves using a mux without success: I can't get the bidirectional SDA signal to correctly mux. The code is as follows: 

mux_sda: process (sel, i_sda_o, sda)
begin
    sda <= (others => 'Z');
    if i_sda_o = '0' then
        sda(sel) <= '0';
    end if;
end process;
i_sda_i <= to_x01(sda(sel));
where

  • sda is a vector of SDA pins on the FPGA declared as INOUT,

  • i_sda_o the internal SDA output from the I2C Master to driver SDA,

  • i_sda_i the internal SDA input to the I2C Master to read SDA and

  • sel an integer used to select the pin to connect the master to.

If I try to simulate the module everything works as expected. Trying to synthesise it, Quartus complains "Illegal directional connection" for every pin in sda at "i_sda_i <= ..."

Can anyone please give me a hint why I'm not allowed to read a particular element of sda and how to solve that? Thank You!

Best Regards

Pauliman

PS: I'm on Quartus 11.0 and ModelSim 6.6d.

20 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi FvM!

    Many thanks for checking. What can I do to allow you to verify my problem? If I try to synthesise my project, Quartus complains

    Error: Illegal directional connection from the pin "O3_DDCSDA" to the node "EDIDOutput:EDIDOutput|Mux0"

    Error: Illegal directional connection from the pin "O2_DDCSDA" to the node "EDIDOutput:EDIDOutput|Mux0"

    Error: Illegal directional connection from the pin "O1_DDCSDA" to the node "EDIDOutput:EDIDOutput|Mux0"

    Error: Illegal directional connection from the pin "O4_DDCSDA" to the node "EDIDOutput:EDIDOutput|Mux0"

    where O?_DDCSDA are the members of the sda vector and EDIDOutput is the module my mux code is in. If I double click on any of the messages Quartus highlights the line "i_sda_i <= to_x01(sda(sel));".

    Best regards

    Pauliman
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    what does the function to_x01 do?

    in any case, if you have a high speed system clock, or if read latency is not a big problem, I would recommend registering the sda bus before you read \ MUX it. it might solve your problem, and as benefit will minimize the risk for metastability.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi the brick!

    to_x01() is supposed to convert all possible states of std_logic_vector to either 0, 1 or x. I'm using this to read a H as 1. The signals are I2C where the clock speed is in my case 100kHz. Registering would be an option. Thanks for the hint!

    Pauliman
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I think you misunderstand the difference between synthesis and simulation. in real life (synthesis) there are only 2 states for std_logic, '0' or '1'. when you drive 'Z" the bus will be pulled up to '1' by the pull up resistor on the board (part of I2C standard), unless the slave forces it down to '0'.

    Remove all references to 'H' 'X' and 'L' from your "operational" code, leave it for test benches.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    No, 'Z' is a real state that pins can drive. It means high impedance, and IS important in VHDL code. Without it you get no tri-state drivers on your pins (and errors associated with conflicting 0 and 1 - which is what 'X' is for in VHDL). A point to note though is that this is only permissable on FPGA pins. Internal tri-states will be converted to muxes during synthesis.

    There is nothing wrong with 'H' and 'L', as long as its in the testbench. Inside an FPGA, they will be converted to '0' and '1'.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    My to-be-synthesised code does not contain anything else then '0', '1' and 'Z'. In the testbench I simulated the pull-up resistors mandatory for I2C by assigning SDA <= 'H';. With that the levels are correct, but I can't read SDA correctly until I convert 'H' to '1' which is why I'm using to_x01().

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Tricky: does that mean that I'm not allowed to connect INOUT ports to internal modules and use them there are tri-state? I've grouped my tri-state pins (O?_DDCSDA) into a std_logic_vector (sda) and connected that vector to my EDIDOutput module in which the mux is located. Do I need to move the mux to the main module to get it working?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Tricky, I don't see any contradiction between our posts. I specifically wrote you can drive 'Z', but the signal value will be determent by the outside world.

    I also explained that 'H' and 'L' are for test benches.

    Pauliman, you don't need the x01 function. if the signal is driven 'Z' (from the master) and 'H' (from test bench) the simulator will translate it as '1' there is a table that defines which value "wins" in every conflict. in your case 'H' simulates the pull up resistor.

    in any case you wrote x01 as part of your code in the first post, and 'x' is also for simulation and test benches only.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Pauliman, you don't need the x01 function. if the signal is driven 'Z' (from the master) and 'H' (from test bench) the simulator will translate it as '1' there is a table that defines which value "wins" in every conflict. in your case 'H' simulates the pull up resistor.

    in any case you wrote x01 as part of your code in the first post, and 'x' is also for simulation and test benches only.

    --- Quote End ---

    You still need the to_x01 function, given what Pauliman said he is doing in his testbench.

    'Z' driven with 'H' gives 'H'

    if input = '1' then - would fail in simulation.

    if to_X01(input) = '1' then -would pass.

    Its only when you drive '1' and 'H' that you get '1'.

    You also have to be careful, because 'H' driven against '0' gives '0'.