Variables Synthesysable ?

Hi
Are VARIABLES in VHDL synthesisable ?
Thanks
EC

ec

ec wrote:
> Hi
> Are VARIABLES in VHDL synthesisable ?
> Thanks
> EC
>
>

Yes.


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

David Ashley

David Ashley wrote:
> ec wrote:
>
>>Hi
>>Are VARIABLES in VHDL synthesisable ?
>>Thanks
>>EC
>>
>>
>
>
> Yes.
>
>

I think you better handle them with care, it happened to me that they
turned out in a "removed instance" or something like this because not
carefully handled.
Variables schedule the value not at the end of the process as signals
do, but immediately, that is why you can have funny behaviour out of that.
The following processes have very different behaviour:

case1:

process (clk, nrst)
begin
if nrst = '0' then
A <= '0';
B <= '0';
elsif rising_edge (clk) then
A <= not A;
B <= A;
end if;
end process

case2:

process (clk, nrst)
variable B : std_logic;
begin
if nrst = '0' then
A <= '0';
B := '0';
elsif rising_edge (clk) then
A <= not A;
B := A;
end if;
end process

In case1 both A and B will be instantiated as FFs and B will be always
one clock cycle delayed in respect of A.
In the case2 B will be scheduled immediately and will be removed by the
compiler because is equivalent to A.
So watch what you are writing.

Cheers

Al


--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

Al <> writes:

> David Ashley wrote:
>> ec wrote:
>>
>>>Hi
>>>Are VARIABLES in VHDL synthesisable ?
>>>Thanks
>>> EC
>>>
>>>
>> Yes.
>>
>
> I think you better handle them with care, it happened to me that they
> turned out in a "removed instance" or something like this because not
> carefully handled.

[snippage]

It's all a question of care and getting used to. At my previous job,
we used variables almost exclusively and it worked very well. We did
17 tapeouts (all multi-million gate Ethernet switch designs) in around
4 years with only 2 designs that weren't right-first-time (neither of
the two errors were due to the coding style).

A typical pipelined design shows some of the differences you need to
adapt to:

signal pipe: std_logic_vector(3 downto 0);
process(Clk, Reset)
begin
if Reset = RESET then
pipe <= (others => '0');
elsif rising_edge(Clk) then
-- do your assignments to pipe(x) in arbitrary order:
outputs <= output_stage(p(4));
pipe(0) <= input_stage(inputs);
pipe(3) <= stage_3(p(2));
pipe(1) <= stage_1(p(0));
pipe(2) <= stage_2(p(1));
end if;
end process;

Alternate version using variables:
process(Clk, Reset)
variable pipe: std_logic_vector(3 downto 0);
begin
if Reset = RESET then
pipe := (others => '0');
elsif rising_edge(Clk) then
-- Assign output FFs (defined elsewhere)
outputs <= output_stage(p(3));
-- Assign each stage in REVERSE order:
p(3) := stage_3(p(2));
p(2) := stage_3(p(1));
p(1) := stage_3(p(0));
p(0) := input_stage(inputs);
endif;
end process;

That being said, we did see some significant improvements in
simulation speed and memory size by using variables rather than
signals. And no, I don't recall the numbers.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

Kai Harrekilde-Petersen

ec wrote:

> Are VARIABLES in VHDL synthesisable ?

Yes. Here are some example designs
and the resulting RTL schematics.
These use variables exclusively.

http://home.comcast.net/~mike_treseler/


-- Mike Treseler

Mike Treseler

Kai Harrekilde-Petersen wrote:


> That being said, we did see some significant improvements in
> simulation speed and memory size by using variables rather than
> signals. And no, I don't recall the numbers.

That's a pitty. Not even an order of magnitide? Was it more than 2X?

I'm just curious. The designs I'm dealing with almost exclusively use
signals. I do verifciation, using my own bus functional models. They
are written in a behavioral style with variables exclusively
(almost).

When profiling a simulation, some 90% of the time is spend in the DUT
and 10% in my verification models (both VHDL).

Clearly, the DUT is the part to be optimized to improve simulation
speed. That's why I would like to know if you could put a rough
estimate on the factor that may be gained by using variables.

--
Paul.
www.aimcom.nl
email address: switch x and s

Paul Uiterlinden

"Paul Uiterlinden" <> wrote in message
news:453bf097$0$10681$847b8a11@dreader22...
> Kai Harrekilde-Petersen wrote:
>
>
>> That being said, we did see some significant improvements in
>> simulation speed and memory size by using variables rather than
>> signals. And no, I don't recall the numbers.
>
> That's a pitty. Not even an order of magnitide? Was it more than 2X?
>
> I'm just curious. The designs I'm dealing with almost exclusively use
> signals. I do verifciation, using my own bus functional models. They
> are written in a behavioral style with variables exclusively
> (almost).

