Variable vs. Signal on indexing

[Jonathan Bromley]

On 19 Jan 2007 18:28:25 -0800, mikegurche@yahoo.com wrote:

Jonathan Bromley wrote:
[a rant about why Verilog RTL code ought to look

more like VHDL RTL code]

Jonathan,

The guidelines I metioned is from
"Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill"
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
which is voted best paper in SNUG2000.

You'll find the same guidelines elsewhere too; for example, in the
OpenMORE coding standard. That doesn't automatically make
the advice correct, though.

Cliff's discussion of the behaviour of NBA and races is spot-on
(and, indeed, I often point my own trainees to that paper), but
please read his section 13.0 rather carefully. He correctly
dismisses his example 25 (mixed blocking and nonblocking assignment
to the same variable) as being non-synthesisable. But he also
dismisses his example 24 without justification, despite correctly
saying that the example synthesises and simulates in exactly the
desired way! On this point (and, note, on only this point)
I disagree strongly with his paper's conclusions. His example
24 is a perfectly sensible use of blocking assignment to local
variables, and represents a coding style that I would strongly
encourage.

I imagine that Cliff's reasoning here is that of a trainer who
wishes to be conservative - note that Jim Lewis uses exactly
the same reasoning when avoiding discussion of variables in
his VHDL training classes. We, similarly, avoid the use of
variables (and locals in Verilog) in our introductory training,
but we slip in the possibility as soon as we are able.
We believe it gives users a powerful additional tool for
expressing their design intent.

It will be nice if you can provide some links for other guidelines.

There is plenty of guidance in this thread. However, I'm not aware
of the idea being published as "guidelines".
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:12r2rflpap2gi52@corp.supernews.com...

Andy,
OK, I see your point, but did you see mine? If the majority of
synthesis vendors are already coming to a common ground, is there a
need for a published standard, or to restrict oneself to it?

Its value is more obvious when you buy IP. If they certify it
to a standard and your tool supports that standard, then it will
work.

Besides IP, the synthesis tools vendors themselves all claim to meet a

standard and generally they don't. As a user of those tools, I'm
technically in a much stronger position to complain about the lack of
adherance when I can refer back to the standard that they claim support for
that their tool doesn't actually support. However, having said that I can
also say that when they hear me say "Modelsim and Quartus have no problem
with this code" it seems to get their attention faster than if I try to
refer to a paragraph in a standard.....but in the final analysis, it is the
existence of a standard that provides that fundamental underpinning of
support for why the competition correctly implements something that they can
not.

Kevin Jennings

 

[KJ]

You have more faith on synthesis software than I do

Mike G.

Unless the source code you write is only in terms of hooking up 4-6 input

LUTs, flip flops, small memory elements (and the various new hard features
that keep popping up with each new generation of devices), then you have a
lot more faith in synthesis software than you may realize.

You may not feel comfortable with the coding style, but if it succintly
describes the function and is maintainable (both are rather nebulous metrics
though) than, if nothing else, this is raising your awareness of other ways
of describing functionality and that is a 'good thing' even if you have no
immediate plans to adopt it.

Kevin Jennings

 

[Jan Decaluwe]

mikegurche@yahoo.com wrote:

I write codes in both VHDL and Verilog. The variable and signal in a
VHDL process roughly translate to the non-blocking and blocking
statements in Verilog. Almost all Verilog coding guidelines recommend
not to mix the non-blocking and blocking statements. It will be much
easier to convert codes between the two languages if VHDL code follows
the same guideline.

Anyone wish to comment from this perspective?

Sure

That is a bad guideline and bad guidelines should be ignored. Here are
my reasons.

First, Cummings created this guideline without any proper
justification. He
simply labels the coding style *a priori* as poor and adds: "Although
this
will work, the author does not recommend it." See the paper. In other
words,
don't do this because I tell you so. I find that unacceptable.

More importantly, there *are* important technical arguments for giving
variable semantics (blocking assignments) a prominent position in RTL
design. It's not just a neutral choice of style. Many relevant design
problems
that are cumbersome and hard to solve without variables, have elegant
solutions with them.

