Can you tell me why post-fit (quartus_fit) mismatches the post-synthesis (quartus_map) simulation? I had a design with counter. A test bench waits for CLK to release the reset. This works in post-synthesis. But a delay after clock edge is needed to reset the post-fit counter. How is it possible?

Here is an example. The synthesized counter first library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity BIST is port ( clk, start: std_logic; CNT: buffer integer range 0 to 1000 ); end BIST; architecture RTL of BIST is begin FF: process (CLK) begin if Rising_Edge(Clk) then if CNT = 1000 then CNT <= 0; else CNT <= CNT+1; end if; if START='1' then CNT <= 0; end if; end if; end process; end RTL; and the verification test bench: library IEEE, POST_SYNth_CUT; use IEEE.STD_LOGIC_1164.ALL; entity VERIF_TB is end VERIF_TB ; architecture BEH of VERIF_TB is signal CLK: std_logic; constant PERIOD: TIME := 10 ns; signal START: std_logic; begin FUNC: entity WORK.BIST port map( CLK => CLK, START => START, CNT => open ); PS: entity post_synth_CUT.BIST port map( CLK => CLK, START => START, CNT => open ); CLOCK : process begin CLK <= '0'; wait for 85*PERIOD/100; CLK <= '1'; wait for 15*PERIOD/100; end process; START_PROC: process begin START <= '0'; for cycle_cnt in 0 to 20 loop wait until CLK = '1'; end loop; -- wait for 1 fs; -- add a delta dealy START <= '1'; -- pulse start wait until CLK = '1'; START <= '0'; wait; end process; end BEH; On the 21th count (clock period), the start is made high. On the next clock, count is zero, therefore. But, it is not in the post-fit simulation. The post-fit becomes 20->0 instead of taking value 21 as expected and as RTL and post-synthesis do. It seems that post-fit process, on clock edge, takes the start <= '1' that is raised after clock. It does not appear correct. If TB delays the start by a moment then both counters are synchronous. Is it because I use "9.1 Build 222 10/21/2009 SJ Web Edition" or Stratix II EP2S15F484C3? Simulator goes crazy?

I think, setting CLK and other input signals simultaneously doesn't create a valid timing, neither for a real device nor in simulation. It's normal behaviour to get differences in simulation behaviour in case of timing violations. Unless intended to reveal existing timing problems, test benches should use a robust, unequivocal timing in my opinion.

--- Quote Start --- ModelSim or Quartus Simulator? --- Quote End --- It is ActiveHDL 7.2. But, I do nor remeber if I had any problems with either Xilinx or functional simulation. if I define the small range counter CNT: buffer integer range 0 to 1 the post-fit will not even compile because of # Compile Error: Explicit type conversions are allowed between closely related types only.at line CNT <= IEEE.STD_LOGIC_ARITH.CONV_INTEGER(SIGNED(ww_CNT));Range 0..2, CNT: buffer integer range 0 to 2compiles but crushes in simulation RUNTIME Fatal Error: Value -2 out of range (0 to 2). on the same line. Even the initial value CNT: buffer integer range 0 to 2:= 0does not change the things. Where the negatives comes from? Either I do not understand something or there are more problems with Altera fitter than those related to delta delay. The RTL and post-synth still run somoothly. --- Quote Start --- setting CLK and other input signals simultaneously doesn't create a valid timing --- Quote End --- Where do you see them changed simultaneously?

--- Quote Start --- ModelSim or Quartus Simulator? --- Quote End --- ModelSim is in conspiracy with Active-HDL -- they show absolutely the identical results: boht the delta-delay and negative values appearing in post-fit! And, latest, SP2, WebEdition of Quartus is not better.

'Post-map' matches 'rtl functional' but differs from 'post-fit'

14 Replies

Altera_Forum

Honored Contributor

15 years ago

Here is an example. The synthesized counter first


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;   
entity BIST is
    port (         
        clk, start: std_logic;
        CNT: buffer integer range 0 to 1000
    );
end BIST;
    
architecture RTL of BIST is
        begin
            
            FF: process (CLK)
            begin
                
                if Rising_Edge(Clk) then              
                    
                    if CNT = 1000 then
                        CNT <= 0;
                    else
                        CNT <= CNT+1;
                    end if;
                    
                    if START='1' then
                        CNT <= 0;
                    end if;
                    
                end if;
        
            end process;
            
        
end RTL;

and the verification test bench:


library IEEE, POST_SYNth_CUT;
use IEEE.STD_LOGIC_1164.ALL;  
entity VERIF_TB   is
end VERIF_TB  ;
architecture BEH of VERIF_TB  is
    signal CLK: std_logic; 
    constant PERIOD: TIME := 10 ns;
    signal START: std_logic;
    
begin
    
    
    FUNC: entity WORK.BIST
    port map(    
            CLK => CLK,
            START => START,
            CNT => open
    );
    PS: entity post_synth_CUT.BIST
    port map(
        CLK => CLK,
        START => START,
        CNT => open
    );
    
    CLOCK : process     
    begin
        CLK <= '0'; wait for 85*PERIOD/100;
        CLK <= '1';    wait for 15*PERIOD/100;
    end process;
    
    
    START_PROC: process
    begin 
        
        START <= '0';
        for cycle_cnt in 0 to 20 loop
            wait until CLK = '1';
        end loop;
        -- wait for 1 fs; -- add a delta dealy
        
        START <= '1';       -- pulse start
        wait until CLK = '1';
        
        START <= '0';
        wait;  
    end process;
    
    
end BEH;

On the 21th count (clock period), the start is made high. On the next clock, count is zero, therefore. But, it is not in the post-fit simulation.

