Signals and variables, concurrent and sequential assignments

[Taras_96]

Hi everyone,

I've heard a number of theories about when to use signal assignments or
variable assignments for RTL code, and when to use concurrent or
sequential VHDL. Does anyone have an opinion on the following 'rules
of thumb'?

1) Model combinational logic within a process with a full sensitivity
list using variable assignments

Coming from a Verilog background, I was told to model combinational
logic, using an always@(/*AUTOSENSE*/) procedural block with blocking
assignments. The VHDL equivalent of this is using a process with a
full sensitivty list, and using variable assignments. However, the
variables are only visible from within the process, and thus it is
difficult to get the results out to a sequential block (clocked
process) bit of code.

process(...)
variable sum;
begin
sum := a + b; //how to get this to a process that is clocked?!
end process;

Once way of getting around this is by assigning the variable to a
signal once all combinational logic has finished, however, this breaks
the general rule of not mixing blocking and non-blocking (in Verilog),
or signal and variable (in VHDL) assignments, and also seems
cumbersome. One alternative is to combine the combinational and logic
parts - discussed further below.

"In general:

sequential blocks use non-blocking <=
combinational blocks use blocking ="
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/6c57aee8293cd934/32fd131568d5e217

"Use non blocking assignments within sequential (clocked) blocks:"
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/d4db6011c11acbf7/

"If it's a reg (i.e. it's being assigned in an always block or an
initial block) and you are trying to design synchronous sequential
logic (flip-flops), then use the non-blocking procedural assignment
(<=).
4. If it's a reg (i.e. it's being assigned in an always block or an
initial block) and you are trying to design combinatorial logic, then
use the blocking signal assignment."
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/d4db6011c11acbf7/e750bbf691c67e5e

Another solution is to migrate all combinational code into the
concurrent section of VHDL - but why then, in Verilog, would you write
combinational code in procedural blocks rather than using assign
statements? I came across the following post discussing the benefits
in Verilog:

"If you wanted the latch or combinational logic. I would decide which
construct to use based on the other features available in continuous
assignments vs. procedural assignments. These are delays and
strengths. You can give strengths to wires and not regs (so you would
use the continuous assignment if you wanted this feature)."
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/dca48606454e48b5/5c87510daa47030d

Is there any other disadvantages in writing combinational code in
concurrent VHDL - perhaps code clarity? The disadvantage mentioned
above is not really relevant in RTL.

2) Don't mix signal and variable assignments (blocking and
non-blocking)

As mentioned above, one solution is to introduce all the combinational
logic into a clocked process using variable assignments, and then clock
them using signal assignments. This is also suggested in another
thread:

"This is the conventional wisdom. I disagree. I prefer to use signal
(non-blocking) assignments _only_ for the purpose of transferring a
variable (register) value to a port or to another process."
http://groups-beta.google.com/group/comp.lang.vhdl/msg/7a377484e81b23e9

On the contrary:

"Try looking at a complex always block which uses a mixture of
blocking and non-blocking and it can be a real challange to decipher
what is intended even with a good understanding of the language."
http://groups-beta.google.com/group/comp.lang.verilog/msg/c7a6c4f0df5676eb

"In summary then, one should use non-blocking assignments to
synchronous>signals and blocking assignments in combinational
constructs. Don't mix them together."
http://groups-beta.google.com/group/comp.lang.verilog/msg/bc07296b9fb0cfe1

So in summary:

If you are to write combinational logic in a process using variable
assignments, thus following rule 1, how do you get the new values to
the clocked process? One solution is to write all combinational code
in concurrent VHDL - are there any disadvantages in this? Another
solution is to combine the combinational and sequential sections of
code, but this seems to go against conventional wisdom.

I'm sure there are many opinions out there, and I'm interested to see
what people think.

Thanks

Taras

 

[Taras_96]

Hi Mike

Your 'rule of thumb' works fine - I've implemented a few simple designs
already using different assignment conventions, and yours seems to give
the clearest code. Just wondering if any of the experts out there have
any comments/experiences on any conventions they might have used. As I
said, using my judgement your convention seems to give the clearest
code, but I'm not an expert (as you can tell by my posts) and thus I
don't trust my own judgements .

