[SOLVED] Quartus PowerPlay estimation and asynchronous faster-than-clock signal: clock domain

Akanimo · Sep 13, 2016

Hi all,

I am a newbie and I have a simple task at hand with Quartus II.

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

barry · Sep 15, 2016

I would try running the power analyzer without the combinatorial (not 'asynchronous') signal and see if you get the same results. A 'clock domain' simply means a bunch of logic related to a specific clock. Without knowing what the rest of your design looks like I can't give you much more information.

Akanimo · Sep 15, 2016

Hi Barry,

Thank you very much for the response. The clock domain definition is very clear and I appreciate it.

barry said:
Without knowing what the rest of your design looks like I can't give you much more information.

My code is a simple FSM.

Code:

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;

Barry said:
I would try running the power analyzer without the combinatorial (not 'asynchronous') signal and see if you get the same results.[/CODE]
Please, how am I to do it without a testbench? Just generate a .saf file and use it as a power input file?

Welcome to EDAboard.com

[SOLVED] Quartus PowerPlay estimation and asynchronous faster-than-clock signal: clock domain

Akanimo

Advanced Member level 3

barry

Advanced Member level 7

Akanimo

Akanimo

Advanced Member level 3

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Connect with us

Online statistics

Forum statistics