I made a test case which was an array of large counters and I recall
something on the order of about 10% improvement when using variables over
signals, definitely not orders of magnitude or even 2x. Although 10% is
'something' it wasn't enough (in my book) to get over the lack of visibility
of variables while you're debugging. By that I mean that you can't add a
variable to the Modelsim wave window to see the history of that variable
after the fact....which is something that I can do with signals with the
simple 'log -r /*' command at the start of sim.

When I hit an assert in my simulation I like to see what led up to that
event without having to restart the sim and having to guess at which
variables I'll need so I can add them to the wave window up front. You can
of course wave the signals that are on the entity to debug and that may be
enough to figure out what's wrong.

Others who use variables extensively cope with this handicap, so it's
something that you can get used to but if someone else has to pick up your
code and debug something they might not appreciate that handicap....It's
also hard to nail down how much less productive one is by having to mentally
keep track of what a variable is instead of being able to just display it.

So while on the one hand you can say that you can run 10% more test cases
with that 10% speedup it's hard to guesstimate at how much time you spend on
the mental gymnastics of keeping track of the variable(s). The difficulty
is also a function of how big and/or complicated the code is at the point
you're debugging. Whatever that time is, it would need to be subtracted
from the 10% (or whatever speedup you measure).

Bottom line though is benchmark it for yourself and see if it's worth it to
you. There are good reasons for using and good reasons for not using
variables.

KJ

KJ

ec wrote:
> Hi
> Are VARIABLES in VHDL synthesisable ?
> Thanks
> EC
>
>

Yes, VARIABLES are synthesisable ...
.... but what is a variable in hardware description ?
We know what is a Signal !

When possible, we use SIGNAL for RTL description (synthesisable code)!
When possible, We use VARIABLE for Test Bench description
(non-synthesisable code) -> the simulator will run much faster!

Laurent
www.amontec.com

Amontec, Larry

Amontec, Larry wrote:
> ec wrote:
> > Hi
> > Are VARIABLES in VHDL synthesisable ?
> > Thanks
> > EC
> >
>
> Yes, VARIABLES are synthesisable ...
> ... but what is a variable in hardware description ?
> We know what is a Signal !

I'm guessing that you really don't know what a signal is or you
wouldn't be asking "what is a variable in hardware description ?" and
implying that a variable is anything different than a signal in some
unspecifyed physical manner.

Variables and signals in the VHDL language have different behaviours in
the same way that 'and' and 'or' and 'xor' are VHDL operators that have
different behaviours. Just because they do different things doesn't
make one better or worse than the other....it simply means they do
different things.

>
> When possible, we use SIGNAL for RTL description (synthesisable code)!
> When possible, We use VARIABLE for Test Bench description
> (non-synthesisable code) -> the simulator will run much faster!
>
If you've measured faster sim times with variables then two questions
come to mind from your two statements....
1. Why do you use signals in your RTL (since it would be faster with
variables)
2. How much faster does it run? (I'm guessing that it probably wasn't
enough to warrant an exclamation point, I measured around 10% on a test
case, what have you seen?)

KJ

KJ

Paul Uiterlinden wrote:

>> That being said, we did see some significant improvements in
>> simulation speed and memory size by using variables rather than
>> signals. And no, I don't recall the numbers.
>
> That's a pity. Not even an order of magnitide? Was it more than 2X?

What if it were 2X?
I wouldn't rewrite working code for that.

The reason I use variables is that they
enable a procedural coding style that
produces working synthesis code faster for me.

I declare variable data structures where I used to generate processes.
I declare functions where I once used asynch processes.
All sim values are current.
The the timing portion of my synthesis description ...

begin -- process template
if reset = '1' then
init_regs;
elsif rising_edge(clock) then
update_regs;
end if;
update_ports;
end process;

.... is separate from my logic description,
and is *always* the same.

These are the advantages for me of using variables.
But this is a different way of looking at logic description,
not just a simple substitution of variables for signals.

> Clearly, the DUT is the part to be optimized to improve simulation
> speed. That's why I would like to know if you could put a rough
> estimate on the factor that may be gained by using variables.

My gut estimate is 2x for my signal-less design entities.
To prove it, I would have to rewrite a design in
a style that I have not used for years. This
doesn't sound like much fun and even if I held
this proof, it alone is not a good enough reason
to change design styles.

-- Mike Treseler

Mike Treseler