About inputs ports sending values up

[parag_paul@hotmail.com]

hi All,
lets way we have the following scenario


library IEEE;
use IEEE.std_logic_1164.all;

entity bot is
port (i: input std_logic);
end entity bot;

architecture arc of bot is
begin
end architecture arc;

entity top is
port (j: input std_logic);
end entity top;

architecture arc of top is
begin
t1: entity WORK.bot port map (i=>j);
end architecture arc;


Now, one thing I dont understand is, if we are not allowed to connect
i from bot as output port, how do we send values up , to the top level
entity,.
What is the need to call ports as input or output then
What is the need to keep constraints for connections when we can
coerce everything,

In hardware , a wire is simply a wire, How does it know that which
direction to transfer signals

-Parag

 

[Evan Lavelle]

Wow. Are you learning VHDL and Verilog at the same time? That's a
really bad idea. Do one properly, then start on the other one.

On Wed, 20 Jun 2007 00:30:18 -0000, "parag_paul@hotmail.com"
<parag_paul@hotmail.com> wrote:

In hardware , a wire is simply a wire, How does it know that which
direction to transfer signals

A *very* good question; this goes to the heart of the difference
between VHDL and Verilog.

Verilog started life as essentially 2 languages: a structural netlist
language, which was combined with a behavioural language. The
'behavioural' language therefore ended up with a structural world
view, with a low-level paradigm (had to get that word in somewhere)
built up from 'registers' and 'wires'. After all, 'real' hardware is
built by connecting registers with wires, with a bit of combinatorial
logic thrown in somewhere, so why not? In the Verilog world, 'wires'
have no 'direction'; they don't drive anything (if you had provided a
Verilog example, as would have been appropriate for comp.lang.verilog,
then this would have been part of the answer to your question). This
all looks very logical at first sight, but, IMHO, it has scaled very
badly since the early 80's, and is the root cause of a great deal of
inconsistency and confusion in the language.

VHDL took a very different view. In VHDL, the only thing of any
interest is the concept of a 'driver'. Drivers connect directly to
each other; there are no wires, registers, "combinatorial logic",
primitives, and so on. Drivers necessarily have direction (which might
have been the answer to your question if you'd asked in
comp.lang.vhdl). This is a higher-level concept which is more amenable
to standard software concepts such as typing and type safety, but
which can also describe (nearly) any low-level hardware. I say
'nearly' because VHDL can't be used to describe (easily, or possibly
at all) some of the low-level primitives which are built into Verilog,
because some real hardware constructs don't look like 'drivers'. The
'driver' world view has, IMHO, scaled well over time, and has avoided
many of the problems which have become apparent with Verilog.

Evan

 

[parag_paul@hotmail.com]

On Jun 20, 1:35 pm, Evan Lavelle <nos...@nospam.com> wrote:

Wow. Are you learning VHDL and Verilog at the same time? That's a
really bad idea. Do one properly, then start on the other one.

On Wed, 20 Jun 2007 00:30:18 -0000, "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
In hardware , a wire is simply a wire, How does it know that which
direction to transfer signals

A *very* good question; this goes to the heart of the difference
between VHDL and Verilog.

Verilog started life as essentially 2 languages: a structural netlist
language, which was combined with a behavioural language. The
'behavioural' language therefore ended up with a structural world
view, with a low-level paradigm (had to get that word in somewhere)
built up from 'registers' and 'wires'. After all, 'real' hardware is
built by connecting registers with wires, with a bit of combinatorial
logic thrown in somewhere, so why not? In the Verilog world, 'wires'
have no 'direction'; they don't drive anything (if you had provided a
Verilog example, as would have been appropriate for comp.lang.verilog,
then this would have been part of the answer to your question). This
all looks very logical at first sight, but, IMHO, it has scaled very
badly since the early 80's, and is the root cause of a great deal of
inconsistency and confusion in the language.

