VHDL inner component with inout port

[shaiko]

A is an inner component under to Hierarchy B
Port X of component A is defined as type "inout".
Port Y of component B is defined as type "in".

Can I connect both of them without changing the port type?

 

[ads-ee]

Just tried it with this code:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
library ieee;
use ieee.std_logic_1164.all;
entity a is
  port (x : inout std_logic);
end entity;
architecture behave of a is
  signal z : std_logic;
begin
  z <= not x;
end architecture behave;

---

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
library ieee;
use ieee.std_logic_1164.all;
entity b is
  port (y : inout std_logic);
end entity;
architecture behave of b is
component a is
  port (x : inout std_logic);
end component;
begin
  a_i : a port map (x => y);
end architecture behave;

---

This only works if y is defined as inout (as currently shown), otherwise the following error is reported when it's defined as an in:
ERROR: [VRFC 10-716] formal port x of mode inout cannot be associated with actual port y of mode in [b.vhd:11]
ERROR: [VRFC 10-145] y with mode 'in' cannot be updated [b.vhd:11]
ERROR: [VRFC 10-1504] unit behave ignored due to previous errors [b.vhd:6]

I wasn't sure about this so I made a testcase to check it. I actually figured it wouldn't work as VHDL is so strict about everything.

 

[FvM]

Try:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
library ieee;
use ieee.std_logic_1164.all;
entity b is
  port (y : in std_logic);
end entity;
architecture behave of b is
component a is
  port (x : inout std_logic);
end component;
signal yy: std_logic;
begin
  yy <= y;
  a_i : a port map (x => yy);
end architecture behave;

---

In addition, the design compiler might require inout port x to be permanently tristated.

 

[shaiko]

There's a real problem behind my question:

I'm using an IP core that has a port which is defined as type "inout" - this port behaves like output when the core is configured as master and input when the core is configured as slave. I however, intend to use it as slave only...

As the PCB is already manufactured, I have to connect this specific logic port to a specific FPGA ball.

The problem: this ball is a dedicated input ball! So I can't define the logical signal behind it as type "out" or "inout" - Quartus fails compilation during Place & Route.

 

[FvM]

The problem: this ball is a dedicated input ball! So I can't define the logical signal behind it as type "out" or "inout" - Quartus fails compilation during Place & Route.

The method sketched in my post should work in this case.

 

[ads-ee]

Try:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
library ieee;
use ieee.std_logic_1164.all;
entity b is
  port (y : in std_logic);
end entity;
architecture behave of b is
component a is
  port (x : inout std_logic);
end component;
signal yy: std_logic;
begin
  yy <= y;
  a_i : a port map (x => yy);
end architecture behave;

---

In addition, the design compiler might require inout port x to be permanently tristated.

Thanks FvM, I ran out of time to test something like this (my simulation had finished), just tried it and this is definitely a solution I'll have to remember. I find this type of stuff to be incredibly annoying and hence my preference for Verilog (even with it's warts).

 

[shaiko]

FvM,

How do you suggest to tristate x?
I have no access to it...

 

[FvM]

To make your design compile, x must not be tristated, at least not with Quartus. To be able to read an input signal, x must be tristated. I presume the slave configuration does just this.

I'm using internal tristate busses in a number of designs, utilizing that they are converted to multiplexers by the design compiler. An inout port that isn't either explicitely tristated or defined with a 'Z' initializercan cause problems in sythesis or simulation.

 

[ads-ee]

If it's inside the IP core and the tri-state control is under control of some registers in the core then it's likely to fail in the build process as you'll have a tri-state output that gets implemented that must be included in the design prior to the input only pin.

You might have to might have to write out a synthesis netlist and manually remove the tri-state cell prior to running the rest of the tools.

Lesson to learn from this...check/double-check/triple-check all I/O pins for both direction and pin type on the device. Supplemental lesson, don't let anyone else come up with a pinout that you don't get to approve before fabrication.

Good luck, hopefully I'm wrong but I don't think there is any easy way to get around this if you don't have access to the RTL of the core.

Regards

 

[FvM]

I guess the design will compile and work in slave mode flawlessly. Otherwise please tell.
In case you are using some standard Altera IP, what is it?

 

[ads-ee]

To make your design compile, x must not be tristated, at least not with Quartus. To be able to read an input signal, x must be tristated. I presume the slave configuration does just this.

I'm using internal tristate busses in a number of designs, utilizing that they are converted to multiplexers by the design compiler. An inout port that isn't either explicitely tristated or defined with a 'Z' initializercan cause problems in sythesis or simulation.

Wow, you're lucky, I've had problems with this kind of stuff in the past, so I always make sure that there are no embedded tristates. Maybe the tools have gotten better, but I'm not willing to risk a project on that. The last time I had something like this I at least had access to the RTL and removed the tristate and brought the input/output/tri-state-control to the module ports. At the time the synthesis tool I was using wouldn't infer a multiplexer between the input and the inout with the tristate control as the select.

Which tool are you referring to? I've mostly been using Xilinx ISE/Vivado for the past 10 years and not much Quartus-II during that time frame.

 

[FvM]

My experience in this regard is solely with Quartus. So I can't say if there are additional problems brought up by ISE/Vivado snythesis.

But quite generally I can agree with your suggestion to avoid internal tristates.

Saying I'm using it in a number of designs shouldn't it be misunderstood as a suggestion. They are used in the design due to specific reasons, e.g. a bus has been designed as regular external processor bus but was changed to a "virtual" internal bus in a derived design. They nevertheless work if you understood the operation principle.

 

[shaiko]

Solved it!

Epilog:
The core wakes up with the inout pin in question not necessarily tri-stated.
The reset value of that pin is set using another generic.

The slave/master configuration - kicks into place one cycle after reset according to a corresponding input port.
Setting the input port to '0' (slave mode) as I was doing wasn't enough.

As soon as I changed the generic that controls the reset value to drive 'Z' from the first cycle - compilation succeeded.

In other words, this makes the port at question wake up tri-stated and remain tri-stated.
My conclusion: in order for compilation to succeed - the inout MUST be explicitly tri-stated.

 

[FvM]

Solved it!

Good. Looks like the IP designers considered their work well.

Otherwise there would be still options to fix the "multiple drivers" issue. E.g. a dummy tristate disconnecting the external driver during reset.