Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Newbie question on combining if rising_edge(clk).

Reply
Thread Tools

Newbie question on combining if rising_edge(clk).

 
 
goouse99@gmail.com
Guest
Posts: n/a
 
      07-18-2013
Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:
> On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)
>
> goo...@.mail,com wrote:
>
>
>
> > Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:

>
> > > wait until clk = '1';

>
> > >

>
> > >

>
> > >

>
> > > requires less typing than

>
> > >

>
> > >

>
> > >

>
> > > if clk = '1' then

>
> > >

>
> > > end if;

>
> > >

>
> > >

>
> > >

>
> > > and, furthremore, causes less confusion than the conditional. I wonder

>
> > >

>
> > > why people keep reproducing this awkward IF pattern instead of wait

>
> > >

>
> > > until. Single wait until synthesizes well, even in xilinx tools now.

>
> > >

>
> > > I've checked that may times.

>
> >

>
> > Hi,

>
> > wait until clk = '1';

>
> >

>
> > actually creates latches, which most of us are trying to avoid.

>
> >

>
> > What you probably mean is:

>
> >

>
> > wait until rising_edge(clk);

>
> >

>
> > And to answer rickmans question too:

>
> > Yes this coding style makes it hard, if not impossible to implement a (async) reset.

>
> > However, there are many applications that neither need this.

>
> > There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.

>
> > But of course, if one needs it, the well known

>
> > if reset then

>
> > elsif rising_edge(clk)

>
> > does the job pretty well, and for thos who whant to save time typing code:

>
> > Use EMACS with VHDL mode.

>
> > Then 90% of the code is writing itself.

>
> > Just make sure you have a reliable TAB button on your keyboard.

>
> >

>
> > Have a nice synthesis

>
> > Eilert

>
> >

>
>
>
> 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
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      07-18-2013
On 7/18/2013 3:18 AM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:
>> On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)
>>
>> goo...@.mail,com wrote:
>>
>>
>>
>>> Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:

>>
>>>> wait until clk = '1';

>>
>>>>

>>
>>>>

>>
>>>>

>>
>>>> requires less typing than

>>
>>>>

>>
>>>>

>>
>>>>

>>
>>>> if clk = '1' then

>>
>>>>

>>
>>>> end if;

>>
>>>>

>>
>>>>

>>
>>>>

>>
>>>> and, furthremore, causes less confusion than the conditional. I wonder

>>
>>>>

>>
>>>> why people keep reproducing this awkward IF pattern instead of wait

>>
>>>>

>>
>>>> until. Single wait until synthesizes well, even in xilinx tools now.

>>
>>>>

>>
>>>> I've checked that may times.

>>
>>>

>>
>>> Hi,

>>
>>> wait until clk = '1';

>>
>>>

>>
>>> actually creates latches, which most of us are trying to avoid.

>>
>>>

>>
>>> What you probably mean is:

>>
>>>

>>
>>> wait until rising_edge(clk);

>>
>>>

>>
>>> And to answer rickmans question too:

>>
>>> Yes this coding style makes it hard, if not impossible to implement a (async) reset.

>>
>>> However, there are many applications that neither need this.

>>
>>> There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.

>>
>>> But of course, if one needs it, the well known

>>
>>> if reset then

>>
>>> elsif rising_edge(clk)

>>
>>> does the job pretty well, and for thos who whant to save time typing code:

>>
>>> Use EMACS with VHDL mode.

>>
>>> Then 90% of the code is writing itself.

>>
>>> Just make sure you have a reliable TAB button on your keyboard.

>>
>>>

>>
>>> Have a nice synthesis

>>
>>> Eilert

>>
>>>

>>
>>
>>
>> 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.


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.

--

Rick
 
Reply With Quote
 
 
 
 
goouse99@gmail.com
Guest
Posts: n/a
 
      07-19-2013
Am Donnerstag, 18. Juli 2013 20:20:26 UTC+2 schrieb rickman:
> On 7/18/2013 3:18 AM, goo...@.mail,com wrote:
>
> > Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:

>
> >> On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)

>
> >>

>
> >> goo...@.mail,com wrote:

>
> >>

>
> >>

>
> >>

>
> >>> Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:

>
> >>

>
> >>>> wait until clk = '1';

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>> requires less typing than

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>> if clk = '1' then

>
> >>

>
> >>>>

>
> >>

>
> >>>> end if;

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>>

>
> >>

>
> >>>> and, furthremore, causes less confusion than the conditional. I wonder

>
> >>

>
> >>>>

>
> >>

>
> >>>> why people keep reproducing this awkward IF pattern instead of wait

>
> >>

>
> >>>>

>
> >>

>
> >>>> until. Single wait until synthesizes well, even in xilinx tools now.

>
> >>

>
> >>>>

>
> >>

>
> >>>> I've checked that may times.

>
> >>

>
> >>>

>
> >>

>
> >>> Hi,

>
> >>

>
> >>> wait until clk = '1';

>
> >>

>
> >>>

>
> >>

>
> >>> actually creates latches, which most of us are trying to avoid.

>
> >>

>
> >>>

>
> >>

>
> >>> What you probably mean is:

>
> >>

>
> >>>

>
> >>

>
> >>> wait until rising_edge(clk);

>
> >>

>
> >>>

>
> >>

>
> >>> And to answer rickmans question too:

>
> >>

>
> >>> Yes this coding style makes it hard, if not impossible to implement a (async) reset.

>
> >>

>
> >>> However, there are many applications that neither need this.

