Newbie question on combining if rising_edge(clk).

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

  1. Guest

    Hi,

    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?

    Thanks,
    Gautam.
     
    , Jul 11, 2013
    #1
    1. Advertising

  2. alb Guest

    On 11/07/2013 08:16, wrote:
    > Hi,
    >
    > 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 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:

    > ERROR:Xst:827 - Signal *** cannot be synthesized, bad synchronous
    > description. The description style you are using to describe a
    > synchronous element (register, memory, etc.) is not supported in the
    > current software release.


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

    http://forums.xilinx.com/t5/Archived-ISE-issues/Xst-827-Problem-please-help-me-thx/td-p/20673

    which points to the solution:

    http://www.xilinx.com/support/answers/14047.htm

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


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

    HTH.
     
    alb, Jul 11, 2013
    #2
    1. Advertising

  3. rickman Guest

    On 7/11/2013 2:16 AM, wrote:
    > Hi,
    >
    > 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?
    >
    > Thanks,
    > Gautam.


    To write it out more clearly...

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

    compared to...

    if (A) then
    if (B) then
    stuff;
    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.

    --

    Rick
     
    rickman, Jul 11, 2013
    #3
  4. alb Guest

    On 11/07/2013 13:07, rickman wrote:
    []
    > To write it out more clearly...
    >
    > if (A and B) then
    > stuff;
    > end if;
    >
    > compared to...
    >
    > if (A) then
    > if (B) then
    > stuff;
    > 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.


    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
    #4
  5. Sean Durkin Guest

    rickman wrote:
    > To write it out more clearly...
    >
    > if (A and B) then
    > stuff;
    > end if;
    >
    > compared to...
    >
    > if (A) then
    > if (B) then
    > stuff;
    > 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.


    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
    (http://www.xilinx.com/support/documentation/white_papers/wp275.pdf) is
    quite interesting, the topic is similar.

    Greetings,
    Sean
     
    Sean Durkin, Jul 11, 2013
    #5
  6. Jim Lewis Guest

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

    process(clk)
    begin
    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):

    process(clk)
    begin
    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:
    http://www.synthworks.com/papers/

    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
    #6
  7. rickman Guest

    On 7/11/2013 7:55 AM, alb wrote:
    > On 11/07/2013 13:07, rickman wrote:
    > []
    >> To write it out more clearly...
    >>
    >> if (A and B) then
    >> stuff;
    >> end if;
    >>
    >> compared to...
    >>
    >> if (A) then
    >> if (B) then
    >> stuff;
    >> 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.

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


    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?

    --

    Rick
     
    rickman, Jul 11, 2013
    #7
  8. rickman Guest

    On 7/11/2013 1:23 PM, Jim Lewis wrote:
    > Dear Xilinx,
    > While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:
    >
    > process(clk)
    > begin
    > 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):
    >
    > process(clk)
    > begin
    > 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 perspective the 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 with load 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 cite IEC 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:
    > http://www.synthworks.com/papers/
    >
    > 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



    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.

    --

    Rick
     
    rickman, Jul 11, 2013
    #8
  9. rickman Guest

    On 7/11/2013 1:50 PM, rickman wrote:
    > On 7/11/2013 7:55 AM, alb wrote:
    >> On 11/07/2013 13:07, rickman wrote:
    >> []
    >>> To write it out more clearly...
    >>>
    >>> if (A and B) then
    >>> stuff;
    >>> end if;
    >>>
    >>> compared to...
    >>>
    >>> if (A) then
    >>> if (B) then
    >>> stuff;
    >>> 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.

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

    >
    > Even if you are talking about gated processes (A is rising_edge(x)),

    Correction......................^^^^^ should be "clocked"...

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



    --

    Rick
     
    rickman, Jul 11, 2013
    #9
  10. Guest

    On Thursday, July 11, 2013 10:53:32 PM UTC+5:30, Jim Lewis wrote:
    > Dear Xilinx,
    >
    > While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:
    >
    >
    >
    > process(clk)
    >
    > begin
    >
    > 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):
    >
    >
    >
    > process(clk)
    >
    > begin
    >
    > if rising_edge(Clk) and (div = someval) then
    >
    > ...
    >
    >
    >
    > I disagree with @Sean's analysis. The "A and B" does not check them bothsimultaneously 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 perspective the 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 with load 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 cite IEC 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:
    >
    > http://www.synthworks.com/papers/
    >
    >
    >
    > 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 notbeen 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


    Thanks Jim for clarifying.
     
    , Jul 12, 2013
    #10
  11. 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
    #11
  12. rickman Guest

    On 7/16/2013 8:47 AM, valtih1978 wrote:
    >
    > 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.


    What is the related code for an async resettable FF?

    --

    Rick
     
    rickman, Jul 16, 2013
    #12
  13. Guest

    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
     
    , Jul 17, 2013
    #13
  14. 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
    #14
  15. valtih1978 Guest

    Rising_edge(clk) is basically equivalent to

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

    end process;

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

    process
    loop
    wait on Clk;
    exit when Clk = '1';
    end loop;
    <body>
    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
    #15
  16. rickman Guest

    On 7/17/2013 5:58 AM, valtih1978 wrote:
    > 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?


    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.

    --

    Rick
     
    rickman, Jul 17, 2013
    #16
  17. 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
    #17
  18. Andy Guest

    On Wednesday, July 17, 2013 10:04:36 AM UTC-5, valtih1978 wrote:
    > 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.


    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
     
    Andy, Jul 17, 2013
    #18
  19. Rob Gaddi Guest

    On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)
    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.
     
    Rob Gaddi, Jul 17, 2013
    #19
  20. rickman Guest

    On 7/17/2013 11:04 AM, valtih1978 wrote:
    > 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.


    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)
    begin
    IF (reset condition) then
    reset assignments...
    ELSIF (rising_edge(clk)) then
    register assignments...
    ENDIF;
    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
    level.

    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.

    --

    Rick
     
    rickman, Jul 17, 2013
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Schmigz

    clk divider

    Schmigz, Feb 9, 2004, in forum: VHDL
    Replies:
    7
    Views:
    5,704
  2. Rakesh Sharma
    Replies:
    2
    Views:
    2,927
    Thomas Rudloff
    Oct 22, 2004
  3. Wojtek

    Signal Set-up Before CLK Rise

    Wojtek, Jul 2, 2006, in forum: VHDL
    Replies:
    12
    Views:
    1,520
    Pascal Peyremorte
    Jul 5, 2006
  4. Replies:
    18
    Views:
    6,596
  5. Replies:
    3
    Views:
    284
Loading...

Share This Page