Newbie question on combining if rising_edge(clk).

[goouse99]

Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:

I think this is one of the rare instances where you're wrong.

wait until clk = '1';

is equivalent to

wait on clk until clk = '1';

which is the same as

wait until rising_edge(clk)

if clk can only be '0' or '1'.



Likewise the OP's

if clk = '1' then

in a process where clk was the only thing in the sensitivity list

should have the same behavior as any of that, or of the more traditional

if rising_edge(clk) then



I've used the "wait until" form in synthesizable code a couple times.

It seems to work, at least on modern synthesizers, and it's nice to save

one level of indentation, but it's not a huge deal one way or another.

It does make an async reset pretty impossible, for what that's worth in

whichever circumstances.



I think my biggest problem with it stylistically is that it's simply

not canonical. The synthesizer can take in all manner of things that,

handed off to someone who didn't write them, would cause

consternation. The goal of writing code is to produce something that

not only performs correctly, but is intuitively and obviously correct

to anyone who sits down to read it. Part of that is doing commonly

done things in the way they're commonly done.



--

Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order. See above to fix.

Hi Rob,
just tested it in ISE 13.1.
It really gives a FF, there's always more to learn about VHDL.

I understand the reasoning behind the processes with only clock on the sensitivity list. But actually the synthesis tools ignore the sensitivity list, so it can not have any effect to the created logic.
Moreover, VHDL-2008 just came up with "process(all)" to simplify things, and what if you want to have resets? What if you have just one input signal and want to create something purely combinatorical?

As you pointed out
wait until clk = '1';
is just a simplification of
wait on clk until clk = '1';

The signals behind the "on" are a sensitivity list and therefore event triggered. So it makes some sense to create a FF. I just wonder why the sensitivity list here isn't ignored. Even this leads to a FF:
wait until (Clock = '1' and Clock2 = '1');
A gated clock, that is!
wait on Clock until (Clock = '1' and Clock2 = '1');
Gives the same gated clock. But Clock2 is not on the sensitivity list.
Is this a clue that the sensitivity list is ignored here too?
How to implement a Clock Enable with wait until?
wait until rising_edge(Clock) and Clock2 = '1';
So, this works, but isn't this a contradiction?
While the sole clk='1' is edge sensitive, and Clock2 ='1' before has been seen as a second clock input, now it is seen as a CE. Weird! Any logical explanation someone?

wait on Clock2 until rising_edge(Clock) and Clock2 = '1'; --FF with CE
This again gives a FF with CE(clock2). So the Event triggering by the sensitivity list is truly ignored in synthesis.

___________

I agree, code readability for the common engineer should be a major concern.
While the example of
wait until clk = '1';
works, the majority, like me just lately, would be alerted since they would suspect Latches to appear.
The alternative, if one chooses to use wait until for some reason, is much simpler recognized to be edge sensitive:
wait until rising_edge(clk);
So just a few characters more saves from much confusion when it comes to code maintainance etc.

I wonder if someone who explicitely wanted to build a latch for some reason ever stumbled about this syntax and cursed the tools to hell since no latch would appear.

Kind regards
Eilert

 

[rickman]

Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:

Hi Rob,
just tested it in ISE 13.1.
It really gives a FF, there's always more to learn about VHDL.

I understand the reasoning behind the processes with only clock on the sensitivity list. But actually the synthesis tools ignore the sensitivity list, so it can not have any effect to the created logic.
Moreover, VHDL-2008 just came up with "process(all)" to simplify things, and what if you want to have resets? What if you have just one input signal and want to create something purely combinatorical?

As you pointed out
wait until clk = '1';
is just a simplification of
wait on clk until clk = '1';

The signals behind the "on" are a sensitivity list and therefore event triggered. So it makes some sense to create a FF. I just wonder why the sensitivity list here isn't ignored. Even this leads to a FF:
wait until (Clock = '1' and Clock2 = '1');
A gated clock, that is!
wait on Clock until (Clock = '1' and Clock2 = '1');
Gives the same gated clock. But Clock2 is not on the sensitivity list.
Is this a clue that the sensitivity list is ignored here too?
How to implement a Clock Enable with wait until?
wait until rising_edge(Clock) and Clock2 = '1';
So, this works, but isn't this a contradiction?
While the sole clk='1' is edge sensitive, and Clock2 ='1' before has been seen as a second clock input, now it is seen as a CE. Weird! Any logical explanation someone?