VHDL took a very different view. In VHDL, the only thing of any
interest is the concept of a 'driver'. Drivers connect directly to
each other; there are no wires, registers, "combinatorial logic",
primitives, and so on. Drivers necessarily have direction (which might
have been the answer to your question if you'd asked in
comp.lang.vhdl). This is a higher-level concept which is more amenable
to standard software concepts such as typing and type safety, but
which can also describe (nearly) any low-level hardware. I say
'nearly' because VHDL can't be used to describe (easily, or possibly
at all) some of the low-level primitives which are built into Verilog,
because some real hardware constructs don't look like 'drivers'. The
'driver' world view has, IMHO, scaled well over time, and has avoided
many of the problems which have become apparent with Verilog.

Evan

Thanks again Evan
OK, Now I get it that in Verilog, there is something called as
collapsing and internally we do this thing called as coercing that can
put any new adoption to Verilog painful ( trust me )

But then again, one thing I dont understand is the following..


In the VHDL example that I have sent in the beginning,( with the
strict checkin and all that ....)
How is it possible that the input ports send values up, when forced
from PLI. Is the PLI implementation wrong.
What could have been the motivation behind force ? Just a supply pin
connected to the network?

If there are checks such as these what is the meaning of force ?



Also that,
lets say I have a VHDL entity (middle level) with an input port, It is
connected to a bottom leaf level guy , also with an input port . When
I say input port does it imply that it can take values from the guys
at the top level level as well as bottom level.

Doesnt the meaning imply so ? ( if drivers it is for VHDL ) that means
values are getting driven to it from top as well as bottom since it is
an input port. But look at the bottom leaf, it means that it can send
values up , though the port it has says it is input. What is the
meaning of a semantic check then?

 

[Mike Treseler]

parag_paul@hotmail.com wrote:

lets say I have a VHDL entity (middle level) with an input port, It is
connected to a bottom leaf level guy , also with an input port . When
I say input port does it imply that it can take values from the guys
at the top level level as well as bottom level.

Input ports have no drivers.
Unless there is an output
port mapped to the same signal,
the value is always 'U'.

Doesnt the meaning imply so ? ( if drivers it is for VHDL ) that means
values are getting driven to it from top as well as bottom since it is
an input port. But look at the bottom leaf, it means that it can send
values up , though the port it has says it is input.

It's the signal (wire) that resolves
a value from all the mapped drivers. In most
cases there is one driver from one output
port, so the calculation is not difficult.
Input ports mapped to the same signal have
no effect on its value.

-- Mike Treseler

 

[parag_paul@hotmail.com]

On Jun 21, 10:38 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

parag_p...@hotmail.com wrote:
lets say I have a VHDL entity (middle level) with an input port, It is
connected to a bottom leaf level guy , also with an input port . When
I say input port does it imply that it can take values from the guys
at the top level level as well as bottom level.

Input ports have no drivers.
Unless there is an output
port mapped to the same signal,
the value is always 'U'.

Doesnt the meaning imply so ? ( if drivers it is for VHDL ) that means
values are getting driven to it from top as well as bottom since it is
an input port. But look at the bottom leaf, it means that it can send
values up , though the port it has says it is input.

It's the signal (wire) that resolves
a value from all the mapped drivers. In most
cases there is one driver from one output
port, so the calculation is not difficult.
Input ports mapped to the same signal have
no effect on its value.

-- Mike Treseler

hi Mike
Just a dumb question, May be there are lingo diffs.
What is the meaning of mapping an ouput port to a signal . Any small
example please

 

[Mike Treseler]

parag_paul@hotmail.com wrote:

hi Mike
Just a dumb question, May be there are lingo diffs.
What is the meaning of mapping an ouput port to a signal . Any small
example please

We're way off topic, but here you go:

dut : entity work.uart
port map (
-- port id signal id driving process
-------------------------------------------------------
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback dest
serialOut => serialOut_s -- [out]-- by uut, loopback source
);

 

[parag_paul@hotmail.com]

On Jun 22, 1:38 am, Mike Treseler <mike_trese...@comcast.net> wrote:

parag_p...@hotmail.com wrote:
hi Mike
Just a dumb question, May be there are lingo diffs.
What is the meaning of mapping an ouput port to a signal . Any small
example please

We're way off topic, but here you go:

dut : entity work.uart
port map (
-- port id signal id driving process
-------------------------------------------------------
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback dest
serialOut => serialOut_s -- [out]-- by uut, loopback source
);

But VHDL semantic chek will not allow you to connect an input port
with the output. That is where i was getting confused.

 

