state machine reset

[Wolfgang Grafen]

I'm still waiting for a description of those "good benefits". The
coding is identical other than eliminating the superfluous text. You
just type less of it...

I did that somewhere here in the threads. Write for readability and
testability and leave the rest for the compiler. They are good enough...

/Wolfgang

 

[Wolfgang Grafen]

I don't get why you think this is any easier than one process. I
think you have done this for a long time and are just used to it. I
have my own style of indentation and I am used to it. But I don't say
it is better than any other. I just like it that way.

I was talking about one clocked process for the complete state machine.
Sorry that you mis-interpreted my example. It is an extract of it...

Wolfgang

 

[Wolfgang Grafen]

If you enjoy the needless extra coding of a nested if-then-else tree
for a state machine, then I suppose all the extra references to state
would be a hindrance to readability.

It is somehow syntax sugar. You are right, case could be a little
better, but this was not my point.

But the solution to readability (and better/safer code too) is to use
the case statement for state machines. Then all but the original
reference to state are assignments to it, the same as all but the
final reference to next_state are assignments to it in your example.

I quit using variable/signal pairs for 'd' and 'q' years ago, and
have never wanted them back.

Sure, intermediate variables are usually not needed for signal
assignments unless you want compute a derived signal.

Best regards

Wolfgang

 

[rickman]

I did that somewhere here in the threads. Write for readability and
testability and leave the rest for the compiler. They are good enough...

Yes, and I replied to those comments. I have not seen any
*substantiated* reasons for separating the sequential and
combinatorial portions of a FSM. Just stating that it is better
because it is better is not justification.

Rick

 

[jacko]

Yes, and I replied to those comments.  I have not seen any
*substantiated* reasons for separating the sequential and
combinatorial portions of a FSM.  Just stating that it is better
because it is better is not justification.

Rick- Hide quoted text -

- Show quoted text -

It's a power saving hint

example

process(ir)
begin
blah blah;
end process;

Now if ir is sequentially assigned, then the write enable of the
signal ir can also be the write enable of the created 'registered
signal copies' of all the inputs to the process not in the sensitivity
list. This makes lower power consumption, as the register effect holds
the logic values still when they could be going all over the shop, but
not needed.

cheers
jacko

p.s. yes I know this interpretation makes my nibz code flawed, as
registering what is assigned to the signal post is not a good idea, as
often it is not valid at the time, and is just a routing. din would be
an example of this (but it is not syncronously assigned), but c is an
example of something which would be valid and is synchronously
assigned, but being registered anyhow (re-registration would have no
major effect appart from duplication of registers). Simulation behaves
as though such registration is used. Well maybe I do a final edit
today.

 

[Wolfgang Grafen]

Yes, and I replied to those comments. I have not seen any
*substantiated* reasons for separating the sequential and
combinatorial portions of a FSM. Just stating that it is better
because it is better is not justification.

I don't do, either. If I said so - sorry for the misunderstanding.
I use only one process for one state machine

Best regards

Wolfgang

 

[Andy]

I am aware that synthesis tools have not always done
the necessary register merging in this situation,
and I suspect that putting the final signal assignments
outside the if statement is effectively a hack to give
the synthesis tool an appropriate hint. But it means
that Q1 and Q2 no longer follow the proper synthesis
template.

"the proper synthesis template" ???

Templates are useful in describing a typical mapping of code structure
to gates and registers, but should not be used as exclusive examples
of good code/design.

If users (and tools, some of which already have) quit focusing on code
templates, and start understanding (and implementing) clock-cycle
behavior, then there will be less confusion. It also leaves more room
for optimization. For example, if register retiming optimizations are
used, the structure of registers and logic will change from what was
literally described anyway. Only when the structure of the
implementation is functionally important (e.g. in synchronization
boundaries) should we focus on structurally clear coding styles, along
with disabling such optimizations.

Take the following example:

signal s1, s2...
....
process (clk) is
variable v1...
begin
if rising_edge(clk) then
v1 := f1(v1, s2);
end if;
s1 <= f2(v1);
end process;

In the example above, s1 is the combinatorial output of the f2
function of a registered v1, or

s1 = f2(registered(v1));

If the assignment to s1 is moved inside the clocked if clause, then s1
becomes the registered f2 of the combinatorial versions of v1.

s1 = registered(f2(v1));

