libraryieee;useieee.std_logic_1164.all;entity a isport(x :inoutstd_logic);endentity;architecture behave of a issignal z :std_logic;begin
z <=not x;endarchitecture behave;
Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
libraryieee;useieee.std_logic_1164.all;entity b isport(y :inoutstd_logic);endentity;architecture behave of b iscomponent a isport(x :inoutstd_logic);endcomponent;begin
a_i : a portmap(x => y);endarchitecture 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.
libraryieee;useieee.std_logic_1164.all;entity b isport(y :instd_logic);endentity;architecture behave of b iscomponent a isport(x :inoutstd_logic);endcomponent;signal yy:std_logic;begin
yy <= y;
a_i : a portmap(x => yy);endarchitecture behave;
In addition, the design compiler might require inout port x to be permanently tristated.
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.
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.
libraryieee;useieee.std_logic_1164.all;entity b isport(y :instd_logic);endentity;architecture behave of b iscomponent a isport(x :inoutstd_logic);endcomponent;signal yy:std_logic;begin
yy <= y;
a_i : a portmap(x => yy);endarchitecture 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).
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.
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.
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.
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.
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.