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