Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17252 Discussions

No paths found for timing analysis

Altera_Forum
Honored Contributor II
2,450 Views

When I compile the following code, the compilation proceeds successfully, but the classic timing analyser of quartus generates the warning "Warning: No paths found for timing analysis". The RTL viewer shows that the output is connected to the inputs accordingly to the expression in the process clause. Could somebody tell me what is wrong with timing analysis? 

 

LIBRARY IEEE; 

LIBRARY LPM; 

USE IEEE.STD_LOGIC_1164.ALL; 

USE LPM.LPM_COMPONENTS.ALL; 

USE IEEE.NUMERIC_STD.ALL; 

 

ENTITY Component_test_wo_library IS 

GENERIC 

mod_0_unsigned_width_n : NATURAL := 8; 

mod_0_unsigned_width_d : NATURAL := 8; 

mult_0_unsigned_width_a : NATURAL := 3; 

mult_0_unsigned_width_b : NATURAL := 5; 

add_0_unsigned_width : NATURAL := 8; 

sub_0_unsigned_width : NATURAL := 5; 

div_0_unsigned_width_n : NATURAL := 9; 

div_0_unsigned_width_d : NATURAL := 5 

); 

PORT 

--Input ports 

Input1_I : IN STD_LOGIC_VECTOR(mult_0_unsigned_width_a-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(0,mult_0_unsigned_width_a)); 

Input2_I : IN STD_LOGIC_VECTOR(mult_0_unsigned_width_b-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(0,mult_0_unsigned_width_b)); 

Input3_I : IN STD_LOGIC_VECTOR(sub_0_unsigned_width-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(0,sub_0_unsigned_width)); 

Input4_I : IN STD_LOGIC_VECTOR(mod_0_unsigned_width_n-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(0,mod_0_unsigned_width_n)); 

Input5_I : IN STD_LOGIC_VECTOR(mod_0_unsigned_width_d-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(1,mod_0_unsigned_width_d)); 

Input6_I : IN STD_LOGIC_VECTOR(sub_0_unsigned_width-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(1,sub_0_unsigned_width)); 

 

--Output ports 

Result_O : OUT STD_LOGIC_VECTOR(div_0_unsigned_width_n-1 DOWNTO 0) := STD_LOGIC_VECTOR(TO_UNSIGNED(0,div_0_unsigned_width_n)) 

); 

END Component_test_wo_library ; 

 

ARCHITECTURE a OF Component_test_wo_library IS 

 

SIGNAL Read_Write : STD_LOGIC := '0'; 

 

BEGIN 

 

Component_test_wo_library: 

PROCESS (Input1_I,Input2_I,Input3_I,Input4_I,Input5_I,Input6_I,Read_Write) IS  

BEGIN 

 

Read: 

IF (Read_Write = '0') 

THEN  

Read_Write <= '1'; 

END IF; 

 

Result: 

IF (Read_Write = '1') 

THEN  

Read_Write <= '0'; 

Result_O <= std_logic_vector( (("0" & unsigned(Input1_I) * unsigned(Input2_I)) + (unsigned(Input4_I) mod unsigned(Input5_I))) /  

(unsigned(Input6_I) - unsigned(Input3_I)) ); 

END IF; 

 

END PROCESS; 

END a;
0 Kudos
13 Replies
Altera_Forum
Honored Contributor II
1,561 Views

Remove the useless read_write code.

0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

I understand that the Read_write code is useless there, but the problem is not connected to it. When I remove subtraction operation from the formula, everything goes nicely. Hence, it somehow depends on the subtraction operation.

0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

Timing tools usually check paths between two registers. In your design I can't see any registers.

0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

When I remove subtraction operation from the formula, everything goes nicely. Hence, it somehow depends on the subtraction operation. 

--- Quote End ---  

 

I can't confirm the observation. 

 

The problem in the original design is created as follows: 

Read_Write is an internal self generated signal, that can't be referenced in timing analysis. Thus both the input to Read_Write as well as the Read_Write to output timing can't be analyzed. 

 

Altera timing analysis doesn't recognize, that Read_Write actually violates minimum pulse width and maximum frequency limits and valid design output can't be predicted.
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

Timing tools usually check paths between two registers. In your design I can't see any registers. 

--- Quote End ---  

 

 

This is not exactly true. When you use a process in VHDL design, the synthesizer implements registers for all signals to which an assignment is performed. In other words, an assignment in process is not instant and every signal has a buffer (this differs a signal from a variable). 

 

 

--- Quote Start ---  

I can't confirm the observation.  

--- Quote End ---  

 

 

Consider the following example: 

 

entity (<the same as in the previous example>) 

ARCHITECTURE a OF Component_test_wo_library IS 

SIGNAL Read_Write : STD_LOGIC := '0'; 

BEGIN 

 

Component_test_wo_library: 

PROCESS (Input1_I,Input2_I,Input3_I,Input4_I,Input5_I,Inpu t6_I,Read_Write) IS  

BEGIN 

 

Read: 

IF (Read_Write = '0') 

THEN  

Read_Write <= '1'; 

END IF; 

 

Result: 

IF (Read_Write = '1') 

THEN  

Read_Write <= '0'; 

Result_O <= std_logic_vector( (("0" & unsigned(Input1_I) * unsigned(Input2_I)) + (unsigned(Input4_I) mod unsigned(Input5_I))) /  

--NO SUBTRACTION OPERATION 

unsigned(Input6_I));  