>
> >>

>
> >>> There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.

>
> >>

>
> >>> But of course, if one needs it, the well known

>
> >>

>
> >>> if reset then

>
> >>

>
> >>> elsif rising_edge(clk)

>
> >>

>
> >>> does the job pretty well, and for thos who whant to save time typing code:

>
> >>

>
> >>> Use EMACS with VHDL mode.

>
> >>

>
> >>> Then 90% of the code is writing itself.

>
> >>

>
> >>> Just make sure you have a reliable TAB button on your keyboard.

>
> >>

>
> >>>

>
> >>

>
> >>> Have a nice synthesis

>
> >>

>
> >>> Eilert

>
> >>

>
> >>>

>
> >>

>
> >>

>
> >>

>
> >> 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.

>
>
>
> 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.
>
>
>
> --
>
>
>
> 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

 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      07-19-2013
On 7/19/2013 3:34 AM, (E-Mail Removed) wrote:
> Am Donnerstag, 18. Juli 2013 20:20:26 UTC+2 schrieb rickman:
>> On 7/18/2013 3:18 AM, goo...@.mail,com wrote:
>>
>>> Am Mittwoch, 17. Juli 2013 18:29:38 UTC+2 schrieb Rob Gaddi:

>>
>>>> On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)

>>
>>>>

>>
>>>> goo...@.mail,com wrote:

>>
>>>>

>>
>>>>

>>
>>>>

>>
>>>>> Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:

>>
>>>>

>>
>>>>>> wait until clk = '1';

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> requires less typing than

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> if clk = '1' then

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> end if;

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> and, furthremore, causes less confusion than the conditional. I wonder

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> why people keep reproducing this awkward IF pattern instead of wait

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> until. Single wait until synthesizes well, even in xilinx tools now.

>>
>>>>

>>
>>>>>>

>>
>>>>

>>
>>>>>> I've checked that may times.

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> Hi,

>>
>>>>

>>
>>>>> wait until clk = '1';

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> actually creates latches, which most of us are trying to avoid.

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> What you probably mean is:

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> wait until rising_edge(clk);

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> And to answer rickmans question too:

>>
>>>>

>>
>>>>> Yes this coding style makes it hard, if not impossible to implement a (async) reset.

>>
>>>>

>>
>>>>> However, there are many applications that neither need this.

>>
>>>>

>>
>>>>> There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.

>>
>>>>

>>
>>>>> But of course, if one needs it, the well known

>>
>>>>

>>
>>>>> if reset then

>>
>>>>

>>
>>>>> elsif rising_edge(clk)

>>
>>>>

>>
>>>>> does the job pretty well, and for thos who whant to save time typing code:

>>
>>>>

>>
>>>>> Use EMACS with VHDL mode.

>>
>>>>

>>
>>>>> Then 90% of the code is writing itself.

>>
>>>>

>>
>>>>> Just make sure you have a reliable TAB button on your keyboard.

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>> Have a nice synthesis

>>
>>>>

>>
>>>>> Eilert

>>
>>>>

>>
>>>>>

>>
>>>>

>>
>>>>

>>
>>>>

>>
>>>> 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.

>>
>>
>>
>> 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.
>>
>>
>>
>> --
>>
>>
>>
>> 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.


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.

--

Rick
 
Reply With Quote
 
Fredxx
Guest
Posts: n/a
 
      07-19-2013
On 19/07/2013 08:34, (E-Mail Removed) wrote:

<snip googled mincing of posts>


>> 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.
>



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?
 
Reply With Quote
 
goouse99@gmail.com
Guest
Posts: n/a
 
      07-22-2013
Am Samstag, 20. Juli 2013 00:13:10 UTC+2 schrieb Fredxx:
> On 19/07/2013 08:34, goo...@.mail,com wrote:
>
>
>
> <snip googled mincing of posts>
>
>
>
>
>
> >> 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.

>
> >

>
>
>
>
>
> 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/V...ap8/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

 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-03-2013
On Wednesday, July 17, 2013 12:25:21 PM UTC-4, Andy wrote:
> 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
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-03-2013
On 8/2/2013 9:39 PM, KJ wrote:
> On Wednesday, July 17, 2013 12:25:21 PM UTC-4, Andy wrote:
>> Also, the implicit wait statement in a process with a sensitivity list is at 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;


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?

--

Rick
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-03-2013
On Saturday, August 3, 2013 12:37:36 AM UTC-4, rickman wrote:
> 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.

> > 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.


No they do not.

> > As you stated, there will be no synthesis differences and there will besimulation 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?


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

Kevin Jennings
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-04-2013
On 8/3/2013 10:52 AM, KJ wrote:
> On Saturday, August 3, 2013 12:37:36 AM UTC-4, rickman wrote:
>> 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' 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.
>
>> 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 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.


>>> 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.

>
> 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.


>>> 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?

>
> 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?

--

Rick
 
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
A few question about vhdl(clk,signal,etc..) natiben27@gmail.com VHDL 3 06-10-2013 05:43 PM
with clk'event, must we use clk='1' or clk='0' ? sunshinekisses@gmail.com VHDL 18 08-09-2007 10:42 PM
Signal Set-up Before CLK Rise Wojtek VHDL 12 07-05-2006 01:16 PM
Xilinx translate error : Cannot find signal "clk" Rakesh Sharma VHDL 2 10-22-2004 08:03 PM
clk divider Schmigz VHDL 7 04-15-2004 08:23 AM



Advertisments