Newbie question on combining if rising_edge(clk).

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

  1. mindentropy

    mindentropy Guest


    I am learning vhdl and found when writing a simple clock divider I did a
    if rising_edge(clk) and div=someval. ISE throws an error saying "The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release."

    I rearranged it to do
    if(rising_edge(clk) then
    if (div = someval)
    and it works fine. I don't seem to understand what seems to be wrong?

    mindentropy, Jul 11, 2013
    1. Advertisements

  2. mindentropy

    alb Guest

    I think it would be useful to know other details like which version of
    ISE and which technology you are targeting.
    Moreover the complete error reported by ISE is:
    <nitpick mode ON>
    With such a long error message some people decide to post only the first
    sentence, some others only the second, some other again just a part of
    the two sentences. IMO either the full message should be reported or
    only the unique part which is essentially the error code.
    <nitpick mode OFF>

    Searching with Google I nevertheless got this as *first* hit:

    which points to the solution:
    I would add a little context to the 'if' statement since it is possible
    that the error is hiding somewhere near it but nobody will ever know
    without the code. I always struggle a lot when I have to post code since
    sometimes simplified examples might be not representative of your actual
    case (therefore ending being just an academic discussion) while other
    times your actual case might need too much context to be understood and

    alb, Jul 11, 2013
    1. Advertisements

  3. mindentropy

    rickman Guest

    To write it out more clearly...

    if (A and B) then
    end if;

    compared to...

    if (A) then
    if (B) then
    end if;
    end if;

    Where A is rising_edge().

    The second form is easier for tools to see what you intend. Synthesis
    does not necessarily result from function. It results from form. This
    is just a feature of the synthesis tool it is not really a language
    issue. But it does make the code easier for others to read as well.
    rickman, Jul 11, 2013
  4. mindentropy

    alb Guest

    On 11/07/2013 13:07, rickman wrote:
    shouldn't the first form correspond to a gated clock, where the second
    to just a clock enable? If this is the case the difference between the
    two is *a lot*.

    If we are not talking about clocked processes than AFAIK the two forms
    should be completely equivalent.
    alb, Jul 11, 2013
  5. mindentropy

    Sean Durkin Guest

    This is not just an issue of form. The two descriptions actually
    describe different things, since priorities are different.

    The second description first checks for A, and only if that is met is B
    even evaluated. So if A is rising_edge(), this forces the tool to
    synthesize an entity that reacts to EVERY rising_edge, and then does
    "stuff" if B is true. So this is basically a simple flip-flop or other
    synchronous element with a synchronous reset, set or a synchronous clock
    enable (depending on what "stuff" actually is); no problem there, since
    that is exactly what Xilinx' flipflops are.

    The first description on the other hand checks for A and B
    simultaneously. So if A is rising_edge(), that would mean you want to
    synthesize some entity that only reacts to clock edges under specific
    circumstances, resulting in something like an asynchronous clock enable,
    or a register with built-in clock gating or something.
    And that is something that does not exist per se in the Xilinx
    architecture and/or is highly recommended against (in the case of clock
    gating), so there's no way for XST to correctly automatically synthesize
    something that behaves in a way that matches what is described. Hence
    the error message, and since this is a common mistake, they warrant a
    guess as to what you really wanted to describe.

    Xilinx White Paper WP275
    ( is
    quite interesting, the topic is similar.

    Sean Durkin, Jul 11, 2013
  6. mindentropy

    Jim Lewis Guest

    Dear Xilinx,
    While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:

    if rising_edge(Clk) then
    if (div = someval) then

    IEC 62050-2005 (was IEEE 1076.6-2004) requires that the following is supported as a flip-flop with load enable (gating on data path):

    if rising_edge(Clk) and (div = someval) then

    I disagree with @sean's analysis. The "A and B" does not check them both simultaneously if the results are boolean. Instead, "and" is a short circuit operator, and when it determines the rising edge is false it has determined the result is false, does not analyze B. Hence, from a VHDL perspectivethe code runs the same. You could make arguments about reversing the order of the clock, however, IEC 62050-2005 still treats it as a flip-flop withload enble.

    Historically ASIC vendors have use an attribute with the 1076.6-1999 style to transform it from a data path enable to a clock gate.

    What is happening here is called market driven support of standards. From a vendors perspective, why spend money and support features unless their users are asking for them. From a user's perspective, when a vendor takes this position, they stifle progress within the industry.

    _If you are a Xilinx customer_, please submit a bug report on this and citeIEC 62050-2005 (was IEEE 1076.6-2004) as a reference. Make sure to reference the IEC standard as I think the IEEE version was deprecated.

    If you want to know more about some of the IEC 62050-2005 /1076.6-2004 coding styles, check out my 2002 HDLCon paper, "Extensions to the VHDL RTL Synthesis Standard" on the page:

    It really is shameful that 9 years have gone by since the standard was finalized and 11 since my paper and Xilinx still does not support these.

    Going further, there is so much more we should be able to do that has not been covered in the RTL synthesis standard yet. If anyone is interested in this effort, I can advise you on working through the IEEE standards process.. You will need to get the synthesis vendors on board to insure it gets supported.

    Best Regards,
    Jim Lewis
    IEEE 1076 Working Group Chair
    Former IEEE 1076.6 Vice Chair
    VHDL Training Expert, SynthWorks
    Jim Lewis, Jul 11, 2013
  7. mindentropy

    rickman Guest

    Even if you are talking about gated processes (A is rising_edge(x)),
    there is nothing functionally different about the two. They will
    simulate exactly the same.

    My point is that while simulation will show an equivalence between the
    two, the synthesis tools can make distinctions based on "form" meaning
    exactly how you write the code.

    Logically speaking, why would the first be a gated clock but not the
    second? There is nothing in the VHDL standard that mentions gated vs.
    enabled clocks. I think there is a standard for synthesis but I don't
    know if it covers gated clocks. Anyone know?
    rickman, Jul 11, 2013
  8. mindentropy

    rickman Guest

    Looks like you answered my questions from the post I just made. I
    should have finished reading the thread before I replied.

    Thanks for the info, this is just what I couldn't remember.
    rickman, Jul 11, 2013
  9. mindentropy

    rickman Guest

    Correction......................^^^^^ should be "clocked"...
    rickman, Jul 11, 2013
  10. mindentropy

    mindentropy Guest

    Thanks Jim for clarifying.
    mindentropy, Jul 12, 2013
  11. mindentropy

    valtih1978 Guest

    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.
    valtih1978, Jul 16, 2013
  12. mindentropy

    rickman Guest

    What is the related code for an async resettable FF?
    rickman, Jul 16, 2013
  13. mindentropy

    goouse99 Guest

    Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:
    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
    goouse99, Jul 17, 2013
  14. mindentropy

    valtih1978 Guest

    What is the problem? Can you be more specific?

    Should I care using the async pattern because async reset is depricated
    and I never use it? Why should I care about the related code?

    Is it the only argument you have?
    valtih1978, Jul 17, 2013
  15. mindentropy

    valtih1978 Guest

    Rising_edge(clk) is basically equivalent to

    wait on clk; -- implied by sensetivity list
    if clk'event and clk = '1' then
    end if;

    end process;

    whereas wait until clk='1' is equivalent to (see VHDL spec)

    wait on Clk;
    exit when Clk = '1';
    end loop;
    end process

    Tell me the difference. I see waiting for the edge in both cases. Does
    latch mean the edge-sensitive storage? So, might be it is your
    rising_edge that produces the latch? Why double standards?

    Do you say that bad style is popular because people mistakenly think
    that good style produces the latches?
    valtih1978, Jul 17, 2013
  16. mindentropy

    rickman Guest

    I'm asking how you would use this form to generate an async reset on the
    FF. Who exactly has "deprecated" the async reset? If you never use it,
    that's fine, but I design FPGAs which use an async reset. If you don't
    specify a reset the register value is defaults to zero in most cases. I
    prefer to define a reset value because it can be useful and it makes the
    synthesis match the simulation.

    I see no advantage to this form. It may be fewer keystrokes, but my
    design process is not limited by the number keys I press. I type very
    fast. If I waw worried about the number of keys I press, I wouldn't be
    using VHDL at all.
    rickman, Jul 17, 2013
  17. mindentropy

    valtih1978 Guest

    It is not just a number of keystrokes. You have extra IF-then nest to
    handle, which complicates the structure of your code whereas wait until
    just makes the wait for clk edge explicit. But, thanks for the argument.
    valtih1978, Jul 17, 2013
  18. mindentropy

    Andy Guest

    It would be "safer" to use "wait until rising_edge(clk)", since "wait untilclk = '1';" will trigger if clk changes from 'H' to '1' (not a rising edge), and will not trigger when clk changes from '0' to 'H' (a rising edge).For the synthesis tool it won't matter, but the RTL simulation will matter, potentially causing a simulation mismatch between RTL and gate level simulations.

    If you need asynchronous reset (not a matter of choice for some design domains), then you'd have to wait for either/both of two events, and then you'dhave to use an if-statement to figure out which condition triggered the wait statement.

    BTW, an exit statement with a condition is equivalent to an if statement containing an unconditional exit statement. There are no free lunches.

    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.

    Andy, Jul 17, 2013
  19. mindentropy

    Rob Gaddi Guest

    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

    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, Jul 17, 2013
  20. mindentropy

    rickman Guest

    Yeah, I understand what you are saying. I just don't consider any of
    these advantages to be addressing problems I have when writing VHDL.

    process (clk, reset inputs)
    IF (reset condition) then
    reset assignments...
    ELSIF (rising_edge(clk)) then
    register assignments...
    end process;

    This is just a form that is so common and recognizable that I have never
    given any thought to the need to save a line or two or an indentation

    I have seen the form below used for simple FFs.

    data_out <= data_in when rising_edge(clk);

    This is the simplest form I am familiar with, one line, no indents! The
    problem with the concurrent FF statement is that it is harder to add
    much logic. The FF input signal would need to be defined by other
    statements if the logic is very complex at all.

    Of the three forms, I prefer to just use the clocked process and keep
    the form constant. No one is confused and the registers are always
    easily recognized.

    BTW, I have not read the synthesis standard. Does that mention all
    three of these forms? Does the standard say anything about
    initialization in the signal declaration? That might make a big
    difference in which forms are acceptable or preferred.
    rickman, Jul 17, 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.