clocking on a variable

[Ralf Hildebrandt]

Hi all!

I just want to hear some opinions about the following (illegal) construct:


process(sig_A,sig_B)
variable clock : std_ulogic;
begin
clock:=sig_A XOR sig_B;
if rising_edge(clock) then
-- do something
end if;
end process;


As I said this is forbidden, because only clocking on a signal is
allowed. My question is: Why? Is it "weak point" in VHDL? Could this be
allowed in the next VHDL standard?


The reason for this construct is just better readable code. Within an
architecture of 1000+ lines of code, dozens of signal are used.
Sometimes similar signals are needed for several registers. Therefore
signal names grow bigger (to make the code readable) and the number of
signals grows. Especially for register-individual clock-gating (to save
power) it would be useful to eliminate all these signals and convert
them to variables.


Ralf

 

[Mike Treseler]

Ralf Hildebrandt wrote:

clock:=sig_A XOR sig_B;
if rising_edge(clock) then

As I said this is forbidden, because only clocking on a signal is
allowed. My question is: Why?

Because a variable is a sports car
and a signal is motor home.

Signals have many attributes including 'event
and can wire processes together. They also
suck up simulation resources
and can pollute the name space.

Variables have only a local value
that needs a ride on a signal to get
in or out of a process.

Is it "weak point" in VHDL?

I like having the option of driving either car.

The reason for this construct is just better readable code. Within an
architecture of 1000+ lines of code, dozens of signal are used.

Using variables whenever possible *inside* each
process will clean up the name space and add clarity.

-- Mike Treseler

 

[Tuukka Toivonen]

In article <54ydnQiB-aHTT0jd4p2dnA@comcast.com>, Mike Treseler wrote:

Using variables whenever possible *inside* each
process will clean up the name space and add clarity.

The same could be achieved by just declaring in standard
variable and signal identical, and allowing to define
signals in the beginning of processes.

So, I'm not convinced that clarity is the primary advantage,
but rather:
- signals and variables have different semantics, a variable
changes immediately, a signal does not. Both behaviours
are useful
- IMO even more important: variable is much faster and simpler
than a signal. If you're modeling a large RAM, variables
are much more economical.

 

[Ralf Hildebrandt]

Mike Treseler wrote:

Ralf Hildebrandt wrote:

clock:=sig_A XOR sig_B;
if rising_edge(clock) then


As I said this is forbidden, because only clocking on a signal is
allowed. My question is: Why?


Because a variable is a sports car
and a signal is motor home.

Signals have many attributes including 'event
and can wire processes together. They also
suck up simulation resources
and can pollute the name space.

Variables have only a local value
that needs a ride on a signal to get
in or out of a process.

Is it "weak point" in VHDL?

This was not the idea behind my question. I totally agree with you, that
signals and variables fit for different purposes.

But in my example the variable is just an utility. It helps me just to
provide the needed clock-signal without additional signal names.

Maybe it is (very) difficult to test such stuff in a strong language,
but on the other hand: What is the reason for forbidding clocking on a
variable? O.k. - you say, that the lack of the 'event attribute is the
breakpoint in the VHDL standard at the moment, but why is it impossible
(or just a bad idea) to add this feature?


Again: The intention of my question is just to get a clearer view to
VHDL. I stumbled over this problem, but had no idea, why this
well-readable construct is forbidden.

Using variables whenever possible *inside* each
process will clean up the name space and add clarity.

Hehe ... this is *exactly* the reason, that led me to this problem.


Ralf

 

[Just an Illusion]

Hi Ralf,

Ralf Hildebrandt wrote:

snip

Is it "weak point" in VHDL?



This was not the idea behind my question. I totally agree with you,
that signals and variables fit for different purposes.

But in my example the variable is just an utility. It helps me just to
provide the needed clock-signal without additional signal names.

Maybe it is (very) difficult to test such stuff in a strong language,
but on the other hand: What is the reason for forbidding clocking on a
variable? O.k. - you say, that the lack of the 'event attribute is the
breakpoint in the VHDL standard at the moment, but why is it
impossible (or just a bad idea) to add this feature?


Again: The intention of my question is just to get a clearer view to
VHDL. I stumbled over this problem, but had no idea, why this
well-readable construct is forbidden.

I think that is link with the process 'awake' management. Read lrm
section 12.6

snip

Ralf

JaI

 

[Wallclimber]

This was not the idea behind my question. I totally agree with you, that
signals and variables fit for different purposes.

But in my example the variable is just an utility. It helps me just to
provide the needed clock-signal without additional signal names.

Maybe it is (very) difficult to test such stuff in a strong language,
but on the other hand: What is the reason for forbidding clocking on a
variable? O.k. - you say, that the lack of the 'event attribute is the
breakpoint in the VHDL standard at the moment, but why is it impossible
(or just a bad idea) to add this feature?


Again: The intention of my question is just to get a clearer view to
VHDL. I stumbled over this problem, but had no idea, why this
well-readable construct is forbidden.

The problem is that variables are, by design, very light-weigh. They
only have an instant value and no concept of future values. When you
assign a new value, it gets assigned immediately. The moment you want
to introduce an 'event attribute for a variable, you'll need to
introduce a lot of additional complexity to the implementation.

In addition, it'd be not very clear how to define 'event on a
variable.

E.g.

process
begin
v_Variable := Value;
-- No event? Or only if Value is different from the
-- previous value of v_Variable?

v_Variable := v_Variable +1;
-- Is 'event now true?

v_Variable := v_Variable -1;
-- Is 'event now true? It's back to the value that it had at the
-- beginning of the process?

end process;

Since the variable can be given a number of values during one process
execution, it's not clear at all what 'event really means. Messy...

Tom

 

[Mike Treseler]

Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de> wrote in message news:<2jo9qjF13g6dhU1@uni-berlin.de>...

This was not the idea behind my question. I totally agree with you, that
signals and variables fit for different purposes.

But in my example the variable is just an utility. It helps me just to
provide the needed clock-signal without additional signal names.

The problem is that a synchronous process
uses its clock as a synchronizing input.
The clock is an egg. The process makes
only chickens, not eggs.
Especially not its own egg.

Maybe it is (very) difficult to test such stuff in a strong language,

The language is easy to try out using simulation.
It's the synthesis templates that can be rather arbitrary.

but on the other hand: What is the reason for forbidding clocking on a
variable? O.k. - you say, that the lack of the 'event attribute is the
breakpoint in the VHDL standard at the moment, but why is it impossible
(or just a bad idea) to add this feature?

If we ignore the chickens and eggs, the next
problem is one of putting a large luggage
rack on my sports car.

Again: The intention of my question is just to get a clearer view to
VHDL. I stumbled over this problem, but had no idea, why this
well-readable construct is forbidden.

The language and the synth subset is what it is.
There are lots of readable constructs that
violate syntax or synthesis rules.

Consider starting with the synchronous templates
that *always* work and are best supported by
synthesis tools, rather than discovering
them by trial and error.

Using variables whenever possible *inside* each
process will clean up the name space and add clarity.

Hehe ... this is *exactly* the reason, that led me to this problem.

The best process variables are intermediate stages
like, states, modes, buffers etc. Things that
other processes don't need directly.

-- Mike Treseler