Connections in Verliog.

Hello,


I understand the below mentioned code partially, that we are defining
the connections between different ports by names. I am not posting the
code for sample_test and angle_test to save people's space and time,
but I do have some logic running for these functionalities. So, lets
just assume some logic is defined for sample_test and angle_test. Now,
I had a few questions:

1) As one can see from the code, the output of sample_test_i and
sample_test_q is going as input to .xi and .yi in angle_test_0. So, i
am thinking that first s_in and sq_in would be processed to give the
output ssinter_i and ssinter_q respectively. Now, these would be
provided as input to .xi and .yi in angle_test. Am I right till now ?

2) Now subsequently, the angle_test_0 functionalities would run only
if all 3 inputs are active ? i.e. it will wait till ssinter_i and
ssinter_q are generated and phase is available to it? The angle_test_0
functionalities will not start until all 3 inputs are available or
would never start if all 3 inputs are not available.

I am not certain of the steps that I just described. Please correct me
if I am wrong. I saw a couple of similar posts, but got lost in the
code.

Jetli.





module ss_angle

(input clock,
input reset,
input wire [10:0] si_in,
input wire [10:0] sq_in,
output wire [10:0] si_out,
output wire [10:0] sq_out
);

wire [10:0] ssinter_i, ssinter_q;
wire [31:0] phase;

sample_test sample_test_i

( .clock(clock),.reset(reset),.signal_in(si_in),.signal_out(ssinter_i) );

sample_test sample_test_q

( .clock(clock),.reset(reset),.signal_in(sq_in),.signal_out(ssinter_q) );


angle_test angle_test_0
( .clock(clock),.reset(reset),
.xi(ssinter_i),.yi(ssinter_q),.zi(phase[27:13]),
.xo(si_out),.yo(sq_out),.zo() );


endmodule



P.S. One can assume that this is my top level code.

 

[John_H]

rjetli@gmail.com wrote:

Hello,


I understand the below mentioned code partially, that we are defining
the connections between different ports by names. I am not posting the
code for sample_test and angle_test to save people's space and time,
but I do have some logic running for these functionalities. So, lets
just assume some logic is defined for sample_test and angle_test. Now,
I had a few questions:

1) As one can see from the code, the output of sample_test_i and
sample_test_q is going as input to .xi and .yi in angle_test_0. So, i
am thinking that first s_in and sq_in would be processed to give the
output ssinter_i and ssinter_q respectively. Now, these would be
provided as input to .xi and .yi in angle_test. Am I right till now ?

2) Now subsequently, the angle_test_0 functionalities would run only
if all 3 inputs are active ? i.e. it will wait till ssinter_i and
ssinter_q are generated and phase is available to it? The angle_test_0
functionalities will not start until all 3 inputs are available or
would never start if all 3 inputs are not available.

I am not certain of the steps that I just described. Please correct me
if I am wrong. I saw a couple of similar posts, but got lost in the
code.

Jetli.

<code snipped>

Are you aware that the connections are always there? The angle_test_0
functionalities are always present, it's just that the specific
functionality is based on the function which you haven't provided. If
the functionality is defined as "sit and do nothing until the control
inputs are asserted" that's fine - it's functionality.

The signals are just wires. Lights are connected by wires and remain
connected. The switch just asserts or deasserts the signal
(current/voltage) to the wire. What the light does with the current is
up to the light's functionality - if the light is turned off at the
bulb, the wall switch does nothing even though the connectivity and
assertion are bot there. It's the function of the lamp that's now
dependent on the inputs.

- John_H

 

[Chris F Clark]

rjetli@gmail.com wrote:

I am not certain of the steps that I just described. Please correct
me
if I am wrong. I saw a couple of similar posts, but got lost in the
code.

To emphasize what John_H said about the connections always being
there...

All the wires, regs, inputs, etc. have values all the time and Verilog
is an inherently (pseudo-)parallel language. Thus, while computations
do flow from inputs to outputs. The ordering of instantiations is not
necessarily the order they are listed in the code. More importantly,
if you compute the value of some instantiation and it changes the
value of an input of some other instantiation you have already run,
then you need to run that other instantiation again, possibly causing
a sequences of events that cause this instantiation to be run again.
So, in that sense it is not good to think of the instantiations as
running in a specific order, but it is better to think of them as
running in parallel. In addition, an instantiation does not wait for
its inputs to become active (some always blocks do wait on events, but
thats another part of the picture), the inputs have values all the
time, and you can run (and rerun) an instantiation as often as need to
keep the outputs in synch with the current input values. In fact,
many siumlators do exactly that.

In fact, the term run and instantiation (or module), don't really make
sense in one sentence. You don't run an instantiation (or module).
You ma do run the always blocks, continuous assignments, and gate
primitive inside a module (or instantiation). But, you don't actually
run the module (instantiation) itself. That's kind of like asking
when you run an include file in C. So, if you take the previous
paragraph and substitute continuous assignment in it, you will have a
more correct explanation.

You can also apply that to always blocks, but then you have to talk
about even controls, and the picture gets more complex. Some always
blocks you can run over and over, others you cannot. In fact, I had
a much longer post, where I tried to explain this in more detail, but
it is far too complex to explain in a posting. You should really read
a good Verilog textbook.

Simply put: the reason you can't follow the posts is that there is a
fundamental model you must learn first to understand Verilog. Then,
once you understand that model, the reasons why things happens when
they happen will begin to make sense. Without that model, especially
thinking of Verilog in traditional programming terms, leads to all
sorts of confusion.

However, instantiations (and modules) are not boundaries that time in
Verilog respects. With a few small twists, you could essentially
replace all instances with the text of their defining modules and have
a functionally identical Verilog program (and the "elaboration" phase
essentially does just that). But, modules and instantiations are not
the first thing to understand about Verilog. So, learning Verilog
from this cordic example code is jumping into much too deep of water.
You need to understand things like the traffic light example first.