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

[Altera_Forum]

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?

[Altera_Forum]

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]

ModelSim or Quartus Simulator?

[Altera_Forum]

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]

--- 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?

[Altera_Forum]

--- 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]

--- 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]

--- 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]

--- 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]

--- 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]

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.

[Altera_Forum]

Do you mean that post-fit includes the timing infromation, despite of the "Functional Simulation Only" option in netlist writer?

[Altera_Forum]

--- Quote Start ---  Do you mean that post-fit includes the timing infromation, despite of the "Functional Simulation Only" option in netlist writer?  --- Quote End ---   Most likely not if explicitely set. I asked, because functional simulation of post-fit netlist seems unusual to me. I only used it for timing analysis. The question is however, which difference in the netlist can change execution sequence in functional simulation?.

[Altera_Forum]

Have you tried doing this again without using the buffer port type? Its hardly used by anyone, and not really the standard way to create output registers. Usually you would use an internal signal to store the value and assign an output to the internal signal. Another thing I notice is that in your code you have 2 separate if statements resetting the counter. It would be more common to use something like:  

if CNT= 1000 or START = '1' then CNT <= 0; else CNT <= CNT + 1; end if;

[Altera_Forum]

@Tricky: I don't see, why the said constructs, that are legal and well-defined VHDL code, should change the synthesis result. 

 Regarding negative integers, I understood a bit more when reviewing your post. The integer signal has to be converted to a numerical bit-vector during synthesis. One should expect integer range 0 to 1000 to be converted to unsigned(9 downto 0). Quartus generally accepts integer signals, also for ports, and generates correct code for it. They are even suggested in the Quartus language templates. But in the said case, Quartus converts the integer apparently to a signed signal: CNT <= IEEE.STD_LOGIC_ARITH.CONV_INTEGER(SIGNED(ww_CNT)); That's no problem in logic synthesis, because the bit-vector is identical. But the simulator stumbles upon it. It may be necessary to change to an unsigned port signal for simulation of Quartus post-fit netlists.