Is the use of 'event attribute on non-clock signal bad practice?











up vote
1
down vote

favorite












There is a similar question here, which was answered with




Yes, rising_edge()/falling_edge() should only be used for clock
signal. While it works in simulation it can cause problems and
unintended hardware in synthesis.




Is the same thing true for using the 'event attribute to detect edges of non-clock signals like in the following example? 



process (rndm_sig)

begin

    if (rndm_sig'event and rndm_sig = 1) then

    -- do something.

    end if;

end process;





vhdl fpga







share|improve this question






















  • Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
    – grorel
    Nov 9 at 9:25










  • Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
    – Andy Ef
    Nov 9 at 9:30










  • Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
    – Matthew Taylor
    Nov 9 at 9:35










  • Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
    – DonFusili
    Nov 9 at 12:10















up vote
1
down vote

favorite












There is a similar question here, which was answered with




Yes, rising_edge()/falling_edge() should only be used for clock
signal. While it works in simulation it can cause problems and
unintended hardware in synthesis.




Is the same thing true for using the 'event attribute to detect edges of non-clock signals like in the following example? 



process (rndm_sig)

begin

    if (rndm_sig'event and rndm_sig = 1) then

    -- do something.

    end if;

end process;





vhdl fpga







share|improve this question






















  • Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
    – grorel
    Nov 9 at 9:25










  • Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
    – Andy Ef
    Nov 9 at 9:30










  • Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
    – Matthew Taylor
    Nov 9 at 9:35










  • Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
    – DonFusili
    Nov 9 at 12:10













up vote
1
down vote

favorite









up vote
1
down vote

favorite











There is a similar question here, which was answered with




Yes, rising_edge()/falling_edge() should only be used for clock
signal. While it works in simulation it can cause problems and
unintended hardware in synthesis.




Is the same thing true for using the 'event attribute to detect edges of non-clock signals like in the following example? 



process (rndm_sig)

begin

    if (rndm_sig'event and rndm_sig = 1) then

    -- do something.

    end if;

end process;





vhdl fpga







share|improve this question













There is a similar question here, which was answered with




Yes, rising_edge()/falling_edge() should only be used for clock
signal. While it works in simulation it can cause problems and
unintended hardware in synthesis.




Is the same thing true for using the 'event attribute to detect edges of non-clock signals like in the following example? 



process (rndm_sig)

begin

    if (rndm_sig'event and rndm_sig = 1) then

    -- do something.

    end if;

end process;





vhdl fpga




vhdl fpga






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 9 at 9:01









Andy Ef

112




112












  • Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
    – grorel
    Nov 9 at 9:25










  • Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
    – Andy Ef
    Nov 9 at 9:30










  • Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
    – Matthew Taylor
    Nov 9 at 9:35










  • Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
    – DonFusili
    Nov 9 at 12:10


















  • Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
    – grorel
    Nov 9 at 9:25










  • Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
    – Andy Ef
    Nov 9 at 9:30










  • Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
    – Matthew Taylor
    Nov 9 at 9:35










  • Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
    – DonFusili
    Nov 9 at 12:10
















Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
– grorel
Nov 9 at 9:25




Here, you define the same thing as if rising_edge(rndm_sig) then ! In synthesis, rndm_sig will be considered as a clock signal.
– grorel
Nov 9 at 9:25












Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
– Andy Ef
Nov 9 at 9:30




Yes, but if rndm_sig is say a signal from a input port then this signal would have to be connected to a clock buffer, which would, according to the other thread, lead to a error during synthesis, correct? My question basically is: Is the same true for using 'event?
– Andy Ef
Nov 9 at 9:30












Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
– Matthew Taylor
Nov 9 at 9:35




Whether you say rising_edge(some_signal) or some_signal=1 and some_signal'event is utterly irrlevant. In both of these some_signal will be connected to the clock input of a flip-flop and is, therefore, a clock.
– Matthew Taylor
Nov 9 at 9:35












Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
– DonFusili
Nov 9 at 12:10




Sounds like an X-Y problem, honestly, a detected edge in digital design is meaningless unless it's either a clock or the edge can be expressed in relation to the clock that will use the decision of the detected edge. In the first case, your question is invalid, in the second there's no reason to use 'event if you have a clock that fulfills Nyquist and the third option is that you're not doing pure digital design, which means you shouldn't be using an FPGA (which you tagged).
– DonFusili
Nov 9 at 12:10












1 Answer
1






active

oldest

votes

















up vote
5
down vote



accepted










Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.



In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.



Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.



The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).



So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.



At the same time there is one rule in digital design which says: all rules are out if there is no other solution.



In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.






share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53222603%2fis-the-use-of-event-attribute-on-non-clock-signal-bad-practice%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    5
    down vote



    accepted










    Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.



    In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.



    Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.



    The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).



    So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.



    At the same time there is one rule in digital design which says: all rules are out if there is no other solution.



    In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.






    share|improve this answer

























      up vote
      5
      down vote



      accepted










      Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.



      In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.



      Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.



      The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).



      So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.



      At the same time there is one rule in digital design which says: all rules are out if there is no other solution.



      In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.






      share|improve this answer























        up vote
        5
        down vote



        accepted







        up vote
        5
        down vote



        accepted






        Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.



        In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.



        Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.



        The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).



        So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.



        At the same time there is one rule in digital design which says: all rules are out if there is no other solution.



        In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.






        share|improve this answer












        Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.



        In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.



        Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.



        The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).



        So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.



        At the same time there is one rule in digital design which says: all rules are out if there is no other solution.



        In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 9 at 11:35









        Oldfart

        2,2792710




        2,2792710






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53222603%2fis-the-use-of-event-attribute-on-non-clock-signal-bad-practice%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            -