Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Code Style - Default Value of Signal in Process

Reply
Thread Tools

Code Style - Default Value of Signal in Process

 
 
Analog_Guy
Guest
Posts: n/a
 
      07-18-2006
Hi,

Any comments about the following code with regard to setting a default
value
of signal 'a'? It appears that they both compile and synthesize fine,
but are there
any comments related to coding style ... or maybe other factors I am
overlooking?

In this process, 'a' is always assigned a default of '0', before the
value of
'b' is checked. If 'b' is '1', then 'a' ends up getting assigned
twice.

PROCESS (resetn, clock)
BEGIN
IF (resetn = '0') THEN
a <= '0';
ELSIF (clock = '1' AND clock'EVENT) THEN
a <= '0';
IF (b = '1') THEN
a <= '1';
END IF;
END IF;
END PROCESS;


In this process, 'a' is only assigned once, depending on the value of
'b'.

PROCESS (resetn, clock)
BEGIN
IF (resetn = '0') THEN
a <= '0';
ELSIF (clock = '1' AND clock'EVENT) THEN
IF (b = '1') THEN
a <= '1';
ELSE
a <= '0';
END IF;
END IF;
END PROCESS;

 
Reply With Quote
 
 
 
 
Hubble
Guest
Posts: n/a
 
      07-18-2006

Analog_Guy schrieb:

> Hi,
>
> Any comments about the following code with regard to setting a default
> value
> of signal 'a'? It appears that they both compile and synthesize fine,
> but are there
> any comments related to coding style ... or maybe other factors I am
> overlooking?
>
> In this process, 'a' is always assigned a default of '0', before the
> value of
> 'b' is checked. If 'b' is '1', then 'a' ends up getting assigned
> twice.
>
> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> a <= '0';
> IF (b = '1') THEN
> a <= '1';
> END IF;
> END IF;
> END PROCESS;
>
>
> In this process, 'a' is only assigned once, depending on the value of
> 'b'.
>
> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> IF (b = '1') THEN
> a <= '1';
> ELSE
> a <= '0';
> END IF;
> END IF;
> END PROCESS;


Note that signal assignments only update the "projected waveform" of a
signal. The effective value of a is changed by the simulator "one
delta" after the rising edge of the clock, in both cases. If you do

a<='0';
a<='1';

inside a process, this is equivalent to

a<='0' after 0 ns;
a<='1' after 0 ns;

The first assignment plans to set a to 0 in the next simulation cycle.
The second removes this projection and plans to set a to '1' in the
next cycle. The effective value of a is assigned only *once*.

So both examples are functionally equivalent.

Hubble.

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      07-18-2006
Analog_Guy wrote:


> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> a <= '0';
> IF (b = '1') THEN
> a <= '1';
> END IF;
> END IF;
> END PROCESS;
>
>
> In this process, 'a' is only assigned once, depending on the value of
> 'b'.
>
> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> IF (b = '1') THEN
> a <= '1';
> ELSE
> a <= '0';
> END IF;
> END IF;
> END PROCESS;


The two processes are equivalent.
I think the second is easier to read.

-- Mike Treseler
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-18-2006

> Any comments about the following code with regard to setting a default
> value
> of signal 'a'?


As a general rule I use (and prefer) the second approach (explicitly
assiging 'a' for both the 'if' and 'else' branches) since it tends to
keep all assignments to a signal in the same general area of the source
code (which helps when you're perusing code). At times though I'll
break this general rule if the logic is getting too busy (i.e. many
nested if/case, etc.) and put a second signal assignment at the top as
a default and add a comment something to the effect "Default -- unless
overridden below". I never bend it to the extent that there are
multiple assignments existing in multiple different logic structures.

>
> In this process, 'a' is always assigned a default of '0', before the
> value of
> 'b' is checked. If 'b' is '1', then 'a' ends up getting assigned
> twice.


And all that will probably mean is that the simulation could run some
very small fraction slower. I doubt that this time difference would be
at all noticeable for any actual design.

KJ

 
Reply With Quote
 
Mark McDougall
Guest
Posts: n/a
 
      07-19-2006
Mike Treseler wrote:

> I think the second is easier to read.


Whilst I acknowledge Mike's knowledge and experience, I humbly disagree.

The issue is perhaps better considered when *many* different signals are
involved and the logic is perhaps a little more complex for assigning
'non-default values'. Another good example is in a state machine,
whereby one can potentially avoid assigning values in many different states.

FWIW my background is actually software, so perhaps that's why I have a
different opinion?!?

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-19-2006
> The issue is perhaps better considered when *many* different signals are
> involved and the logic is perhaps a little more complex for assigning
> 'non-default values'. Another good example is in a state machine, whereby
> one can potentially avoid assigning values in many different states.


Generally I find in a state machine that the 'default' assignment that is
needed is not some specific default value but instead to simply retain the
current value which of course requires no line of code at all.

Many times when there are only a couple places where assignments that differ
from a default value are needed it is 'usually better' to move those
assignments out of the state machine entirely and simply assign the signal
as being a decode of being in those particular states something like

if ((Current_State = Do_Something) or (Current_State = Do_Something_Else)
then
a <= '1';
else
a <= '0';
end if;

'Usually better' means that in a lot of cases (not all, hence the 'usually')
the signal 'a' does not really need to be a function of the next state of
the state machine it can instead be a function of the current state. If
that is the case, then 'a' will not be involved with all of the next state
decoding logic and will then tend to have higher performance (hence the
'better'). The more signals there are like that cluttering up the state
machine the less understandable/supportable the code tends to become.

Another less tangible 'better' is that the dependencies of signal 'a' are a
lot clearer in the source code since all the assignments to 'a' are
spacially grouped together in the source. This will also tend to clear up
the state machine code as well since now it won't be cluttered with
assignments to signals that really don't actually require the 'next' state
of the state machine but can get by just fine using the 'current' state.

KJ


 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      07-19-2006
In clocked processes (where I do almost all my coding anyway) I use
either method, depending on the complexity of the code. Especially WRT
state machines, I use default assignments a lot, to keep the FSM code
itself a little cleaner.

In combinatorial processes, default assignments to every signal are the
simplest, safest way to avoid latches. I've read coding style guides
that emphasize having an "else" for every "if", etc., and yet debugged
a lot of code that followed that rule and still had unassigned signals
resulting in latches. Default assignments are also very easily audited
in code reviews, and then you don't have to worry about "elses" for
every "if", etc.

In general though, I avoid combinatorial processes if at all possible.
With variables, and signal assignments outside the clocked "if" clause
(results in combinatorial logic after the registers), the uses for the
combinatorial process have diminished greatly.

Andy

 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-20-2006

"Andy" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> In clocked processes (where I do almost all my coding anyway) I use
> either method, depending on the complexity of the code. Especially WRT
> state machines, I use default assignments a lot, to keep the FSM code
> itself a little cleaner.
>

Since the 'state machine control' logic in a state machine expresses the
conditions under which the 'current state' is supposed to change to some
other state, the default assignments are of no use there since the 'default'
is to stay in the current state (whatever state that may be) not in some
hard coded state.

That would imply that when using default assignments in your state machine
code it is for setting other state machine outputs. By intermingling
equations for outputs and equations for state coding together, in some sense
you've already dirtied your state machine code. A decent percentage of the
time though I've found that those other outputs don't really need to depend
on the next state (which would then force the equations for those outputs to
be expressed in the state machine decode logic) but instead could be decoded
off of the current state which means that those equations for the outputs
could be moved completely out of the state machine logic and written more
cleanly all by themselves....and tend to have higher performance to boot.

I don't disagree with you that there are times when you do need to embed
those output equations in with the state machine logic because you really do
need to set them based on the 'next' state and then the use of default
assignments would be useful but I don't think it should happen as you say 'a
lot'.

> In combinatorial processes, default assignments to every signal are the
> simplest, safest way to avoid latches. I've read coding style guides
> that emphasize having an "else" for every "if", etc., and yet debugged
> a lot of code that followed that rule and still had unassigned signals
> resulting in latches. Default assignments are also very easily audited
> in code reviews, and then you don't have to worry about "elses" for
> every "if", etc.


Agreed. Here the use of defaults is a much cleaner approach.

> In general though, I avoid combinatorial processes if at all possible.
> With variables, and signal assignments outside the clocked "if" clause
> (results in combinatorial logic after the registers), the uses for the
> combinatorial process have diminished greatly.


Diminished to near zero in my opinion.

KJ


 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      07-20-2006
I agree with you, it just depends on what the "default" behavior of the
output is: is it a pulsed output, which defaults to off, unless the SM
turns it on (and it is up to the SM to keep it on for long enough), or
is it a modal output, where it retains its previous value unless
changed by the SM. In the case of the latter, I usually put a comment
about it in the section where the other defaults are explicitly set.
Either way, the coding in the SM is usually simpler and cleaner that
way.

Andy


KJ wrote:
> "Andy" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
> > In clocked processes (where I do almost all my coding anyway) I use
> > either method, depending on the complexity of the code. Especially WRT
> > state machines, I use default assignments a lot, to keep the FSM code
> > itself a little cleaner.
> >

> Since the 'state machine control' logic in a state machine expresses the
> conditions under which the 'current state' is supposed to change to some
> other state, the default assignments are of no use there since the 'default'
> is to stay in the current state (whatever state that may be) not in some
> hard coded state.
>
> That would imply that when using default assignments in your state machine
> code it is for setting other state machine outputs. By intermingling
> equations for outputs and equations for state coding together, in some sense
> you've already dirtied your state machine code. A decent percentage of the
> time though I've found that those other outputs don't really need to depend
> on the next state (which would then force the equations for those outputs to
> be expressed in the state machine decode logic) but instead could be decoded
> off of the current state which means that those equations for the outputs
> could be moved completely out of the state machine logic and written more
> cleanly all by themselves....and tend to have higher performance to boot.
>
> I don't disagree with you that there are times when you do need to embed
> those output equations in with the state machine logic because you really do
> need to set them based on the 'next' state and then the use of default
> assignments would be useful but I don't think it should happen as you say 'a
> lot'.
>
> > In combinatorial processes, default assignments to every signal are the
> > simplest, safest way to avoid latches. I've read coding style guides
> > that emphasize having an "else" for every "if", etc., and yet debugged
> > a lot of code that followed that rule and still had unassigned signals
> > resulting in latches. Default assignments are also very easily audited
> > in code reviews, and then you don't have to worry about "elses" for
> > every "if", etc.

>
> Agreed. Here the use of defaults is a much cleaner approach.
>
> > In general though, I avoid combinatorial processes if at all possible.
> > With variables, and signal assignments outside the clocked "if" clause
> > (results in combinatorial logic after the registers), the uses for the
> > combinatorial process have diminished greatly.

>
> Diminished to near zero in my opinion.
>
> KJ


 
Reply With Quote
 
Jim Lewis
Guest
Posts: n/a
 
      07-26-2006
Hi,
For simple processes like the one you have shown, I
prefer to use the second process.

However, for statemachines, I default all outputs to their
non-driving value (as you show in the first process)
and then only assign a vlaue to an output when it is the
driving value. If used consistently, this will make your
statemachine code shorter (50% or more).

As long as one or the other coding style is used consistently
(ie: not mixed together), the code is readable. Once you
get used to defaulting a statemachine outputs and only driving
the active value, I find it faster to sum up what the code is
doing. Those of us who prefer 2 process statemachines find
other value in this style too.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training (E-Mail Removed)
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

> Hi,
>
> Any comments about the following code with regard to setting a default
> value
> of signal 'a'? It appears that they both compile and synthesize fine,
> but are there
> any comments related to coding style ... or maybe other factors I am
> overlooking?
>
> In this process, 'a' is always assigned a default of '0', before the
> value of
> 'b' is checked. If 'b' is '1', then 'a' ends up getting assigned
> twice.
>
> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> a <= '0';
> IF (b = '1') THEN
> a <= '1';
> END IF;
> END IF;
> END PROCESS;
>
>
> In this process, 'a' is only assigned once, depending on the value of
> 'b'.
>
> PROCESS (resetn, clock)
> BEGIN
> IF (resetn = '0') THEN
> a <= '0';
> ELSIF (clock = '1' AND clock'EVENT) THEN
> IF (b = '1') THEN
> a <= '1';
> ELSE
> a <= '0';
> END IF;
> END IF;
> END PROCESS;
>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How to make an internal signal embedded deep in hierarchy to a gloal output signal Weng Tianxiang VHDL 2 01-30-2007 12:58 PM
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM



Advertisments