Why does verilog allow you to write on a input port and VHDL

[parag_paul@hotmail.com]

I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

 

[Homuncilus]

On Jun 12, 6:47 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

I don't think so.
In verilog, the input ports you define just indicate that there is
wire driven by some sourse connecting the ports. However, the wire can
be driven by other sourse internal. That happens in some hardware
design.

 

[Evan Lavelle]

On Mon, 11 Jun 2007 15:47:32 -0700, "parag_paul@hotmail.com"
<parag_paul@hotmail.com> wrote:

I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

The port direction is basically advisory. I guess that this is
historically related to port collapsing in XL, where your port
probably ends up as an inout anyway. The LRM specifically says "A port
that is declared as input (output) but used as an output (input) or
inout may be coerced to inout. If not coerced to inout, a warning has
to be issued".

In other words, a simulator can do pretty much what it wants, although
a synthesiser or linter should flag this as an error for you.

As for the second part of your question, well, VHDL is different,
isn't it?

Evan

 

[parag_paul@hotmail.com]

On Jun 12, 4:07 pm, Evan Lavelle <nos...@nospam.com> wrote:

On Mon, 11 Jun 2007 15:47:32 -0700, "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

The port direction is basically advisory. I guess that this is
historically related to port collapsing in XL, where your port
probably ends up as an inout anyway. The LRM specifically says "A port
that is declared as input (output) but used as an output (input) or
inout may be coerced to inout. If not coerced to inout, a warning has
to be issued".

In other words, a simulator can do pretty much what it wants, although
a synthesiser or linter should flag this as an error for you.

As for the second part of your question, well, VHDL is different,
isn't it?

Evan

Obviously VHDL is different, and it does not go beyond the semantic
checks to coerce the ports too.


I also wanted to understand, given a inout port, what do yo mean by
getting the outside of an inout port. Do implementations have the
freedom to keep to ports for an inout. How does it matter,

|-------| |---------|
---- a |--------------| b |-----------
|-------| |---------|

Here port a is input and port b is output, Why are they not allowed to
connect in VHDL and Verilog allows

 

[Evan Lavelle]

I'm afraid that I don't understand most of your reply. Can you put
some more words in it, and redraw your diagram showing signal
directions and connections?

Your basic question seems to be why Verilog allows something that VHDL
doesn't. As I said, they're different. In this particular case,
because of a historical accident, the Verilog LRM allows something
which is both illogical and incorrect, and this is Not A Good Thing.
The text in the LRM is not attempting to justify this, because it's
not justifiable. The text just allows EDA vendors to write tools that
will accept old models that use this "feature".

Don't write code that does this because, as you've found out, your
simulator may not tell you that you've made a mistake.

 

[parag_paul@hotmail.com]

On Jun 12, 5:56 pm, Evan Lavelle <nos...@nospam.com> wrote:

I'm afraid that I don't understand most of your reply. Can you put
some more words in it, and redraw your diagram showing signal
directions and connections?

Your basic question seems to be why Verilog allows something that VHDL
doesn't. As I said, they're different. In this particular case,
because of a historical accident, the Verilog LRM allows something
which is both illogical and incorrect, and this is Not A Good Thing.
The text in the LRM is not attempting to justify this, because it's
not justifiable. The text just allows EDA vendors to write tools that
will accept old models that use this "feature".

Don't write code that does this because, as you've found out, your
simulator may not tell you that you've made a mistake.

Thanks Evan
In the diagram what I meant was that , suppose a is an input port and
is conencted to an output port in the instantiated module ( VHDL
perspective )
How is the simulator correct in not allowing me to do so. It say ,
port mismatch, although the concept of port coercion can happen , isnt
it?

I think VHDL simulator is at fault or is the behavior correct,
Moreover you cannot write an input port in your VHDL process saying
that it cannot be written to as it is an input port. But when you use
pli or debugger you are allowed to force a value there


Are we even getting near some code of strictness when it comes to
debug or everything goes

 

[parag_paul@hotmail.com]

On Jun 12, 6:58 pm, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

On Jun 12, 5:56 pm, Evan Lavelle <nos...@nospam.com> wrote:

I'm afraid that I don't understand most of your reply. Can you put
some more words in it, and redraw your diagram showing signal
directions and connections?

Your basic question seems to be why Verilog allows something that VHDL
doesn't. As I said, they're different. In this particular case,
because of a historical accident, the Verilog LRM allows something
which is both illogical and incorrect, and this is Not A Good Thing.
The text in the LRM is not attempting to justify this, because it's
not justifiable. The text just allows EDA vendors to write tools that
will accept old models that use this "feature".

Don't write code that does this because, as you've found out, your
simulator may not tell you that you've made a mistake.

Thanks Evan
In the diagram what I meant was that , suppose a is an input port and
is conencted to an output port in the instantiated module ( VHDL
perspective )
How is the simulator correct in not allowing me to do so. It say ,
port mismatch, although the concept of port coercion can happen , isnt
it?

I think VHDL simulator is at fault or is the behavior correct,
Moreover you cannot write an input port in your VHDL process saying
that it cannot be written to as it is an input port. But when you use
pli or debugger you are allowed to force a value there

Are we even getting near some code of strictness when it comes to
debug or everything goes

Also another doubt I have is, " I read somewhere in debug that for an
inout port get to the input port to get a list of the fanouts , Why is
it so ?
isnt the inout port in itslef capable of handling an array of fanouts

 

parag_paul@hotmail.com wrote:

I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

VHDL is a more formally defined language with stricter rules. Its
port connections are rather like software subprogram arguments, with
fixed directions. Its hierarchical resolution for drivers at
different levels of hierarchy is elegantly defined, but is not much
like real hardware.

Verilog is more quick-and-dirty. Its port connections (at least when
collapsed) act more like hardware. Unless a hardware connection has
buffering logic, it is just a wire with no inherent direction, and can
drive either direction. Its flat resolution for all drivers on a net
matches real hardware.

It is just a difference in language design philosophy. Each has
advantages and disadvantages, and different people prefer each. If
they were the same, there wouldn't be two different languages.

 

[parag_paul@hotmail.com]

On Jun 13, 4:46 am, s...@cadence.com wrote:

parag_p...@hotmail.com wrote:
I dont get it ,
Why is Verilog as a language allowing you what Hardware ideally should
not ?

VHDL is a more formally defined language with stricter rules. Its
port connections are rather like software subprogram arguments, with
fixed directions. Its hierarchical resolution for drivers at
different levels of hierarchy is elegantly defined, but is not much
like real hardware.

Verilog is more quick-and-dirty. Its port connections (at least when
collapsed) act more like hardware. Unless a hardware connection has
buffering logic, it is just a wire with no inherent direction, and can
drive either direction. Its flat resolution for all drivers on a net
matches real hardware.

It is just a difference in language design philosophy. Each has
advantages and disadvantages, and different people prefer each. If
they were the same, there wouldn't be two different languages.

So there is no concept of coercing in VHDL ?
Can you please confirm this
The VHDL LRM (1076-2000) does not say anything about that?
But DEBUG force on a signal does go up and down like an inout port ?
Why so ?