Taras

 

[Taras_96]

Thanks everyone for your suggestions - It's been really helpful

Taras


Taras_96 wrote:

Hi everyone,

I've heard a number of theories about when to use signal assignments
or
variable assignments for RTL code, and when to use concurrent or
sequential VHDL. Does anyone have an opinion on the following 'rules
of thumb'?

1) Model combinational logic within a process with a full sensitivity
list using variable assignments

Coming from a Verilog background, I was told to model combinational
logic, using an always@(/*AUTOSENSE*/) procedural block with blocking
assignments. The VHDL equivalent of this is using a process with a
full sensitivty list, and using variable assignments. However, the
variables are only visible from within the process, and thus it is
difficult to get the results out to a sequential block (clocked
process) bit of code.

process(...)
variable sum;
begin
sum := a + b; //how to get this to a process that is clocked?!
end process;

Once way of getting around this is by assigning the variable to a
signal once all combinational logic has finished, however, this
breaks
the general rule of not mixing blocking and non-blocking (in
Verilog),
or signal and variable (in VHDL) assignments, and also seems
cumbersome. One alternative is to combine the combinational and
logic
parts - discussed further below.

"In general:

sequential blocks use non-blocking <=
combinational blocks use blocking ="

http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/6c57aee8293cd934/32fd131568d5e217

"Use non blocking assignments within sequential (clocked) blocks:"

http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/d4db6011c11acbf7/

"If it's a reg (i.e. it's being assigned in an always block or an
initial block) and you are trying to design synchronous sequential
logic (flip-flops), then use the non-blocking procedural assignment
(<=).
4. If it's a reg (i.e. it's being assigned in an always block or an
initial block) and you are trying to design combinatorial logic,
then
use the blocking signal assignment."

http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/d4db6011c11acbf7/e750bbf691c67e5e

Another solution is to migrate all combinational code into the
concurrent section of VHDL - but why then, in Verilog, would you
write
combinational code in procedural blocks rather than using assign
statements? I came across the following post discussing the benefits
in Verilog:

"If you wanted the latch or combinational logic. I would decide
which
construct to use based on the other features available in continuous
assignments vs. procedural assignments. These are delays and
strengths. You can give strengths to wires and not regs (so you
would
use the continuous assignment if you wanted this feature)."

http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/dca48606454e48b5/5c87510daa47030d

Is there any other disadvantages in writing combinational code in
concurrent VHDL - perhaps code clarity? The disadvantage mentioned
above is not really relevant in RTL.

2) Don't mix signal and variable assignments (blocking and
non-blocking)

As mentioned above, one solution is to introduce all the
combinational
logic into a clocked process using variable assignments, and then
clock
them using signal assignments. This is also suggested in another
thread:

"This is the conventional wisdom. I disagree. I prefer to use signal
(non-blocking) assignments _only_ for the purpose of transferring a
variable (register) value to a port or to another process."

http://groups-beta.google.com/group/comp.lang.vhdl/msg/7a377484e81b23e9

On the contrary:

"Try looking at a complex always block which uses a mixture of
blocking and non-blocking and it can be a real challange to decipher
what is intended even with a good understanding of the language."

http://groups-beta.google.com/group/comp.lang.verilog/msg/c7a6c4f0df5676eb

"In summary then, one should use non-blocking assignments to
synchronous>signals and blocking assignments in combinational
constructs. Don't mix them together."

http://groups-beta.google.com/group/comp.lang.verilog/msg/bc07296b9fb0cfe1

So in summary:

If you are to write combinational logic in a process using variable
assignments, thus following rule 1, how do you get the new values to
the clocked process? One solution is to write all combinational code
in concurrent VHDL - are there any disadvantages in this? Another
solution is to combine the combinational and sequential sections of
code, but this seems to go against conventional wisdom.

I'm sure there are many opinions out there, and I'm interested to see
what people think.

Thanks

Taras