wait on Clock2 until rising_edge(Clock) and Clock2 = '1'; --FF with CE
This again gives a FF with CE(clock2). So the Event triggering by the sensitivity list is truly ignored in synthesis.

Do you know that these forms are synthesized the way you state? This
last one does not actually describe a FF with CE. If Clock2 is asserted
the wait will trigger, but unless Clock is rising at the same time it
won't be true, will it? The simulation would not work, so if this works
in synthesis you have a mismatch.

___________

I agree, code readability for the common engineer should be a major concern.
While the example of
wait until clk = '1';
works, the majority, like me just lately, would be alerted since they would suspect Latches to appear.
The alternative, if one chooses to use wait until for some reason, is much simpler recognized to be edge sensitive:
wait until rising_edge(clk);
So just a few characters more saves from much confusion when it comes to code maintainance etc.

I would still find this form confusing. I don't actually "read" code
for the most part. I speed read it like I read a book. It is only when
I am looking for a bug that I go into second grade, "read every word"
mode. So I am very used to seeing the visual clues from the white space
used with the conventional structures. Like a stop sign being octagonal
and a warning sign being a diamond, etc.

I wonder if someone who explicitely wanted to build a latch for some reason ever stumbled about this syntax and cursed the tools to hell since no latch would appear.

Yeah, that could be interesting.

 

[goouse99]

Am Donnerstag, 18. Juli 2013 20:20:26 UTC+2 schrieb rickman:

Do you know that these forms are synthesized the way you state? This

last one does not actually describe a FF with CE. If Clock2 is asserted

the wait will trigger, but unless Clock is rising at the same time it

won't be true, will it? The simulation would not work, so if this works

in synthesis you have a mismatch.














I would still find this form confusing. I don't actually "read" code

for the most part. I speed read it like I read a book. It is only when

I am looking for a bug that I go into second grade, "read every word"

mode. So I am very used to seeing the visual clues from the white space

used with the conventional structures. Like a stop sign being octagonal

and a warning sign being a diamond, etc.








Yeah, that could be interesting.



--



Rick

Hi Rick,
yes, I've tested all the mentioned examples with ISE 13.4 XST and looked at the technology view to see the result.

The last example :
wait on Clock2 until rising_edge(Clock) and Clock2 = '1'; --FF with CE
surely would give the mentioned mismatch with simulation.
But, and that's the point, this is the same as with a process with wrong sensitivity list.
The equivalent process would be like this:

process(Clock2) is
begin
if rising_edge(Clock) then
if Clock2 = '1' then --the CE
Dout <= Din; -- simple Datapath (Register)
end if;
end if;
end process;

Synthesis would give a nice FF with CE but simulation would just "trigger" the process on a Clock2 event.

I just wanted to check wether synthesis ignores sensitivity lists in wait statements too, or not.

__________

With confusing you mean the general use of wait statement synchronized processes?
Basically I agree to that.
While at (rare) times the wait-statement coding results in much simpler code one could well do without it for the sake of a uniform coding style.
And if some "code-artist" insists on using this in a project, the source could be used as a simulation reference to verify a style conform recoded model.

Kind regards
Eilert

 

[rickman]

Am Donnerstag, 18. Juli 2013 20:20:26 UTC+2 schrieb rickman:

Hi Rick,
yes, I've tested all the mentioned examples with ISE 13.4 XST and looked at the technology view to see the result.

The last example :
wait on Clock2 until rising_edge(Clock) and Clock2 = '1'; --FF with CE
surely would give the mentioned mismatch with simulation.
But, and that's the point, this is the same as with a process with wrong sensitivity list.
The equivalent process would be like this:

process(Clock2) is
begin
if rising_edge(Clock) then
if Clock2 = '1' then --the CE
Dout<= Din; -- simple Datapath (Register)
end if;
end if;
end process;

Synthesis would give a nice FF with CE but simulation would just "trigger" the process on a Clock2 event.

I just wanted to check wether synthesis ignores sensitivity lists in wait statements too, or not.

