[SOLVED] "Slow Signals" in Timing Simulation - FPGA

[fmaximovic]

Hi all,

I coded a very, very simple 8-bit adder in VHDL and its Behavioral Simulation ran fine. Its Timing Simulation though gave a terrible result: more than 100 ns to perform a sum on a Virtex 6 board (Speed Grade 3); at least, that's what I see from ISim (Xilinx's surrogate for Modelsim).




I did absolutely nothing with Timing Constraints, I mean I don't even know where the defaults ones are; I don't know whether this might be the problem. Same thing for pin assignment or else; I just wrote the code (actually inside a very small schematic) and clicked on Implement and then Timing Simulation.
Synthesis is optimized for speed.

Ah, I said "very simple 8-bit adder", and what I meant was

aws_tmp := (L1(7) & L1) + (L2(7) & L2);
RES_CV <= aws_tmp;

inside a rising clock if statement, with L1 and L2 8-bit input and RES_CV 9-bit output ports. It was just a test.

Thank you in advance for your answers.

 

[FvM]

I wonder about the purpose of a 500 MHz for the design. Which strange constructs are there in addition? How about a hidden reset signal?

The adder and I/O delay would give several ns total delay, Most likely less than 10 ns. Everything else needs to be created intentionally (or possibly inadvertently).

 

[fmaximovic]

Re: &quot;Slow Signals&quot; in Timing Simulation - FPGA

500 MHz was just a tentative clock frequency; could it create problems to the design?

Anyway yes, there's a reset in the code, which is

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;
 
entity STD_ADDER1 is
    Port ( L1 : in  STD_LOGIC_VECTOR (7 downto 0);
           L2 : in  STD_LOGIC_VECTOR (7 downto 0);
           RES_CV : out  STD_LOGIC_VECTOR (8 downto 0);
           EN : in  STD_LOGIC;
           RESET : in  STD_LOGIC;
           CLK : in  STD_LOGIC);
end STD_ADDER1;
 
architecture Behavioral of STD_ADDER1 is
 
begin
    ad1 : process (clk,reset,en)
        variable aws_tmp : std_logic_vector(8 downto 0);
        begin
            if RESET='1' then
                RES_CV<=(others=>'0');
            elsif (CLK'event and CLK='1') then
                if EN='1' then
                    aws_tmp := (L1(7) & L1) + (L2(7) & L2);
                    RES_CV <= aws_tmp;
                end if;
            end if;
        end process;        
end Behavioral;

---

- - - Updated - - -

(Reset is initialized to 0 in the testbench and never changed)

 

[FvM]

I don't work with Xylinx or ISIm, just as a guess: does it possibly model internal power on reset?
I would nevertheless revert to a reasonable clock frequency like 100 Mhz.

To see the actual adder propagation delay, you can use it unregistered and change the input data.

 

[j_andr]

Re: &quot;Slow Signals&quot; in Timing Simulation - FPGA

could you add the "EN" signal to the waveform ?
j.a

 

[fmaximovic]

Re: &amp;quot;Slow Signals&amp;quot; in Timing Simulation - FPGA

could you add the "EN" signal to the waveform ?
j.a

The EN signal is always equal to 1 and never never changes; should I do something with it?

- - - Updated - - -

I don't work with Xylinx or ISIm, just as a guess: does it possibly model internal power on reset?
I would nevertheless revert to a reasonable clock frequency like 100 Mhz.

To see the actual adder propagation delay, you can use it unregistered and change the input data.

I could; but unregistered means... produced by an internal register (like in a component) rather than coming from a pin?

 

[mrflibble]

That just doesn't look right. As suggested reduce the clock to something like 100 MHz. Also add the EN and RESET signals. Yes, even if they don't do something exciting. Maybe even assert and de-assert your RESET just to be sure. And if reset doesn't do anything useful in your opinion, then just get rid of it in the entire module. If it does something useful, then better testbench it.

 

[fmaximovic]

That just doesn't look right. As suggested reduce the clock to something like 100 MHz. Also add the EN and RESET signals. Yes, even if they don't do something exciting. Maybe even assert and de-assert your RESET just to be sure. And if reset doesn't do anything useful in your opinion, then just get rid of it in the entire module. If it does something useful, then better testbench it.

I did change the values of RESET but it didn't help; however, changing the inputs somewhere after 100 ns produced the wanted results (a sum performed in less than 4 ns from the first rising edge).
I have no idea about the reasons of such a long freeze at the start; someone talked about global reset/GRS on Xilinx boards.

Thank you all, I appreciated your help very much.