awkward result in post implementation timing simulation

[askhunter]

Hi,

I design a module for rgbtogrey.  When i start  post implementation timing simulation,I get the following result.(gryodata) 

Everything was seamless until post implementation timing simulation, but here I came across something like this.

I would be very happy if someone could help me with this subject.

 

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.types.all;

entity rgb2grey is
                        Port (  
                               clk      : in std_logic;
                               active_i : in std_logic;
                               active_o : out std_logic;
                               rgb_in   : in  std_logic_vector(23 downto 0);
                               gry_o    : out std_logic_vector(7 downto 0)                             
                             );
end rgb2grey;

architecture Behavioral of rgb2grey is

signal active,active2,active3,active4: std_logic:='0';
--signal temp_gry,temp_gry2,temp_gry3,temp_gry4 : std_logic_vector(7 downto 0):=(others=>'0');
signal temp_gry,temp_gry2,temp_gry3,temp_gry4,tempy_reg,temp_son : integer:=0;

  --temp_gry<= std_logic_vector(to_unsigned((to_integer(unsigned(rgb_in(7 downto 0))) + to_integer(unsigned(rgb_in(15 downto 8))) + to_integer(unsigned(rgb_in(23 downto 16))))/3,8));

BEGIN
    process(clk)
    begin
        if rising_edge(clk) then
            if active_i='1' then
                temp_gry<= to_integer(unsigned(rgb_in(7 downto 0)))/3;
                temp_gry2<=to_integer(unsigned(rgb_in(15 downto 8)))/3;
                temp_gry3<=to_integer(unsigned(rgb_in(23 downto 16)))/3;
                active<='1';
            else
                active<='0';
            end if;
            temp_gry4<=temp_gry+temp_gry2;
            tempy_reg<=temp_gry3;
            temp_son<=temp_gry4+tempy_reg;
            gry_o<=std_logic_vector(to_unsigned(temp_son,8));
            
            active2<=active;  
            active3<=active2;
            active4<=active3;

            end if;
    end process;              
--        gry_o<=temp_gry3;

        active_o<=active4;
        
end Behavioral;

 

[zygot]

@askhunter

It's not clear from your pictures what it is that you are referring to since the times scales are different. The purpose of post place and route timing simulation is to show the relative signal path delays in your implemented design as well as possible inferred latches or registers hidden by IP. The RTL simulation merely indicates if your behavioural logic is performing as you intended ( assuming that the testbench is well designed ). It is merely a simplified (no delays, no setup, no hold times) idealistic representation of simple logic. If the timing simulation doesn't give the same results as the RTL simulation then it's unlikely that your hardware will behave as you intend either. 

In the typical professional setting a lot of people are working on parts of a large design effort simultaneously. No one can afford to schedule a design effort where everything is done sequentially. In such a case timing simulations become a very important indicator of risks of projects not making deadlines. It simply isn't possible to create a lot of hardware, software, test protocols etc sequentially or even in parallel and 2 weeks before shipment throw all that stuff together for the first time and then figure out why things don't work. So we have a lot of ways to do simulation that offer increasingly more accurate, and hence reliable, views of how our design ( after it's been optimized, re-worked and reduced to LUT equations ) might actually work in a system before having to run it in hardware. When there are 10 engineers doing parts of 1 large FPGA design and all of those parts are integrated it's not uncommon for some of them to start failing due to limited routing resources and clock line limitations.

[askhunter]

these two photos maybe a little more revealing about my problem.

[zygot]

Am I correct in assuming that there is no testbench and that rgb2grey is your toplevel entity? That is you just let Vivado decide how to simulate rgb2grey?

Did you have a timing constraint for the clk period when you implemented the design? Was the timing score 0?

Now that I'm trying to read your code the organization needs work. Why is all of your logic in one process? Why is the process creating output when active_i is de-asserted?

Also, I'm curious as to your reasoning for changing your internal registers to type integer from std_logic_vector.

Lastly, I'm having a hard time correlating the simulation waveforms to your code. I don't see a rst or 24-bit output in your code.

[fpga_babe]

It appears to me that it is normal behavior with implementation design.

In RTL simulation, there is no gate delay. All logic gate operate without any delay from its input to output ports.

However, the delay is attached on simulation with delay on inplemetation design. That is why you can see that each bit of a bus signal will have different propagating time. It called "skew" sometimes in layout design. If there is no timing volation on your design, then there would be no problem with this.

 

[zygot]

9 hours ago, fpga_babe said:

If there is no timing volation on your design, then there would be no problem with this.

You're not following my approach to answering the question. There are a number of problems with the code under discussion. Perhaps you might want to try implementing this code and seeing what happens... or you could just provide your own answer.

[fpga_babe]

3 hours ago, zygot said:

You're not following my approach to answering the question. There are a number of problems with the code under discussion. Perhaps you might want to try implementing this code and seeing what happens... or you could just provide your own answer.

Hi, 

My thought is that the question may related to the skew between signals in a bus.

Sorry if I am out of the real issue from the first post. But we need him/her to confirm the issue more clearly.

- What is the problem ?

- output data is wrong ? 

- timing of signal are wrong ? 

...

[zygot]

1 hour ago, fpga_babe said:

My thought is that the question may related to the skew between signals in a bus.

I think that I see larger problems than simple timing (routing) issues. If the person asking the question isn't going to interact then I'm happy to move onto other issues. I'm pretty sure that this code doesn't run at 125 MHz as written which is where I thought the discussion should start. There's no sense in doing a timing simulation if the place and route tool reports failing paths. Not everyone asking for help wants to participate in an interactive form of discussion. That's fine; I've got plenty of other things to do.

Most people who post to this site simply want someone to fix their code. I'm willing to help them correct a lack of understanding or ignorance of underlying concepts that lie deep beneath the surface; that way they can fix their own code. This requires an effort and some work on their part; enlightenment is a complicated process. Seems like a reasonable deal to me. You can spend a lot of money getting far worse guidance.