VHDL port inout problem

Hi

I have an entity with inout port and instantiated this entity in the
test bench to send some test waveforms to it. Even though I assign a
value to this port in the test bench it always gets "U". The debugger
shows that the assignment istatement s getting executed but the value
remains "U". When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine. Why? I would really appreciate if anyone could clarify
this behaviour.

Thanks
MKumar
www.onchiptech.com

 

[Mike Treseler]

mkumar@onchiptech.com wrote:

I have an entity with inout port and instantiated this entity in the
test bench to send some test waveforms to it. Even though I assign a
value to this port in the test bench it always gets "U". The debugger
shows that the assignment istatement s getting executed but the value
remains "U". When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine.

If this is an internal port,
or if there are pins to spare,
consider separate input and output ports.
If the port really does need to time share
the a tri-buf pin, then direction control
logic must be added to the design.

For example, see the signals OE and READY
in the Bi-Directional Port example here:

http://home.comcast.net/~mike_treseler/

-- Mike Treseler

 

On Mar 25, 9:51 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

mku...@onchiptech.com wrote:
I have an entity with inout port and instantiated this entity in the
test bench to send some test waveforms to it. Even though I assign a
value to this port in the test bench it always gets "U". The debugger
shows that the assignment istatement s getting executed but the value
remains "U". When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine.

If this is an internal port,
or if there are pins to spare,
consider separate input and output ports.
If the port really does need to time share
the a tri-buf pin, then direction control
logic must be added to the design.

For example, see the signals OE and READY
in the Bi-Directional Port example here:

http://home.comcast.net/~mike_treseler/

-- Mike Treseler

Mike, Thanks
Its a bi-directional data bus with directional logic provided by Read
and Write control signals. When Read is active data is read from the
port and when write is active data is written to the port. I looked at
your eaxmple, thanks for the link, but I don't see reading from data
or data_s in the oe_demo.

MKumar
ONCHIP Technologies (P) Ltd
(OTUSB - embedded USB Software)
www.onchiptech.com

 

[Mike Treseler]

bhavanireddy@gmail.com wrote:

When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine.

Hmmm. If the port works "fine" as IN, that implies
that bidirectional data is not required there.

I looked at
your eaxmple, thanks for the link, but I don't see reading from data
or data_s in the oe_demo.

Did you see the waves?
http://home.comcast.net/~mike_treseler/oe_demo.pdf

-- Mike Treseler

 

[Account1]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:56o69vF29itgbU1@mid.individual.net...

bhavanireddy@gmail.com wrote:

When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine.

Hmmm. If the port works "fine" as IN, that implies
that bidirectional data is not required there.

Is there a good documentation about using inout ports? What the simulator
exactly does when evaluating design containing inout ports? What say LRM?


Thanks

I looked at
your eaxmple, thanks for the link, but I don't see reading from data
or data_s in the oe_demo.

Did you see the waves?
http://home.comcast.net/~mike_treseler/oe_demo.pdf

-- Mike Treseler

 

[Andy]

The unit under test has a driver for that signal too...

If not explicitly defined, it is driven as 'U'. You need an explicit
driver to 'Z' in there if you are not otherwise driving it. That way
the testbench driven value will win.

The only reason I use inouts for otherwise input only ports is if they
are part of a record type port, which usually ends up being mode inout
to handle different elements of the record being inputs and outputs.
Gets confusing after a bit, but synthesis figures out when you have a
continuous assignment to 'Z', and just gets rid of the driver
altogether. I usually define a default constant of all 'Z's for each
record type to make specifying a default driver easier. Unfortunately,
this means I cannot use integers, booleans, enums, etc. in those
record ports.

We really need user-defined modes for record types on ports, that can
individually define different modes for different elements of the same
record port.

Andy

On Mar 25, 8:34 am, mku...@onchiptech.com wrote:

Hi

I have an entity with inout port and instantiated this entity in the
test bench to send some test waveforms to it. Even though I assign a
value to this port in the test bench it always gets "U". The debugger
shows that the assignment istatement s getting executed but the value
remains "U". When I change the port type to "in" in the inner entity
and leave the port type as inout in the top level entity (test bench)
it works fine. Why? I would really appreciate if anyone could clarify
this behaviour.

Thanks
MKumarwww.onchiptech.com