Active sources

V

valtih1978

Guest
I read in
http://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_12.HTM
that signal is active during simulation cycle

- If one of its sources is active or
- the signal is named in the formal part of an association element in a
port association list and the the corresponding actual is active.

=1= This immediately raises the question: how is the activity status
propagated? We see that the source or active port's actual causes formal
to be active. I do not understand why activity propagates down the
hierarchy: when you have active parent module signal then, connected as
input to the children, submodules will see it's activity as formal part
activity. Why activity should not propagate in the opposite direction,
through the output ports, from formal part to the actual?

I see a similar double standard in the driving value definition. It says
that if signal source is a port then formal part driver is used. You
cannot drive the input port this way but this is not necessary -
effective values are rather propagated downwards. We first propagate
info upwards through output ports by driving values and then signals
propagate downwards as effective values. Right? I see no such
bi-directional mechanism for the signal activity propagation.


=2= Moreover, I do not see how the signal activity flag is connected to
anything else. For instance, I see how driver's value originates from
the transaction, how this determines the driving values of signals and,
furthermore, the effective values. However, I see that all what
determines the signal activity flag is the activity flag of another
signal! I want to know how is the first active signal can ever appear in
such system?


=3= Ports are also sources. Why sources and ports are treated
separately? BTW, why not to instantiate the drivers for the ports also?
To avoid delta-cycle delays in ports?

=4= BTW, is slice a signal?

I have such a mess in my head. Will Ashenden fix it?
 
Ashendon may have been thinking that "one of its sources is active" covers output signal "propagating" (see 3 below) back up through the hierarchy (from submodule to module). Is he using "sources" synonymously with "drivers"?

=2= Signals are not the only things that cause events in simulation. Delays on "wait ... for" statements also cause events to be directly scheduled, with the process owning the wait statement being sensitive to the scheduled event. I remember being confused by a waveform at the end of one of my simulations. The clock and all signal activity had stopped a long time before the simulation actually stopped. Then I realized my testbench had a timeout on a wait statement that had not yet expired when I killed the clock (and thus all signal activity) in the testbench. The simulation had continued to "run" even though the wait statement had already triggered. Also, every process is executed at time zero.

=3= Instead of a signal "propagating up through the hierachy", think of ports as just a short-hand way of aliasing external signals (or aliasing external aliases to external signals). In 1076-2008, with the addition of references to external signals, one could do the same thing as ports and port maps with aliases to signals/aliases up or down the hierachical chain.

The modality of ports allows the compiler to verify the appropriateness of driving and/or reading those aliases. And since an alias is nothing but another reference to an existing signal, there is no delta cycle propagation delay associated with the ports/maps between driver and reader.

Note also that 2008 allows expressions in port maps (beyond type conversions). These break the implicit aliases before and after the expression, and an implied process (concurrent statement) is inserted between the two aliases/signals. The same delta cycle happened before when type conversions were used on port maps. I do not know if a built-in type conversion between "closely related" ports/actuals (really just a compile-time accounting trick) inserts a delta delay or not.

Andy
 
On 26.08.2013 15:45, valtih1978 wrote:
> This immediately raises the question: how is the activity status propagated

Ok, I have realized that driver is a source and active driver is the
originator of signal activity. But, I still do not understand how does
the activity propagate downwards.
 
On Tuesday, August 27, 2013 3:08:03 AM UTC-5, valtih1978 wrote:
> But, I still do not understand how does the activity propagate downwards.

You mean downwards through a hierachy via a series of in or inout ports/maps?

Again, if you think of ports and port maps as a shorthand way to define aliases to signals "on the other side" of the entity interface, there is no "propagation" of values involved (unless expressions are used in the port maps). Aliases are not copies of signals that are manipulated by the simulator to always keep the same values. They are new references to the same original signal (like an access type, but not dynamically associable with different signals).

There is but one signal for an entire series of mappings through a hierachy of entity/architecture pairs (defined at the uppermost level in the port chain), with many references to it in different entity/architectures.

Andy
 
Basically, my question is how does LRM specify the aliasing you are
talking about. The notion of alias implies that activity is propagated
up and down. However, in the spec I see only upward propagation. Port
source is active if actual is active. This implies downward propagation.
 
The LRM is silent WRT ports/maps being aliases. It is just my observation of the overall effects of ports and port maps (specifically that there are no delta-delays associated with ports/maps, only with associated expressions..) If you don't like my observation, you are free to ignore it, and substitute your own, or anyone else's, so long as it satisfies the LRM definitions of ports and port maps.

Propagation is a loosely defined term. I believe you are referring to how a driven value on a submodule's OUT port is made available outside that module, or how an instantiating module's driven value on a signal associated with a submodule's IN port is made available inside the submodule.

That is explained by the fact that only one signal exists in either of those cases. The compiler controls, by scope, map(s) and mode(s), where that signal's value can be legally read or driven. With only one signal, what is there to propagate?

Andy
 
On 29.08.2013 20:11, Andy wrote:
Propagation is a loosely defined term. I believe you are referring to how a driven value on a submodule's OUT port is made available outside that module, or how an instantiating module's driven value on a signal associated with a submodule's IN port is made available inside the submodule.
Click to expand...

I believe that I am talking about the signal activity propagation, that
I have quoted "

signal is active during simulation cycle
- If one of its sources is active or
- the signal is named in the formal part of an association element
in a port association list and the the corresponding actual is active.

" and hyperlinked,
http://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_12.HTM,
in the very beginning of my question!
 
Yes, that's it. I just do not understand how do they follow from the
definition. I believe that notes just repeat the points that are
hard-to-spot, yet present in the definition. I do not see how the upward
activity propagation follows from the downward.
 
> =4= BTW, is slice a signal?

It must be, since signal is an object and
http://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_4.HTM#4.3.2.2
says

A named object one of the following:
-- AN OBJECT DECLARED BY OBJECT DECLARATION,
-- Formal parts and etc

In addition, the following are objects, but are not named entities:
-- implicit signals
-- AN ELEMENT OR SLICE OF ANOTHER OBJECT
-- targets of access objects
 
Ok, it seems that ports are a kind of source. Therefore, activity will
spread both upwards and downwards. But, then I do not understand why did
they stipulate the active -> formal activity propagation right in the
definition if it follows from the notion of source? Why not just pick
this in the notes as it is done with formal -> actual output ports?
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top