In either case, without an asynchronous reset, the cycle based
behavior is the same, but the implementation is slightly different. I
have even seen Synplify optimize two signals assigned to the same
function, one inside and the other outside the clocked clause,
optimized into the same register and function, which is still
functionally (on a clock cycle basis) correct.

As Mike T aptly pointed out, asynchronous reset creates a meaningful
difference between the two styles (if s1 is assigned inside the
clocked clause, it must also be reset in the reset clause, whereas if
it is after the clocked clause, it need not be included in the reset
clause.)

Naturally, if you need a combinatorial output from registered logic,
this example is the only way to do it in the same process with the
clocked logic, avoiding the need for "public" signals for the
registers. Jonathan B's use of this style for state machine outputs is
another unique and useful application.

Andy

 

[rickman]

"the proper synthesis template" ???

Templates are useful in describing a typical mapping of code structure
to gates and registers, but should not be used as exclusive examples
of good code/design.

If users (and tools, some of which already have) quit focusing on code
templates, and start understanding (and implementing) clock-cycle
behavior, then there will be less confusion. It also leaves more room
for optimization. For example, if register retiming optimizations are
used, the structure of registers and logic will change from what was
literally described anyway. Only when the structure of the
implementation is functionally important (e.g. in synchronization
boundaries) should we focus on structurally clear coding styles, along
with disabling such optimizations.

I can't say I completely agree with that, especially in the context of
your example below. HDL says Hardware Description Language. So I
describe the hardware when I code an HDL. I am not writing
programs.

Take the following example:

signal s1, s2...
...
process (clk) is
variable v1...
begin
if rising_edge(clk) then
v1 := f1(v1, s2);
end if;
s1 <= f2(v1);
end process;

In the example above, s1 is the combinatorial output of the f2
function of a registered v1, or

s1 = f2(registered(v1));

If the assignment to s1 is moved inside the clocked if clause, then s1
becomes the registered f2 of the combinatorial versions of v1.

s1 = registered(f2(v1));

Sorry, but these are not the same. If the tools are allowed to do
that it can break designs.

Your example should have been...

s1 = registered(f2(f1(v1,s2));

If s2 is an input that is asynchronous to the clock, you now have a
race condition that can result in inconsistent states between s1 and
v1.

In either case, without an asynchronous reset, the cycle based
behavior is the same, but the implementation is slightly different. I
have even seen Synplify optimize two signals assigned to the same
function, one inside and the other outside the clocked clause,
optimized into the same register and function, which is still
functionally (on a clock cycle basis) correct.

Given my objection above, I suspect that they are doing something to
recognize when it is ok to do this and when it is not ok.

 

[kennheinrich]

So it is very important to me
to know what the "lowest common denominator" is for synthesis
support; I want to find the boundaries of industry-wide support,
and explore how to do interesting stuff within those boundaries.

This lowest common denominator as a function of tools and vendors will
always then be a moving target, defined not by well-understood
standards but by experience and time. That's not necessarily a bad
thing, but those standards need to be understood as a dynamic,
evolving goal, and not taken as absolute immortal truth. While I
understand your need and motivation as a consultant for discovering
these basic limits, the same drive can be (and sadly, usually is)
perverted by less knowledgeable users in industry. Hence the evolution
of the coding style "folklore", or "cargo-cult coding". I have a
mental image of medieval peasants in a dark cave, huddled around the
smoky fire, telling ghost stories: "Avert thine eyes from the lure of
variables, my son, for they shall leadest thou into the fires of
damnation...".

Whereas Andy had written:
I agree in principle, and this is in exactly what you need to do to be
able to *read* code - see it execute in your head, rather than try to
map it to "style 1" or "style 2", because you only understand what
style 1 or style 2 do. This is definitely what the *users* need to
learn to do.

But in defense of the synthesis templates, the problem of writing a
synthesis tool that understands _everything_ is obviously a pretty
difficult task. That's what something like IEEE-1076.6 (guidelines for
RTL synthesis) is supposed to help with - give you the lowest common
denominator in a nutshell. However, it's fundamentally impossible to
constrain a user, especially a novice user, to write code that stays
within the strict subset of the guidelines. This gets more and more
difficult as code gets more complex, if-statements and their matching
ends span more and more lines, and and many fumbling fingers get
involved in its development. So, to borrow a comment I've heard about
the C language, VHDL still gives you enough rope to hang yourself. The
problem is to teach you not to actually do it.

- Kenn