E
ec
Guest
Hi
Are VARIABLES in VHDL synthesisable ?
Thanks
EC
Are VARIABLES in VHDL synthesisable ?
Thanks
EC
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
David Ashley
Guest
ec wrote:
--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Yes.Hi
Are VARIABLES in VHDL synthesisable ?
Thanks
EC
--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
A
Al
Guest
David Ashley wrote:
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
I think you better handle them with care, it happened to me that theyec wrote:
Hi
Are VARIABLES in VHDL synthesisable ?
Thanks
EC
Yes.
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
K
Kai Harrekilde-Petersen
Guest
Al <alessandro.basili@cern.ch> writes:
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>
[snippage]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.
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>
M
Mike Treseler
Guest
ec wrote:
and the resulting RTL schematics.
These use variables exclusively.
http://home.comcast.net/~mike_treseler/
-- Mike Treseler
Yes. Here are some example designsAre VARIABLES in VHDL synthesisable ?
and the resulting RTL schematics.
These use variables exclusively.
http://home.comcast.net/~mike_treseler/
-- Mike Treseler
P
Paul Uiterlinden
Guest
Kai Harrekilde-Petersen wrote:
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
That's a pitty. Not even an order of magnitide? Was it more than 2X?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.
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
K
KJ
Guest
"Paul Uiterlinden" <paulu@sx4all.nl> wrote in message
news:453bf097$0$10681$847b8a11@dreader22...
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
news:453bf097$0$10681$847b8a11@dreader22...
I made a test case which was an array of large counters and I recallKai 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).
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
A
Amontec, Larry
Guest
ec wrote:
.... 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
Yes, VARIABLES are synthesisable ...Hi
Are VARIABLES in VHDL synthesisable ?
Thanks
EC
.... 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
K
KJ
Guest
Amontec, Larry wrote:
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.
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
I'm guessing that you really don't know what a signal is or youec 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 ! ;-)
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.
come to mind from your two statements....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
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
M
Mike Treseler
Guest
Paul Uiterlinden wrote:
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.
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
What if it were 2X?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?
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.
My gut estimate is 2x for my signal-less design entities.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.
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
M
Mike Treseler
Guest
KJ wrote:
log /top/dut/myproc/*
Saves all variable history for a single process uut.
I agree that speed is an insufficient reason to
take on variables, but an unfamiliar command
to log waves is not an insurmountable roadblock either.
This a personal preference, and there is no point
in my trying to prove or disprove it.
-- Mike Treseler
Note thatBy 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.
log /top/dut/myproc/*
Saves all variable history for a single process uut.
I agree that speed is an insufficient reason to
take on variables, but an unfamiliar command
to log waves is not an insurmountable roadblock either.
The most significant value for me is clarity of design intent.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.
This a personal preference, and there is no point
in my trying to prove or disprove it.
-- Mike Treseler
K
KJ
Guest
Mike Treseler wrote:
that you can't use that command (or any other) to log all variables in
a design unless you go through and list all of the processes. There is
no equivalent to "log -r /*" to log all variables in a design unit that
is being simulated. The only way around that is to get the full
hierarchical list of all processes and make up a .do file (and then
maintain that as the design hierarchy evolves) to log that activity.
For any design verfication testing simulation other than the lowest
unit levels you most likely don't know ahead of time which process to
log the variables on for the assert that is going to fail once you
finally do a 'run'. Once the assert hits is when the debug starts and
the lack of variable history is at least some bit of a hinderance.
I don't doubt that you can (and do) debug using the signals that you
have available from the entity but I would hazard to guess that if the
variable history was there you'd make use of that too and probably
debug a bit faster (i.e. more productive during the particular task of
debugging).
signals or variables or both depending on the particular design.
sim speed (or whatever metric they thought it was an improvement on) to
simply benchmark and test it on a small scale and try it out for
themselves.....and pointed out my recollection of what I seem to recall
for sim speed improvement when I did that benchmarking myself and one
of the drawbacks that exists when using variables. They can take that
tiny tidbit of information and consider or discard that as they wish.
KJ
KJ wrote:
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.
Note that
log /top/dut/myproc/*
Saves all variable history for a single process uut.
"Single process uut" is the key restriction.
It's not an unfamiliar command that needs to be mastered, it's the factI agree that speed is an insufficient reason to
take on variables, but an unfamiliar command
to log waves is not an insurmountable roadblock either.
that you can't use that command (or any other) to log all variables in
a design unless you go through and list all of the processes. There is
no equivalent to "log -r /*" to log all variables in a design unit that
is being simulated. The only way around that is to get the full
hierarchical list of all processes and make up a .do file (and then
maintain that as the design hierarchy evolves) to log that activity.
For any design verfication testing simulation other than the lowest
unit levels you most likely don't know ahead of time which process to
log the variables on for the assert that is going to fail once you
finally do a 'run'. Once the assert hits is when the debug starts and
the lack of variable history is at least some bit of a hinderance.
I don't doubt that you can (and do) debug using the signals that you
have available from the entity but I would hazard to guess that if the
variable history was there you'd make use of that too and probably
debug a bit faster (i.e. more productive during the particular task of
debugging).
function of the person writing the code than whether that person usesBottom 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.
The most significant value for me is clarity of design intent.
I agree, and I find that 'clarity of design intent' is much more a
signals or variables or both depending on the particular design.
poster that if they thought it might be a useful technique because ofThis a personal preference, and there is no point
in my trying to prove or disprove it.
Never said that 'you' should. I was simply suggesting to the previous
sim speed (or whatever metric they thought it was an improvement on) to
simply benchmark and test it on a small scale and try it out for
themselves.....and pointed out my recollection of what I seem to recall
for sim speed improvement when I did that benchmarking myself and one
of the drawbacks that exists when using variables. They can take that
tiny tidbit of information and consider or discard that as they wish.
KJ
P
Paul Uiterlinden
Guest
KJ wrote:
Thanks for your answer. I agree 10% is not worth the hassle. 2X
perhaps would, but the only way to find out is doing a design twice.
And that's definitely not do-able.
Although, proving that it can be done and gaining simulation speed
would give me a nice stick to beat the designer and let him think
about his coding style... ;-)
--
Paul.
www.aimcom.nl
email address: switch x and s
KJ,"Paul Uiterlinden" <paulu@sx4all.nl> 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).
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.
Thanks for your answer. I agree 10% is not worth the hassle. 2X
perhaps would, but the only way to find out is doing a design twice.
And that's definitely not do-able.
Although, proving that it can be done and gaining simulation speed
would give me a nice stick to beat the designer and let him think
about his coding style... ;-)
--
Paul.
www.aimcom.nl
email address: switch x and s
P
Paul Uiterlinden
Guest
Mike Treseler wrote:
styles.
Having said that, there is also Equivalence Checking that allows you
to chance existing code and prove that the functionality has not
changed. I have done that in the past. Still you have to be careful
to not forget the synthesis part and make a mess of the synthesis
result speed-wise.
would justify at least some thought about it, in my opinion.
--
Paul.
www.aimcom.nl
email address: switch x and s
No, but it would give a reason to talk with the designers about codingPaul 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.
styles.
Having said that, there is also Equivalence Checking that allows you
to chance existing code and prove that the functionality has not
changed. I have done that in the past. Still you have to be careful
to not forget the synthesis part and make a mess of the synthesis
result speed-wise.
It is risky to change coding style, I agree. A factor of 2X howeverClearly, 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.
would justify at least some thought about it, in my opinion.
--
Paul.
www.aimcom.nl
email address: switch x and s
K
Kai Harrekilde-Petersen
Guest
Paul Uiterlinden <paulu@sx4all.nl> writes:
results from it. It was generally combined with the procedural coding
style that Mike wrote about.
determine where the bottleneck is.
In many of the Ethernet switch designs, the major part (>50%!) of the
simulation time was spent in the CRC32 calculations, which used some
very neat recursively defined XOR_tree() functions which yielded
perfectly balanced binary XOR-gate trees directly during the synthesis
elaboration, but were simulation time hogs.
As I recall, this was in particular a problem with designs with 10GbE
ports which used a 64-bit wide CRC32, while the 8-bit parallel
computations for the 1GbE ports wasn't a real issue even when there
were 24+ ports.
Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
Alas, I did not do those timed tests at the time, but only used theKai 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?
results from it. It was generally combined with the procedural coding
style that Mike wrote about.
In my experience, you need to profile your DUT code and look at it toWhen 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.
determine where the bottleneck is.
In many of the Ethernet switch designs, the major part (>50%!) of the
simulation time was spent in the CRC32 calculations, which used some
very neat recursively defined XOR_tree() functions which yielded
perfectly balanced binary XOR-gate trees directly during the synthesis
elaboration, but were simulation time hogs.
As I recall, this was in particular a problem with designs with 10GbE
ports which used a 64-bit wide CRC32, while the 8-bit parallel
computations for the 1GbE ports wasn't a real issue even when there
were 24+ ports.
Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
P
Paul Uiterlinden
Guest
Kai Harrekilde-Petersen wrote:
designs that show an evenly spread cpu time consumption. An
indication of an optimal design, or showing that the design is
generally slow. Who is to say?
recursive function, consuming a disproportional part of cpu time
during simulation. And to make it worse: switching on code coverage
broke the function. Clearly a simulator bug, but the fastest way to
get around it was to flatten the function. The simulation ran faster,
code coverage worked and synthesis result was not affected after all.
--
Paul.
www.aimcom.nl
email address: switch x and s
Agreed, but not always you will find a bottle neck. There are thoseIn my experience, you need to profile your DUT code and look at it
to determine where the bottleneck is.
designs that show an evenly spread cpu time consumption. An
indication of an optimal design, or showing that the design is
generally slow. Who is to say?
I've even seen the same with a simple parity generator. That too was aIn many of the Ethernet switch designs, the major part (>50%!) of
the simulation time was spent in the CRC32 calculations, which used
some very neat recursively defined XOR_tree() functions which
yielded perfectly balanced binary XOR-gate trees directly during the
synthesis elaboration, but were simulation time hogs.
recursive function, consuming a disproportional part of cpu time
during simulation. And to make it worse: switching on code coverage
broke the function. Clearly a simulator bug, but the fastest way to
get around it was to flatten the function. The simulation ran faster,
code coverage worked and synthesis result was not affected after all.
--
Paul.
www.aimcom.nl
email address: switch x and s
A
Amontec, Larry
Guest
KJ wrote:
SIGNALs are used to interact between process!
description. Multiple concurrent PROCESS with multiple SIGNALs for
interacting between the PROCESS ! The only objective is to write many
smallest process (This is the better way to write re-usable VHDL code).
In this way, all VARIABLEs will be gone. If you still have VARIABLEs,
you have to re-think about your methodology and design concept!
For a test bench description, it is more more easy to think ONE process,
as one processor with multiple VARIABLEs and FUNCTIONs !
application as FFT accelerator ... no simple as a Shift register test
bench !
andAmontec, 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 ?"
KJ, are you a C programmer talking about VHDL !
VARIABLEs can only be used in the process itself!implying that a variable is anything different than a signal in some
unspecifyed physical manner.
The SIGNAL and VARIABLE are really VERY different !
SIGNALs are used to interact between process!
VHDL RTL description has the advantage to provide TRUE multi-processingVariables 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)
RTL description concept is much more different than Test Bench concept.
description. Multiple concurrent PROCESS with multiple SIGNALs for
interacting between the PROCESS ! The only objective is to write many
smallest process (This is the better way to write re-usable VHDL code).
In this way, all VARIABLEs will be gone. If you still have VARIABLEs,
you have to re-think about your methodology and design concept!
For a test bench description, it is more more easy to think ONE process,
as one processor with multiple VARIABLEs and FUNCTIONs !
Yes, but this is for a complex PCI core testbench + high level2. 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?)
50% to 70%
application as FFT accelerator ... no simple as a Shift register test
bench !
www.amontec.comKJ
Laurent Gauch
K
KJ
Guest
Amontec, Larry wrote:
before there was a VHDL or Verilog language standard. As a college
intern I was even doing some PLD programming before JEDEC had
standardized on a fusemap file and Data I/O had yet to come out with
Abel, Minc's PLDesigner did not yet exist. But I also know C and a bit
of C++ and a few other languages also.
variables were somehow not as good as signals or something since you
didn't know what the 'hardware description' of a variable is. My point
is that variables and signals result in the same 'hardware
description'. Inside an FPGA signals and variables would both be
physical metal interconnect and pass transistor programming (for those
that don't get optomized away). Just because they are used differently
doesn't affect that definition, it simply affects how you actually
write your code.
You can write code, making extensive use of variables, and never use
any signals other than the inputs and outputs of the entities
themselves OR you could write code that never uses a single variable
but uses signals everywhere (or anything between those extremes). Both
approaches can result in the exact same synthesized result....so now
tell me how is the 'hardware description' of a variable any different
than that of a signal?
parts on the board are very much RTL like. In fact, by gross count of
parts on the board, most of those parts would probably be considered
RTL. The more complicated ones (like processors and more 'difficult'
functions) are not and could not be synthesized by any present or
future tool in this decade. All of those parts are elements of the
'testbench concept'. In any case, it's a mix.
to write maintainable re-usable code.
My opinion is that processes are somewhat analogous to paragraphs in a
chapter. They should encapsulate a specific thought and if that means
one signal or a dozen that's OK. My fuzzy metric is that a process
should fit on a screen. That way the entire process can be studied,
debugged and understood at a glance without having to flip back and
forth. I tend to group signals within a process by how much those
signals depend on the same set of inputs. Again, that minimizes the
amount of flipping back and forth. I'll use variables within processes
where it enhances readability to do so. That's the general idea, for
how I come out with code that is readable and understandable.
I don't have hard fast rules such as 'only one process per entity',
'minimum sized process' or 'minimum lines of code', 'no variables'
since I haven't found any of these to be the most productive way to get
to a functioning design. There are elements of each that are useful
and I'll use them in the way I find to be most productive for myself
while also not trying to come up with something that may be a chore for
someone else unfamiliar with the design to pick up later.
extensively than I do.
what that function is whether it is part of a testbench or not. In
fact, even in simple testbench cases I tend to have multiple processes;
the simplest being I'll typically have a process to generate stimulus
input to the thing that I'm testing and another process to validate
that the outputs are correct. At times I've been able to combine them
into a single process but I find that to be more the exception than the
general case.
style but using signals and measured a 50-70% speed improvement with
variables? If so, then besides seeing more of a speedup than I saw, it
would seem that you would have a stronger motivation to use variables
because of the larger speedup....so why aren't you?
Also, I didn't say my benchmark test was a simple shift register. The
benchmark was an entity that used a generate statement to generate a
large block of processes (to emulate the large number of processes
within a typical design) where each process implemented a counter using
either a signal or a variable. Instead of a counter I could have
chosen any other logical function as well and benchmarked that. I
suspect that my results would be the same (i.e. that variables were
about 10% faster than signals)...but perhaps not.
KJ
boards and writing logic for all sorts of programmable devices evenYes, 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 ?"
KJ, are you a C programmer talking about VHDL !
Absolutely not. I'm a professional engineer who has been designing
before there was a VHDL or Verilog language standard. As a college
intern I was even doing some PLD programming before JEDEC had
standardized on a fusemap file and Data I/O had yet to come out with
Abel, Minc's PLDesigner did not yet exist. But I also know C and a bit
of C++ and a few other languages also.
hardware description ?" with the implicit (to me) assumption thatand
implying that a variable is anything different than a signal in some
unspecifyed physical manner.
The SIGNAL and VARIABLE are really VERY different !
VARIABLEs can only be used in the process itself!
SIGNALs are used to interact between process!
What started this was your statement "... but what is a variable in
variables were somehow not as good as signals or something since you
didn't know what the 'hardware description' of a variable is. My point
is that variables and signals result in the same 'hardware
description'. Inside an FPGA signals and variables would both be
physical metal interconnect and pass transistor programming (for those
that don't get optomized away). Just because they are used differently
doesn't affect that definition, it simply affects how you actually
write your code.
You can write code, making extensive use of variables, and never use
any signals other than the inputs and outputs of the entities
themselves OR you could write code that never uses a single variable
but uses signals everywhere (or anything between those extremes). Both
approaches can result in the exact same synthesized result....so now
tell me how is the 'hardware description' of a variable any different
than that of a signal?
PCBA that it is going to be a part of and the models for some of thoseWhen 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)
RTL description concept is much more different than Test Bench concept.
Not always. Generally I surround my FPGA design with a model of the
parts on the board are very much RTL like. In fact, by gross count of
parts on the board, most of those parts would probably be considered
RTL. The more complicated ones (like processors and more 'difficult'
functions) are not and could not be synthesized by any present or
future tool in this decade. All of those parts are elements of the
'testbench concept'. In any case, it's a mix.
VHDL RTL description has the advantage to provide TRUE multi-processing
description.
Strike the word 'RTL' from the previous sentence and I agree.
would be to put one signal within each process....most likely not a wayMultiple concurrent PROCESS with multiple SIGNALs for
interacting between the PROCESS ! The only objective is to write many
smallest process (This is the better way to write re-usable VHDL code).
That's your opinion and you're entitled to it. The 'smallest process'
to write maintainable re-usable code.
My opinion is that processes are somewhat analogous to paragraphs in a
chapter. They should encapsulate a specific thought and if that means
one signal or a dozen that's OK. My fuzzy metric is that a process
should fit on a screen. That way the entire process can be studied,
debugged and understood at a glance without having to flip back and
forth. I tend to group signals within a process by how much those
signals depend on the same set of inputs. Again, that minimizes the
amount of flipping back and forth. I'll use variables within processes
where it enhances readability to do so. That's the general idea, for
how I come out with code that is readable and understandable.
I don't have hard fast rules such as 'only one process per entity',
'minimum sized process' or 'minimum lines of code', 'no variables'
since I haven't found any of these to be the most productive way to get
to a functioning design. There are elements of each that are useful
and I'll use them in the way I find to be most productive for myself
while also not trying to come up with something that may be a chore for
someone else unfamiliar with the design to pick up later.
In this way, all VARIABLEs will be gone
So what? Do you get charged by how many variables you use?
Tressler and many others that follow his lead and use variables moreIf you still have VARIABLEs,
you have to re-think about your methodology and design concept!
I don't agree....and I think you'd get a bigger disagree from Mike
extensively than I do.
is 'easier to think of a function as one process' or not depends onFor a test bench description, it is more more easy to think ONE process,
as one processor with multiple VARIABLEs and FUNCTIONs !
You really like excamation points don't you? In any case, whether it
what that function is whether it is part of a testbench or not. In
fact, even in simple testbench cases I tend to have multiple processes;
the simplest being I'll typically have a process to generate stimulus
input to the thing that I'm testing and another process to validate
that the outputs are correct. At times I've been able to combine them
into a single process but I find that to be more the exception than the
general case.
thing, one written with variables and the other with the same coding2. 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?)
50% to 70%
Yes, but this is for a complex PCI core testbench + high level
application as FFT accelerator ... no simple as a Shift register test
bench !
So are you saying that you have two equivalent descriptions of the same
style but using signals and measured a 50-70% speed improvement with
variables? If so, then besides seeing more of a speedup than I saw, it
would seem that you would have a stronger motivation to use variables
because of the larger speedup....so why aren't you?
Also, I didn't say my benchmark test was a simple shift register. The
benchmark was an entity that used a generate statement to generate a
large block of processes (to emulate the large number of processes
within a typical design) where each process implemented a counter using
either a signal or a variable. Instead of a counter I could have
chosen any other logical function as well and benchmarked that. I
suspect that my results would be the same (i.e. that variables were
about 10% faster than signals)...but perhaps not.
KJ
M
Mike Treseler
Guest
Amontec, Larry wrote:
These things happen.
Hardware is inferred from assignments.
Variables and signals alone have no physical significance.
In a synchronous process either
n_v := n_v + 1;
or
n_s <= n_s + 1;
will infer a counter as long
as n affects the right side of
a port assignment.
I can synthesize an entity without signals.
The only thing that variable can't do
is participate in a port map.
-- Mike Treseler
I'm also a C programmer talking about VHDL.KJ, are you a C programmer talking about VHDL !
These things happen.
The significant difference is assignment delay.and
implying that a variable is anything different than a signal in some
unspecifyed physical manner.
Hardware is inferred from assignments.
Variables and signals alone have no physical significance.
In a synchronous process either
n_v := n_v + 1;
or
n_s <= n_s + 1;
will infer a counter as long
as n affects the right side of
a port assignment.
I can synthesize an entity without signals.
The only thing that variable can't do
is participate in a port map.
-- Mike Treseler