[Evan Lavelle]

On Thu, 21 Jun 2007 21:39:36 -0000, "parag_paul@hotmail.com"
<parag_paul@hotmail.com> wrote:

But VHDL semantic chek will not allow you to connect an input port
with the output. That is where i was getting confused.

Parag - you're in the **wrong NG**. This is comp.lang.verilog; *not*
comp.lang.vhdl. You might as well be asking in comp.lang.c++, for all
the good it's going to do you.

But, since you ask, look up 'force' in your VHDL reference
manual/books/whatever. When you don't find it, look it up in your
simulator vendor docs. The commands you type into your simulator don't
necessarily have anything to do with VHDL. If you reply, perhaps you
might consider directing the reply to the VHDL NG instead.

Evan

 

[parag_paul@hotmail.com]

HI Evan
Thanks, but that forum, has very low activity, and I half expect an
answer. Here I might as well find a few takers.
Still I will keep in mind. And thanks a lot. I kept reading your
explanation for sometime, and got is clear in my head
This is a rebirth for me in concepts
-Parag


On Jun 22, 1:13 pm, Evan Lavelle <nos...@nospam.com> wrote:

On Thu, 21 Jun 2007 21:39:36 -0000, "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
But VHDL semantic chek will not allow you to connect an input port
with the output. That is where i was getting confused.

Parag - you're in the **wrong NG**. This is comp.lang.verilog; *not*
comp.lang.vhdl. You might as well be asking in comp.lang.c++, for all
the good it's going to do you.

But, since you ask, look up 'force' in your VHDL reference
manual/books/whatever. When you don't find it, look it up in your
simulator vendor docs. The commands you type into your simulator don't
necessarily have anything to do with VHDL. If you reply, perhaps you
might consider directing the reply to the VHDL NG instead.

Evan

 

[parag_paul@hotmail.com]

As for the solution of force . The language does not say much about
what it means. I always consider it to be a supply pin connected to a
wire somewhere in the between
-Parag

On Jun 22, 6:23 pm, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

HI Evan
Thanks, but that forum, has very low activity, and I half expect an
answer. Here I might as well find a few takers.
Still I will keep in mind. And thanks a lot. I kept reading your
explanation for sometime, and got is clear in my head
This is a rebirth for me in concepts
-Parag

On Jun 22, 1:13 pm, Evan Lavelle <nos...@nospam.com> wrote:

On Thu, 21 Jun 2007 21:39:36 -0000, "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
But VHDL semantic chek will not allow you to connect an input port
with the output. That is where i was getting confused.

Parag - you're in the **wrong NG**. This is comp.lang.verilog; *not*
comp.lang.vhdl. You might as well be asking in comp.lang.c++, for all
the good it's going to do you.

But, since you ask, look up 'force' in your VHDL reference
manual/books/whatever. When you don't find it, look it up in your
simulator vendor docs. The commands you type into your simulator don't
necessarily have anything to do with VHDL. If you reply, perhaps you
might consider directing the reply to the VHDL NG instead.

Evan

 

parag_paul@hotmail.com wrote:

As for the solution of force . The language does not say much about
what it means. I always consider it to be a supply pin connected to a
wire somewhere in the between

While it may be convenient to think of it this way for most purposes,
a force is not really equivalent to this.

Consider that you can force a net to high-Z, and the resulting value
of the net will be high-Z, no matter what else is driving it. So it
is not equivalent to just adding a connection.

There are also some other subtle ways that it is different.

To get the exact effect of a force, you would need to physically
disconnect all the other drivers from the net in addition to
connecting the forced value to the net.

This is part of why you have trouble fitting forces into the VHDL
concepts of port directions and hierarchical resolution. It is not
equivalent to simply adding a driver in a particular place. A tool
has to do something beyond what the language defines in order to
provide the desired capabilities for forcing.

 

[parag_paul@hotmail.com]

What is the meaning of hierarchial resolution

You mean , VHDL resolves values at different portions in the
hierarchy, But a wire is a wire all the way,
Different parts of the wire cannot be resolved to different values
is it?

I mean , somebody can get confused with VHDL but does it mean that
there can be different values in different part of a same wire
connected throughout the hierarchy