The post-fit becomes 20->0 instead of taking value 21 as expected and as RTL and post-synthesis do. It seems that post-fit process, on clock edge, takes the start <= '1' that is raised after clock. It does not appear correct.

If TB delays the start by a moment then both counters are synchronous.

Is it because I use "9.1 Build 222 10/21/2009 SJ Web Edition" or Stratix II EP2S15F484C3? Simulator goes crazy?

Altera_Forum
Honored Contributor
15 years ago
ModelSim or Quartus Simulator?
Altera_Forum
Honored Contributor
15 years ago
I think, setting CLK and other input signals simultaneously doesn't create a valid timing, neither for a real device nor in simulation. It's normal behaviour to get differences in simulation behaviour in case of timing violations. Unless intended to reveal existing timing problems, test benches should use a robust, unequivocal timing in my opinion.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
ModelSim or Quartus Simulator?
--- Quote End ---
It is ActiveHDL 7.2. But, I do nor remeber if I had any problems with either Xilinx or functional simulation.

if I define the small range counter
CNT: buffer integer range 0 to 1
the post-fit will not even compile because of
# Compile Error: Explicit type conversions are allowed between closely related types only.
at line
CNT <= IEEE.STD_LOGIC_ARITH.CONV_INTEGER(SIGNED(ww_CNT));
Range 0..2,
CNT: buffer integer range 0 to 2
compiles but crushes in simulation
RUNTIME Fatal Error: Value -2 out of range (0 to 2).
on the same line. Even the initial value

CNT: buffer integer range 0 to 2:= 0
does not change the things.

Where the negatives comes from? Either I do not understand something or there are more problems with Altera fitter than those related to delta delay. The RTL and post-synth still run somoothly.

--- Quote Start ---
setting CLK and other input signals simultaneously doesn't create a valid timing
--- Quote End ---
Where do you see them changed simultaneously?
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
ModelSim or Quartus Simulator?
--- Quote End ---

ModelSim is in conspiracy with Active-HDL -- they show absolutely the identical results: boht the delta-delay and negative values appearing in post-fit!

And, latest, SP2, WebEdition of Quartus is not better.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
Where do you see them changed simultaneously?
--- Quote End ---

In my understanding, start <= '1' (without the optional timed wait) is generated simultaneously with the clock edge. According to VHDL spec, the simulator may update both processes and the DUT instance in arbitrary order. Only an intentional delay assures a specific order of execution.

The unspecified order problem is present in any functional simulation, I think. In timing (gate level) simulation, the START input may or may not have sufficient hold time related to CLK.

P.S.: I don't exactly understand about the other simulation issues. If you suspect a particular problem with Quartus simulator or design compiler, you should show an example, that allows to reproduce the problem.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
In my understanding, start <= '1' (without the optional timed wait) is generated simultaneously with the clock edge. According to VHDL spec, the simulator may update both processes and the DUT instance in arbitrary order. Only an intentional delay assures a specific order of execution. The unspecified order problem is present in any functional simulation
--- Quote End ---

Perhaps my problem is because Altera people have not heard of the delta delays concept that the whole VHDL simulation is based upon. People must know that an assignment incurs a delta delay.

--- Quote Start ---
If you suspect a particular problem with Quartus simulator or design compiler, you should show an example, that allows to reproduce the problem.
--- Quote End ---
Huh? Try some magnifying glass!
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
People must know that an assignment incurs a delta delay.
--- Quote End ---

Can you please refer to a respective VHDL specification. I'm not aware of it.

--- Quote Start ---
Huh? Try some magnifying glass!
--- Quote End ---

I'm not motivated to assemble snippets.

P.S.: In my understanding, a delta cycle occurs after updating the signals of all processes. I don't see a clear conclusion of this rule affecting the treatment of START in the said case. But I'm not an expert for simulation related VHDL. In synthesized VHDL, the question is meaningless, I think.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
Can you please refer to a respective VHDL specification. I'm not aware of it.

--- Quote End ---

I have never seen the specifictaion. Have you? Nevertheless, VHDL people know that VHDL was designed for simulation. On assignments + delta delay, take a book. (http://books.google.com/books?q=delta+delay+assignment+vhdl&btng=search+books)

--- Quote Start ---
I'm not motivated to assemble snippets.
--- Quote End ---

The "snippets" elaborate anoter, negative values related, issue of post-fit. The solid example of topic issue was given is second post before you responded. The two files cannot be joined just because one is synthesized while another is a test bench.

Thank you for telling that you are motivated only to instruct us in the topic, as you do not stop to confess, you understand weakly.

--- Quote Start ---
In my understanding, a delta cycle occurs after updating the signals of all processes.
--- Quote End ---
After university cource and some experience I was left with the same impression. Unitl, I run into this http://groups.google.ee/group/comp.lang.vhdl/browse_thread/thread/5e5801f51a375fe1 recently.
Altera_Forum
Honored Contributor
15 years ago
After overthinking the problem, I agree, that the testbench generates a delta cycle between CLK rising edge and START assertion. It's apparently working in functional simualtion. But isn't the Active HDL post-fit simulation a timing simulation? In this case, it wouldn't be a problem of delta delays but timing violations related to the actual design timing. In other words, the real synthesized design, if exposing the same timing as the model, has the same problem.

Regarding the negative values problem, I simply wanted to understand, where you see something wrong in the Quartus generated files.

Forum Discussion

'Post-map' matches 'rtl functional' but differs from 'post-fit'

14 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Quartus Dark Theme on Linux - Solution

Error(23098) when using IPM_IOPLL on Agliex 7

Quartus 13.1 License

Highlight similar instances of a selected word fails when scrolling