Newbie question on combining if rising_edge(clk).

Discussion in 'VHDL' started by mindentropy, Jul 11, 2013.

  1. mindentropy

    goouse99 Guest

    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.


    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
    goouse99, Jul 18, 2013
    1. Advertisements

  2. mindentropy

    rickman Guest

    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.
    rickman, Jul 18, 2013
    1. Advertisements

  3. mindentropy

    goouse99 Guest

    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
    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
    goouse99, Jul 19, 2013
  4. mindentropy

    rickman Guest

    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.

    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

    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.
    rickman, Jul 19, 2013
  5. mindentropy

    Fredxx Guest

    On 19/07/2013 08:34, wrote:

    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?
    Fredxx, Jul 19, 2013
  6. mindentropy

    goouse99 Guest

    Am Samstag, 20. Juli 2013 00:13:10 UTC+2 schrieb Fredxx:
    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:

    Of course you can't have:
    wait ...

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

    And the last one was being under discussion.

    Have a nice synthesis
    goouse99, Jul 22, 2013
  7. mindentropy

    KJ Guest

    Don't think so. Consider this simple case

    Original code...

    ORIG_PROC : process(clock)
    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
    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
    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
    KJ, Aug 3, 2013
  8. mindentropy

    rickman Guest

    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.

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

    I think there will be no differences seen in simulation. Am I wrong
    with my view?
    rickman, Aug 3, 2013
  9. mindentropy

    KJ Guest

    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.
    That's your point not mine.
    No they do not.
    Yes you are wrong. Try it in a simulator if you're curious.

    Kevin Jennings
    KJ, Aug 3, 2013
  10. mindentropy

    rickman Guest

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

    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?
    rickman, Aug 4, 2013
  11. mindentropy

    KJ Guest

    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. 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.
    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.
    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..
    You have posted no code, I'm not going to write it for you.

    Kevin Jennings
    KJ, Aug 4, 2013
  12. mindentropy

    Andy Guest


    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 ;


    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, Aug 5, 2013
  13. mindentropy

    KJ Guest

    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.

    KJ, Aug 5, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.