UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
134 Views
Registered: ‎07-26-2018

awkward result in post implementation timing simulation

Jump to solution

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.

gryooo.JPGgryyyyyooo.JPG

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;
0 Kudos
1 Solution

Accepted Solutions
Scholar richardhead
Scholar
108 Views
Registered: ‎08-01-2012

Re: awkward result in post implementation timing simulation

Jump to solution

These are glitches, and are expected. The path length of each bit on a bus will vary, and so each bit changes at a different time. As long as the design meets the timing specs (specifically the setup/hold time) then there is no problem. What you see are the bits all changing at different times after the clock edge (the setup time) and they are ready well before the next edge (hold time).

2 Replies
Contributor
Contributor
115 Views
Registered: ‎07-26-2018

Re: awkward result in post implementation timing simulation

Jump to solution

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

0 Kudos
Scholar richardhead
Scholar
109 Views
Registered: ‎08-01-2012

Re: awkward result in post implementation timing simulation

Jump to solution

These are glitches, and are expected. The path length of each bit on a bus will vary, and so each bit changes at a different time. As long as the design meets the timing specs (specifically the setup/hold time) then there is no problem. What you see are the bits all changing at different times after the clock edge (the setup time) and they are ready well before the next edge (hold time).