I see. Interesting even if perhaps not useful. I typically don't dig
into how the tools work beyond what I want to do with them, but this can
be useful info when chasing bugs. The more you know how the tools work,
the better you will know how they don't work.

__________

With confusing you mean the general use of wait statement synchronized processes?
Basically I agree to that.
While at (rare) times the wait-statement coding results in much simpler code one could well do without it for the sake of a uniform coding style.
And if some "code-artist" insists on using this in a project, the source could be used as a simulation reference to verify a style conform recoded model.

I don't follow that last sentence.

Yes, I'm talking about the general use of wait statements for FF
inference. But then I make use of the async reset in nearly all clocked
processes so maybe I'm a little biased.

I don't typically deal with any "code artists". I work alone and even
when I get code from vendors they nearly always use more conventional
forms.

BTW, working alone has its down side. That is one of the main reasons I
post in newsgroups. Without communications here I would get nearly no
cross-fertilization. Even if I don't use an idea that others provide, I
might well be inspired by it. So thanks for your comments and ideas.

 

[Fredxx]

On 19/07/2013 08:34, (e-mail address removed) wrote:

Hi Rick, yes, I've tested all the mentioned examples with ISE 13.4
XST and looked at the technology view to see the result.

The last example : wait on Clock2 until rising_edge(Clock) and Clock2
= '1'; --FF with CE surely would give the mentioned mismatch with
simulation. But, and that's the point, this is the same as with a
process with wrong sensitivity list. The equivalent process would be
like this:

process(Clock2) is begin if rising_edge(Clock) then if Clock2 = '1'
then --the CE Dout <= Din; -- simple Datapath (Register) end if; end
if; end process;

Synthesis would give a nice FF with CE but simulation would just
"trigger" the process on a Clock2 event.

I just wanted to check wether synthesis ignores sensitivity lists in
wait statements too, or not.

I didn't think you could have a sensitivity list to a process using
"wait" statements. Or should I say Modelsym throws wobblies if you do?

 

[goouse99]

Am Samstag, 20. Juli 2013 00:13:10 UTC+2 schrieb Fredxx:

On 19/07/2013 08:34, [email protected],com wrote:



<snip googled mincing of posts>




















I didn't think you could have a sensitivity list to a process using

"wait" statements. Or should I say Modelsym throws wobblies if you do?

Hi Fred,
if you carefully read the last postings again or look up the wait-statement syntax you would know what I'm refering to.
e.g. here:
http://www.nt-nv.fh-koeln.de/Labor/VhdlEnglish/Kap8/k8211.html

Of course you can't have:
process(<sensitivity_list>)...
....
wait ...

But there is:
process is...
....
wait on <sensitivity_list> until ...

And the last one was being under discussion.

Have a nice synthesis
Eilert

 

[KJ]

Also, the implicit wait statement in a process with a sensitivity list isat the
BOTTOM of the process, not at the top. No real difference for synthesis, but there
are differences in simulation: all processes run at startup, regardless of the
sensitivity list. Wait statements will not trigger at startup.

Don't think so. Consider this simple case

Original code...

ORIG_PROC : process(clock)
begin
if rising_edge(clock) then
a <= '0';
end if;
end process;

Implemented with the wait at the start of the process where it belongs...

WAIT_AT_TOP_PROC : process
begin
wait until rising_edge(clock);
a <= '0';
end process;

Implemented with the wait at the bottom where you said it belongs...

WAIT_AT_END_PROC : process
begin
a <= '0';
wait until rising_edge(clock);
end process;

At t=0, all three processes trigger. ORIG_PROC and WAIT_AT_TOP_PROC willnot assign any new value to signal 'a' so it will remain 'U' because even though there is an implicit 'event' to cause the process to trigger, the condition 'rising_edge(clock)' will not be true so ORIG_PROC will complete and exit, 'WAIT_AT_TOP_PROC' will suspend until the rising edge condition is met. Both processes will wake up at the next event on 'clock'. However, WAIT_AT_END_PROC will assign '0' to signal 'a' and then suspend therefore WAIT_AT_END_PROC is not equivalent to the original 'ORIG_PROC'.

As you stated, there will be no synthesis differences and there will be simulation differences but the incorrect one is when you put the wait statement at the end of the process.

