- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Remove the useless read_write code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Timing tools usually check paths between two registers. In your design I can't see any registers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page