Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
736 Views

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.
0 Kudos
5 Replies
Highlighted
Valued Contributor III
6 Views

 

--- 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.
0 Kudos
Highlighted
Valued Contributor III
6 Views

 

--- 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.
0 Kudos
Highlighted
Valued Contributor III
6 Views

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
0 Kudos
Highlighted
Valued Contributor III
6 Views

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.
0 Kudos
Highlighted
Valued Contributor III
6 Views

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
0 Kudos