Kevin Jennings

 

[rickman]

Don't think so. Consider this simple case

Original code...

ORIG_PROC : process(clock)
begin
if rising_edge(clock) then
a<= '0';
end if;
end process;

Implemented with the wait at the start of the process where it belongs...

WAIT_AT_TOP_PROC : process
begin
wait until rising_edge(clock);
a<= '0';
end process;

Implemented with the wait at the bottom where you said it belongs...

WAIT_AT_END_PROC : process
begin
a<= '0';
wait until rising_edge(clock);
end process;

Your analysis is faulty. The wait until rising_edge statement is not
equivalent to the if rising_edge statement in the process with a
sensitivity list. This can be seen in the case where the process
includes a second trigger in the sensitivity list like a reset. The IF
statement prevents the code within from being executed when the process
runs unless the process was triggered by the rising edge of the clock.

At t=0, all three processes trigger. ORIG_PROC and WAIT_AT_TOP_PROC will not assign any new value to signal 'a' so it will remain 'U' because even though there is an implicit 'event' to cause the process to trigger, the condition 'rising_edge(clock)' will not be true so ORIG_PROC will complete and exit, 'WAIT_AT_TOP_PROC' will suspend until the rising edge condition is met. Both processes will wake up at the next event on 'clock'. However, WAIT_AT_END_PROC will assign '0' to signal 'a' and then suspend therefore WAIT_AT_END_PROC is not equivalent to the original 'ORIG_PROC'.

The WAIT_AT_TOP_PROC and WAIT_AT_END_PROC processes still need an IF
statement wrapping the assignment statement.

As you stated, there will be no synthesis differences and there will be simulation differences but the incorrect one is when you put the wait statement at the end of the process.

I think there will be no differences seen in simulation. Am I wrong
with my view?

 

[KJ]

Your analysis is faulty. The wait until rising_edge statement is not
equivalent to the if rising_edge statement in the process with a
sensitivity list.

My analysis is correct, you're misreading the post. The point that I was responding to from Andy is simply his statement about the placement of the wait statement being at the bottom of the process rather than the top (that portion of Andy's post is the only thing shown in my post, the rest of his post was snipped). To prove, I offered up a sample process 'ORIG_PROC' andtwo alternate processes, one with the wait statement at the top, the otherat the bottom. I believe I fairly represented what Andy was proposing with his statement about 'top' and 'bottom' of the process as being the location of the wait statement.

If either alternate behaves differently from 'ORIG_PROC', then it is not equivalent to 'ORIG_PROC' process. I then went on to explain why the two alternatives simulate differently to prove that one way is equivalent to 'ORIG_PROC' and the other one is not. If you don't believe it then don't debatethe point, simply copy/paste my code and simulate it.

This can be seen in the case where the process
includes a second trigger in the sensitivity list like a reset. The IF
statement prevents the code within from being executed when the process
runs unless the process was triggered by the rising edge of the clock.

That's your point not mine.

The WAIT_AT_TOP_PROC and WAIT_AT_END_PROC processes still need an IF
statement wrapping the assignment statement.

No they do not.

I think there will be no differences seen in simulation. Am I wrong
with my view?

Yes you are wrong. Try it in a simulator if you're curious.

Kevin Jennings

 

[rickman]

My analysis is correct, you're misreading the post. The point that I was responding to from Andy is simply his statement about the placement of the wait statement being at the bottom of the process rather than the top (that portion of Andy's post is the only thing shown in my post, the rest of his post was snipped). To prove, I offered up a sample process 'ORIG_PROC' and two alternate processes, one with the wait statement at the top, the other at the bottom. I believe I fairly represented what Andy was proposing with his statement about 'top' and 'bottom' of the process as being the location of the wait statement.

If either alternate behaves differently from 'ORIG_PROC', then it is not equivalent to 'ORIG_PROC' process. I then went on to explain why the two alternatives simulate differently to prove that one way is equivalent to 'ORIG_PROC' and the other one is not. If you don't believe it then don't debate the point, simply copy/paste my code and simulate it.


That's your point not mine.

The point illustrates a case where the process was run other than on the
rising edge of the clock and the code within the IF rising_edge... was
not executed. If you can't explain how this is not like the situation
you are describing then you point must not be correct.