I have treated this subject in some more detail using a practical
example here:
http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2
(Although this page is about MyHDL, it contains (converted) equivalent
Verilog for your review.)

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

[Mike Treseler]

Jan Decaluwe wrote:

I have treated this subject in some more detail using a practical
example here:
http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2
(Although this page is about MyHDL, it contains (converted) equivalent
Verilog for your review.)

Good example. Thanks for the posting.
Quartus synthesis accepts jc2_alt.v with no errors
and sees it like this:

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

-- Mike Treseler

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:12qvc944brcb0c2@corp.supernews.com...

Jan,
There are enough issues with design, verification,
and HDL coding that new users must deal with and
master. As a result, I don't think a new user
needs to bother with variables in an RTL design.

Snip
Note I state my guideline as a "recommendation" and not a rule.

Recommendation:
Avoid using variables for RTL design on your first couple of projects.

This way those who already have FPGA design skills or are
sharp would feel free to violate it.

Secondly, consider trying to explain variable versus signal
semantics to a junior software engineer. What will be the most
difficult? Obviously, variables are the easy stuff. In contrast,
signals are complex objects with pretty complicated semantics,
requiring a considerable amount of learning. Still, many
hardware designers have a tendency to label signals as
"basic" and variables as "advanced". It should really be the
other way around. Odd, isn'it?

To some degree, I agree. Especially for verification.
Here are my notes for RTL creation:

RTL behavior in a clocked process:
Signal assignment: Always implies* a register
Variable assignment:
Implies a register if variable read before written.
Alternately implies a register if variable has a life time.
Implies combinational logic when always written before read.

*Registers are created for all implied registers unless there
is a redundancy that can be merged with another register.


RTL behavior in a combinational process:
Signal assignment:
Must get a value for every hardware execution of the
process or it will create a latch.
Recommendation: do not read a value that is written in the same
process, otherwise, signal must be on sensitivity list and process
must iterate.

Variable assignment:
Implies combinational logic when always written before read.
If read before written then error
Must get a value for every hardware execution of the
process or it will create a latch.

For design creation there are alot of details that must
be managed. As you pare this down to RTL creation,
you must master signals, but for most applications you
don't need to use variables - hence you
don't need to learn the additional hardware implications.

Actually, if you focus on correct function first and foremost I suspect
you'll be up and running faster. The 'implications' of whether you use
signals or variables are rather transparent....i.e. who cares if the
function being implemented is correct? To the absolute newbie, variables
are easier to grasp since you can step through the code and see your
variable getting updated. with signals you don't get that feedback, so in
many cases the learning curve there can be steeper.

The more important design considerations inside a process are things like
understanding what hardware can be generated by seemingly simple looking
constructs....like if (a=b) then....else .... end if, where a and b are, say
16 bit signals...oh and that if statement is buried down 5 levels of if
statements all encapsulated inside a case statement. Or even c <= a /
b;....gee this won't run at 200 MHz? Clocking on multiple edges or even on
multiple signals. What is this 'combinatorial loop' warning thingy? What's
a latch? Stuff like that are the kinds of things that 'simulate just fine'
but either don't synthesize or can only operate in the KHz range.

Whether one uses variables or signals to accomplish the task of implementing
a given function generally just doesn't matter much in getting the function
working properly at the intended speed but it can make a difference in how
maintainable that code ends up being. So after designing for function and
performance, having code that is clean, maintainable and supportable is the
next major item even though none of those things are directly measurable
metrics.

Kevin Jennings

 

[Jan Decaluwe]

Jim Lewis wrote:

Exciting . Sometimes registered, sometimes combo logic.


A brave new world And much more difficult to do without variables.
Just don't think of it in terms of registers or combo, think of it in
terms of delayed or not (by a clock cycle).


I was being facetious. In general I like keeping a tight
eye on the hardware I am creating. I have not come across
a hardware structure for which I really desired to do this.

Never needed to code a CRC which treated multiple bits
in a single clock cycle? How did you/would you solve that?

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

KJ wrote:

You have more faith on synthesis software than I do

Mike G.

Unless the source code you write is only in terms of hooking up 4-6 input
LUTs, flip flops, small memory elements (and the various new hard features
that keep popping up with each new generation of devices), then you have a
lot more faith in synthesis software than you may realize.

