Re: About inputs ports sending values up

On Jun 20, 1:35 pm, Evan Lavelle <nos...@xxxxxxxxxx> 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...@xxxxxxxxxxx"

<parag_p...@xxxxxxxxxxx> 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?

.

Relevant Pages

  • Re: About inputs ports sending values up
    ... Are you learning VHDL and Verilog at the same time? ... language, which was combined with a behavioural language. ... Drivers necessarily have direction (which might ...
    (comp.lang.verilog)
  • Re: Why does verilog allow you to write on a input port and VHDL does not
    ... Your basic question seems to be why Verilog allows something that VHDL ... How is the simulator correct in not allowing me to do so. ... Moreover you cannot write an input port in your VHDL process saying ...
    (comp.lang.verilog)
  • Re: From vhdl to verilog
    ... by migrating to Verilog. ... The clocked process has no variables. ... translating RTL Verilog into VHDL is trivial ... there are things you can do in synthesisable VHDL ...
    (comp.lang.verilog)
  • Re: Choice of Language for FPGA programming
    ... (snip on verilog and VHDL) ... < making some ignorant mistakes. ... We in the world would anyone want to use a language with as many side ...
    (comp.arch.fpga)
  • Re: verilog versus vhdl
    ... among other things I obviousely first have to learn one of the two ... interested in replies from people which know both languages cause ... I strongly prefer Verilog. ... VHDL is a much more complex language than Verilog. ...
    (comp.arch.fpga)
Loading