No they do not.

"No they do not"? Taht's the sum total of your explanation? The
location of the wait statement does not alter the rest of the logic.
Why would the effective location of the wait statement alter the effect
of the IF statement? That makes no sense and contradicts everything I
have learned about the language.

Yes you are wrong. Try it in a simulator if you're curious.

I will try this when I get the chance. But you have explained nothing
that would make me think you are right. The IF statement will always
operate. The fact that the process is run has nothing to do with the
execution of the code within the IF statement when the process was not
run because of a rising edge on the clock.

Just tell me how the assignment statements within the IF
(rising_edge(clock)) THEN ... ENDIF will be executed if
rising_edge(clock) does not return TRUE?

 

[KJ]

The point illustrates a case where the process was run other than on the
rising edge of the clock and the code within the IF rising_edge... was
not executed.

Again, that is your point not mine. The entire scope of my point was simply correcting a statement that Andy had made regarding the placement of a wait statement in a process. You keep wanting to expand it into something else entirely.

If you can't explain how this is not like the situation
you are describing then you point must not be correct.

Wow...you have a low standard of proof if someone describing something (or not) is the differentiator for whether or not a point "must not be correct"..

Andy made a point. I provided working example code snippet that anyone witha simulator can test and verify refutes his statement. I quoted only Andy's statement that I was refuting, not the entire rest of the post to give the proper context. That's the way the scientific method works. Your standard of "If you can't explain how..." is the art of politics. But in any case, my first posting did describe exactly why as well.

"No they do not"? Taht's the sum total of your explanation? The
location of the wait statement does not alter the rest of the logic.
Why would the effective location of the wait statement alter the effect
of the IF statement? That makes no sense and contradicts everything I
have learned about the language.

Do you even read what you're quoting from someone else before you decide topost? Please read what is quoted with all the ">>>>" above that you yourself included as part of your post. THAT is a pretty fair explanation. That was in my first post.

Yes you are wrong. Try it in a simulator if you're curious.

I will try this when I get the chance. But you have explained nothing
that would make me think you are right.

I have explained it, you don't understand the explanation. I'm not going to explain again since I also provided working code to demonstrate the pointso that anyone can test it out to verify. I also clearly stated that it would be better to simply simulate it rather than debate the point, but apparently you would rather debate. I'm done debating since you won't take theminimal amount of time it would take to actually verify using the live working code snippets that I provided. Stop being lazy.

If you would take the time, what you would find is that between t=0 and the time of the first rising edge of the clock, the process with the wait statement at the end of the process (as I believe Andy would claim it should be placed) would not behave the same as the original process ('ORIG_PROC').The process with the wait statement at the begining (which Andy in his post was saying was wrong) does behave the same.

My example disproves his statement. It doesn't go any further. Maybe you don't care between t=0 and the first rising edge, but that's not relevant..

Just tell me how the assignment statements within the IF
(rising_edge(clock)) THEN ... ENDIF will be executed if
rising_edge(clock) does not return TRUE?

You have posted no code, I'm not going to write it for you.

Kevin Jennings

 

[Andy]

Kevin,

See ieee std 1076-2008 p.171:

If a process sensitivity list appears following the reserved word process, then the process statement is assumed to contain an implicit wait statementas the last statement of the process statement part; this implicit wait statement is of the form

wait on sensitivity_list ;

Andy

Note that "wait on clk;" and "wait until rising_edge(clk);" are NOT equivalent.

"Wait until rising_edge(clk)" is equivalent to "wait on clk; if rising_edge(clk) then ... end if;". Since the implicit "wait on clk" is the last statement of the process (see above) the if risin_edge(clk) statement would correctly be at the top of the process.

Andy

 

[KJ]

Note that "wait on clk;" and "wait until rising_edge(clk);" are NOT equivalent.

All of the discussion in the thread had been about using some form of "waituntil rising_edge(clk);" not "wait on clk;" as a replacement for "if rising_edge(clk)". What it comes down to then is the code that I posted for 'WAIT_AT_TOP_PROC' is not what you had intended with your last paragraph "Also, the implicit wait statement in a process..." which is why posting code isa 'good' thing. Thanks for clarifying your intent.

Kevin