You may not feel comfortable with the coding style, but if it succintly
describes the function and is maintainable (both are rather nebulous metrics
though) than, if nothing else, this is raising your awareness of other ways
of describing functionality and that is a 'good thing' even if you have no
immediate plans to adopt it.

Kevin Jennings

By "visualizing hardware", I mean to think in terms of block
diagram and then describe each block in a VHDL segment. I consider
synthesis software as a tool that performs transformation and local
optimization and converts HDL constructs to LUTs. It just follows your
instruction.

It is like a C compiler that transforms C code to machine instructions.
The compiler can do some optimization but can never change the
algorithm. Regardless how good it is, no compiler can convert bubble
sort (O(n^2)) to quick sort (O(n log n)).

I use variables when the hardware counterpart (an abstract part, not
LUTs) can be clearly identified. The main issue is to relate hardware
to code rather than the usage of variables or sequential statements.
By doing this, I never worry about "simulation/synthesis mismatch"
and seldom check the synthesized RTL schematic (unless for critical
path) because I know it is correct.

Mike G.

 

[KJ]

<mikegurche@yahoo.com> wrote in message
news:1169325608.336364.132040@51g2000cwl.googlegroups.com...

KJ wrote:

You have more faith on synthesis software than I do

Mike G.

Unless the source code you write is only in terms of hooking up 4-6 input
LUTs, flip flops, small memory elements (and the various new hard
features
that keep popping up with each new generation of devices), then you have
a
lot more faith in synthesis software than you may realize.

Snip
Kevin Jennings

By "visualizing hardware", I mean to think in terms of block
diagram and then describe each block in a VHDL segment. I consider
synthesis software as a tool that performs transformation and local
optimization and converts HDL constructs to LUTs. It just follows your
instruction.
It is like a C compiler that transforms C code to machine instructions.
Yep.....and if the usage of a variable or signal translates into a flip flop

or a LUT then so be it.

The compiler can do some optimization but can never change the
algorithm. Regardless how good it is, no compiler can convert bubble
sort (O(n^2)) to quick sort (O(n log n)).
Nobody was implying that it could or should....and certainly not as a result

of choosing between variables or signals in an implementation.

I use variables when the hardware counterpart (an abstract part, not
LUTs) can be clearly identified.
What is the relevance of clearly identifying an abstract part that is not

actually part of the actual implementation? (Since you stated 'not LUTs'
which are the basic logic building block in an FPGA). The code describes
function, which needs to be absolutely correct.

The main issue is to relate hardware
to code rather than the usage of variables or sequential statements.
So how does what you say be related to this thread then?

By doing this, I never worry about "simulation/synthesis mismatch"
and seldom check the synthesized RTL schematic (unless for critical
path) because I know it is correct.

You can only know it is correct via verification by simulation and actual

implementation, not visualization of hardware.

I think your basic point is that having a feel for what is going to be
implemented by the code you write is important so knowing that you will have
difficulty synthesizing dual clock edged flip flops (as an example) is
problematic so you don't do it...and that's a correct view. But use of
variables versus signals does not fall under that category, they will result
in a function that is implemented by a LUT which may be followed by a flip
flop (depending on the usage inside the process).

Kevin Jennings

 

[Mike Treseler]

Jan Decaluwe wrote:

clked : process(clk)
variable cnt_v : count_t;
begin
if rising_edge(clk) then
cnt_v := cnt_v + 1; -- increment on rising edge
end if;
cnt <= cnt_v; -- wire assignment outside of clocked clause
end process clked;

I never used this template, but started to think about it because
of my work on MyHDL.

The question I have is: is there an equivalent (also synthesizable)
version for Verilog? At first sight, I don't think so, but perhaps
I'm wrong.

Don't know.
I will play with it a bit.

Background: there is a MyHDL to Verilog converter, and a MyHDL to
VHDL converter is well under way. When finished, IP developers will
have a way to generate equivalent Verilog and VHDL code from a single
source. Of course, this requires that equivalent templates exist
in both languages.

Good work.

-- Mike Treseler