Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

PowerPlay estimation and asynchronous faster-than-clock signal: no clock domain found

Hi all,

I am a newbie and I have a simple task at hand.

I am working on a simple controller project on a Max3000A series device with an input signal that is faster than the system clock. This signal and the system clock are externally generated using external oscillators and are then fed into the device through a general I/O pin and a dedicated GCLK pin, respectively. The essence of this signal is to be ANDed with another signal internally generated in the device before being ported out of the device as an output pin. It is not intended to pass through any register in the device, only a single AND gate. I believe that makes its operation asynchronous. It is necessary for me to do this so I can obtain the 5kHz signal I need to drive the kind of buzzer I intend to.

In the power estimation process with PowerPlay Power Analyzer, I get the report that relative toggle rate could not be calculated because no clock domain was found for some nodes in my design and this results in a low confidence level for the estimated power. I think it is because of this 'asynchronous' signal, I am not sure (especially because I don't understand the term 'clock domain', which I will like somebody to help explain to me and, moreso, because I probably haven't represented this signal well in the testbench since it is not supposed to be bounded by the clock).

I need to know how to get a 'high-confidence' power estimation with the PowerPlay Power Analyzer in a scenario like this. And please remember to explain 'clock domain' too. Thanks.

Akanimo.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi all,

    I am a newbie and I have a simple task at hand.

    I am working on a simple controller project on a Max3000A series device with an input signal that is faster than the system clock. This signal and the system clock are externally generated using external oscillators and are then fed into the device through a general I/O pin and a dedicated GCLK pin, respectively. The essence of this signal is to be ANDed with another signal internally generated in the device before being ported out of the device as an output pin. It is not intended to pass through any register in the device, only a single AND gate. I believe that makes its operation asynchronous. It is necessary for me to do this so I can obtain the 5kHz signal I need to drive the kind of buzzer I intend to.

    In the power estimation process with PowerPlay Power Analyzer, I get the report that relative toggle rate could not be calculated because no clock domain was found for some nodes in my design and this results in a low confidence level for the estimated power. I think it is because of this 'asynchronous' signal, I am not sure (especially because I don't understand the term 'clock domain', which I will like somebody to help explain to me and, moreso, because I probably haven't represented this signal well in the testbench since it is not supposed to be bounded by the clock).

    I need to know how to get a 'high-confidence' power estimation with the PowerPlay Power Analyzer in a scenario like this. And please remember to explain 'clock domain' too. Thanks.

    Akanimo.

    --- Quote End ---

    I think you can view the async signal as a clock for the purpose of power. Use a suitable clock value that equals average of change rate of your signal.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I think you can view the async signal as a clock for the purpose of power.

    --- Quote End ---

    Thank you for your response kaz. Please, how am I to achieve that? Like below?

    async_signal_like_clock : PROCESS
        BEGIN
            async_signal <= '0';
            wait for 3 * (async_signal_period/5);
            async_signal <= '1';
            wait for 2 * (async_signal_period/5);
        END PROCESS;

    --- Quote Start ---

    Use a suitable clock value that equals average of change rate of your signal.

    --- Quote End ---

    I don't really understand this statement. Please can you elaborate more on it?

    About clock domain, please help explain to me what it means. Thanks once again.

    Akanimo.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    power estimation can be done in various stages but the easiest one is to compile,fit and then run powerplay.

    Since your design is just few signals you can enter overall toggle rate.below is an example from altera:

    --- Quote Start ---

    The toggle percentage rangesfrom 0 to 100%. Typically, the toggle percentage is 12.5%, which is the toggle percentage of a16-bit counter. To ensure you do not underestimate the toggle percentage, you can use a highertoggle percentage. Most logic only toggles infrequently, and hence toggle rates of less than 50%are more realistic.For example, a T-flip-flop (TFF) with its input tied to VCC has a toggle rate of 100% because itsoutput is changing logic states on every clock cycle (Figure 3–2). Figure 3–3 shows an example ofa 4-bit counter. The first TFF with the LSB output cout0 has a toggle rate of 100% because thesignal toggles on every clock cycle. The toggle rate for the second TFF with output cout1 is 50%since the signal only toggles on every two clock cycles. Consequently, the toggle rate for the thirdTFF with output cout2 and fourth TFF with output cout3 are 25% and 12.5%, respectively.Therefore, the average toggle percentage for this 4-bit counter is (100 + 50 + 25 + 12.5) /4

    --- Quote End ---

    you can enter toggle rate in powerplay r I think yu can also enter in quartus project settings

    Hence testbench is not applicable as quartus does not support that.

    I am not sure why you mentioned system clock but are not telling what is't for. normally we use clock in fpga design to clock registers and that is clock domain
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thank you kaz for being helpful.

    I must apologize for I failed to mention that my project is basically a control system experiment of a simple process. It is made up of a Finite State Machine only (with exception of the async signal I mentioned earlier, which is the only signal that is not a part of the FSM).

    --- Quote Start ---

    Since your design is just few signals you can enter overall toggle rate.

    --- Quote End ---

    With the toggling of the state flipflops being absolutely dependent on events occuring in the process and its previous state, the toggle rate, to me, seems indeterminable.

    I am saying this because I can't ascertain what state the flipflops will transition to and when the transition will occur since it is dependent on real-world inputs. The flipflops will maintain a certain value (say "0101") for as long as an event that triggers a transition to another state does not occur, and when an event occurs, it may transition to, say "1111" or "1011" or "1010" or ..., depending on what event occurred. I think you can guide me better if I paste my code so you take a look at it.

    LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.NUMERIC_STD.all;
    LIBRARY altera_mf; USE altera_mf.altera_mf_components.ALL;
    ENTITY MBHPCP_State_Controller_with_MAX3000A_for_test IS
        PORT (clk, ok, enough, before, beyond                            : IN STD_LOGIC := '1';
                mode_switch, reset, silence_switch, alarm_pulse, buzzer_astable                            : IN STD_LOGIC := '0';
                trouble_buzzer, trouble_LED, auto_mode_LED,                                                  
                enough_LED, before_LED, beyond_LED, not_ok_LED, silence_LED            : OUT    STD_LOGIC := '0';.
                roll                                                                 : BUFFER STD_LOGIC := '0'); 
    END ENTITY MBHPCP_State_Controller_with_MAX3000A_for_test;
    LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.STD_LOGIC_UNSIGNED.ALL; USE IEEE.NUMERIC_STD.ALL;
    ARCHITECTURE behaviour OF MBHPCP_State_Controller_with_MAX3000A_for_test IS
        ---------------
        
        CONSTANT reset_state : STD_LOGIC_VECTOR(2 DOWNTO 0) := "000";
        CONSTANT stop_roll_state : STD_LOGIC_VECTOR(2 DOWNTO 0) := "011";
        CONSTANT roll_state : STD_LOGIC_VECTOR(2 DOWNTO 0) := "110";
        CONSTANT trouble_state : STD_LOGIC_VECTOR(2 DOWNTO 0) := "111";
        CONSTANT silent_state : STD_LOGIC_VECTOR(2 DOWNTO 0) := "101";
        SIGNAL state : STD_LOGIC_VECTOR(2 DOWNTO 0) := reset_state;
    ------------------
        CONSTANT auto : STD_LOGIC := '0';
        SIGNAL alarm_snooze_timer : STD_LOGIC_VECTOR(0 TO 12) := "0000000000000";
        SIGNAL roll_starting_time_delay : STD_LOGIC_VECTOR(0 TO 2) := "000";
        SIGNAL silence_to_trouble : STD_LOGIC := '0';
    BEGIN
    ------------------
    -- GENERATION OF LED INDICATION FOR THE STATUS OF THE RESPECTIVE PROCESS INPUTS BEGINS FROM HERE.
        before_LED <= '1' WHEN before = '0' ELSE '0';        
        enough_LED <= '1' WHEN enough = '0' ELSE '0';            
        beyond_LED <= '1' WHEN beyond = '0' ELSE '0';
        auto_mode_LED <= '1' WHEN mode_switch = auto ELSE '0';
        not_ok_LED <= '1' WHEN ok = '0' ELSE '0';
    -- GENERATION OF LED INDICATION FOR THE STATUS OF THE RESPECTIVE PROCESS INPUTS ENDS HERE.
    ------------------
    ------------------
    -- GENERATION OF ALARM_SNOOZE_TIMER_GENERATOR FOR TROUBLE_BUZZER SNOOZING BEGINS HERE.
        alarm_snooze_timer_generator : PROCESS (clk)
        BEGIN
            IF clk'EVENT AND clk = '1' THEN
                IF alarm_pulse = '1' THEN
                    IF mode_switch = auto THEN
                        IF state = silent_state AND alarm_snooze_timer = "1111111111111" THEN
                            silence_to_trouble <= '1';
                            alarm_snooze_timer <= "0000000000000";
                        ELSIF state = silent_state AND alarm_snooze_timer < "1111111111111" THEN
                            alarm_snooze_timer <= alarm_snooze_timer + 1;
                        ELSE 
                            alarm_snooze_timer <= "0000000000000";
                        END IF;
                        IF state /= silent_state THEN
                            silence_to_trouble <= '0';
                        END IF;
                    END IF;
                END IF;
            END IF;
        END PROCESS;
    ------------------
    ------------------
        roll_starting_time_delay_generator : PROCESS (clk)
        BEGIN
            IF clk'EVENT AND clk = '1' THEN
                IF mode_switch = auto THEN
                    IF state = roll_state AND ok = '1' AND roll_starting_time_delay = "111" THEN
                        roll_starting_time_delay <= roll_starting_time_delay;
                        roll <= '1';
                    ELSIF state = roll_state AND ok = '1' AND roll_starting_time_delay < "111" THEN
                        roll_starting_time_delay <= roll_starting_time_delay + 1;
                        roll <= '0';
                    ELSIF state /= roll_state OR ok = '0' THEN
                        roll_starting_time_delay <= "000";
                        roll <= '0';
                    END IF;
                END IF;
            END IF;
        END PROCESS;
        
    -- GENERATION OF ROLL_STARTING_TIME_DELAY_GENERATOR FOR TROUBLE_BUZZER SNOOZING OF ABOUT 8 SECONDS ENDS HERE.
    ------------------
    ------------------
    -- GENERATION OF FINITE STATE MACHINE FOR RESPECTIVE STATE TRANSITIONS BEGINS FROM HERE
        finite_state_machine_generator : PROCESS (clk)
        BEGIN
            IF (clk'EVENT AND clk = '1') THEN
                IF mode_switch = auto THEN
                    CASE state IS
                        WHEN reset_state =>
                            IF (before = '0' AND enough = '0') OR (beyond = '0') THEN
                                state <= trouble_state;
                            ELSE
                                IF (enough = '0') THEN
                                    state <= stop_roll_state;
                                END IF;
                                IF (before = '0') THEN
                                    state <= roll_state;
                                END IF;
                            END IF;
                        WHEN stop_roll_state =>
                            IF (before = '0' AND enough = '0') OR (beyond = '0') THEN
                                state <= trouble_state;
                            ELSIF (before = '0' AND enough = '1' AND beyond = '1') THEN
                                state <= roll_state;
                            ELSE
                                state <= stop_roll_state;
                            END IF;
                        WHEN roll_state =>
                            IF (before = '0' AND enough = '0') OR beyond = '0' THEN
                                state <= trouble_state;                    
                            ELSIF (before = '1' AND enough = '0' AND beyond = '1') THEN
                                state <= stop_roll_state;
                            ELSE
                                state <= roll_state;
                            END IF;
                        WHEN trouble_state =>
                            IF (reset = '1' AND before = '1' AND enough = '1' AND beyond = '1') THEN
                                state <= reset_state;
                            ELSIF silence_switch = '1' THEN
                                state <= silent_state;
                            ELSE
                                state <= trouble_state;
                            END IF;
                        WHEN silent_state =>
                            IF (reset = '1' AND before = '1' AND enough = '1' AND beyond = '1') THEN
                                state <= reset_state;
                            ELSIF silence_to_trouble = '1' THEN
                                state <= trouble_state;
                            ELSE
                                state <= silent_state;
                            END IF;
                        WHEN OTHERS =>
                            state <= reset_state;
                    END CASE;
                END IF;
            END IF;
        END PROCESS finite_state_machine_generator;
        trouble_buzzer <= '1' WHEN ((state = trouble_state) AND (mode_switch = auto) AND (buzzer_astable='1')) ELSE '0';
        trouble_LED <= '1' WHEN (state = trouble_state) ELSE '0';
        silence_LED <= '1' WHEN state = silent_state ELSE '0';
    -- GENERATION OF FINITE STATE MACHINE FOR RESPECTIVE STATE TRANSITIONS ENDS HERE
    ------------------    
    END ARCHITECTURE behaviour;

    --- Quote Start ---

    you can enter toggle rate in powerplay r I think yu can also enter in quartus project settings

    --- Quote End ---

    Please, how do I calculate the toggle rate in this scenario.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I think your design is too small for too much concern on logic accurate transition rate as most of power would be static (as opposed to that of switching).

    If you indeed want proper rate you need to look at your simulation for sometime and estimate toggle rate per signal. But it is overkill and I suggest using default of 12.5% for io and all signals.

    Try then increase it and you will see the difference to be small anyway