END IF; 

 

END PROCESS; 

END a; 

 

This example compiles without a warning and I get the following worst-case tpd - 63,104ns. However, as soon as I add subtraction, the tool cannot provide me with this info because it thinks that the output is not connected to the inputs. 

 

Therefore, the subtraction operation somehow affects the paths and timing analysis, although RTL viewer shows that everything is connected.
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

This is not exactly true. When you use a process in VHDL design, the synthesizer implements registers for all signals to which an assignment is performed. In other words, an assignment in process is not instant and every signal has a buffer (this differs a signal from a variable). 

 

 

--- Quote End ---  

 

 

 

No Sir, a process creates registers only if you use clock edge.  

A process otherwise produces combinatorial circuit or latches
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

A process otherwise produces combinatorial circuit or latches 

--- Quote End ---  

 

 

Yes. I agree with you that a process creates latches, although a register is a set of latches. In any case, the problem with subtraction operation remains. The tool cannot identify the paths between the output and the input. 

 

Is it somehow possible to set the paths manually?
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

This example compiles without a warning and I get the following worst-case tpd - 63,104ns. However, as soon as I add subtraction, the tool cannot provide me with this info because it thinks that the output is not connected to the inputs. 

--- Quote End ---  

 

I still get the same warning with the new architecture code. (Quartus 9.0, Classical Timing Analyzer, Cyclone III). 

 

--- Quote Start ---  

Warning: No paths found for timing analysis 

--- Quote End ---  

 

You'll notice that you aren't able to define "Read_Write" as a clock, neither in Classical Analyzer nor Time Quest, apparently because it's an internal signal of unknown timing. If you make it an external input, timing analysis works.
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

An obvious issue in this post is that the problem should not be about chasing timing paths but about design itself: 

 

Firstly, the computation of multiply,add,divide,subtract and modulus requires careful breakdown of these processes into several pipe stages.  

 

Secondly, there is no clock and no clock edge process. The attempt to do that in the following code: 

 

if read_write = '0' then 

read_write <= '1'; 

end if; 

 

if read_write = '1' then 

read_write <= '0'; 

end if; 

 

 

produces an oscillatory signal that can't be useful in FPGAs 

 

The term register in FPGAs is used to mean clocked flipflop. The term latch is used to mean a flipflop without clock-unlike academic definition of register.
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

I think, I have figured out what the problem is. Truly, the problem does not depend on a particular operation (e.g., subtraction). It rather depends on the "length" of equation. I have tried different combinations of the operations. As long as I have 4 operations, the project compiles successfully with the settings I have in Quartus-II ver 9.1. However, as soon as I add one operation more, the tool fails. Furthermore, if I split up the equation into two processes as was proposed by kaz, then no problem with extra operations occurs. 

 

--- Quote Start ---  

I still get the same warning with the new architecture code. 

--- Quote End ---  

I think, FvM experienced the same issue when tried compiling the simplified example.  

 

Therefore, it seems there is some preference or limitation for timing analyser on the length of operations involved in one formula. 

 

Thank you for helping me with this issue!
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

I have conducted a few more experiments just to be sure that the problem is in the tool. Indeed, the tool calculates a worst-case tpd following some formula that takes tpd of every operation involved in calculations, e.g., tpd=(n-1)*(tpd,or+tpd,and) or the like. 

 

For instance, if I try the following code: 

 

PROCESS (Input_I,Read_Write) IS  

BEGIN 

 

Read: 

IF (Read_Write = '0') 

THEN  

Read_Write <= '1'; 

END IF; 

 

Result: 

IF (Read_Write = '1') 

THEN  

Read_Write <= '0'; 

Result1_O <= not Input_I; 

END IF; 

 

the tool cannot process it because there is no information about tpd of bitwise not operation in a process. Since the subtraction operation is performed as an addition of two's complement (a-b=a+not(b)), the tool cannot calculate tpd for this expression. Furthermore, it does not depend on a device family as I have tried different ones and have got the same result. However, the tool works fine for other operations logical, arithmetical etc.
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

To check your assumptions about the cause of timing analysis failure, please compile the below modified code. You'll notice that timing analysis works as soon as the latch is controlled by a signal of known timing. 

 

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.NUMERIC_STD.ALL; ENTITY no_timing IS PORT ( Read_Write2 : STD_LOGIC; --Input ports Input_I : IN STD_LOGIC_VECTOR(7 DOWNTO 0); --Output ports Result_O : OUT STD_LOGIC_VECTOR(7 DOWNTO 0) ); END; ARCHITECTURE a OF no_timing IS SIGNAL Read_Write : STD_LOGIC := '0'; BEGIN PROCESS (Input_I,Read_Write) IS BEGIN IF (Read_Write = '0') THEN Read_Write <= '1'; END IF; --IF (Read_Write = '1') IF (Read_Write2 = '1') THEN Read_Write <= '0'; Result_O <= not Input_I; END IF; END PROCESS; END;
0 Kudos
Altera_Forum
Honored Contributor II
1,561 Views

 

--- Quote Start ---  

You'll notice that timing analysis works as soon as the latch is controlled by a signal of known timing. 

--- Quote End ---  

Yes, I agree with you and the example you have proposed works. Somehow, the tool can calculate timing for every operation but the "not" one unless the timing is controlled explicitly.
0 Kudos
Reply