TimeQuest Data-Required Time Appears Incorrect

[Altera_Forum]

I am very motivated to get a good grasp of the TimeQuest Timing Analyzer. Unfortunately, while going through a very simple project on my De0-Nano board (Cyclone IV), I have ran into a few issues that I can't seem to understand. The problem is that the setup summary report in the TimeQuest GUI shows the data-required time to be after the next rising edge... It seems to me that the data-required time should be some time before (Tsu) the next rising edge. Obviously this issue is giving me incorrect slack times. 

 I am running a Slow-Corner Delay Model of a Post-Map Netlist Here is my Top Level VHDL Code:# ############################################################## library ieee; use ieee.std_logic_1164.all;   entity TimingTutorial is port ( CLK_50 : IN std_logic; LED : OUT std_logic_vector(7 downto 0) := (others => '0'); SW : IN std_logic_vector(3 downto 0) ); end TimingTutorial;   architecture behavior of TimingTutorial is signal SW_reg : std_logic_vector(3 downto 0);  begin  process(CLK_50) begin if rising_edge(CLK_50) then   SW_reg <= SW; end if; end process;   process(CLK_50) begin  if rising_edge(CLK_50) then   LED(0) <= (SW_reg(3) AND SW_reg(2)) AND (SW_reg(1) AND SW_reg(0));  end if; end process;   end behavior;# ##############################################################   And Here is my SDC file:# ############################################################### Base Clock For Design# (include virtual clock as well because Altera training says you need it for derive_clock_uncertainty to work correctly??) create_clock -name Clk_50 -period 20.000 [get_ports {CLK_50}] create_clock -name Clk_50_virt -period 20.000# Add in clock uncertainty for more accurate timing analysis derive_clock_uncertainty# ##############################################################  And I have attached an image of the Waveform that doesn't make sense to me

[Altera_Forum]

I don't see how you arrived at your conclusion?

[Altera_Forum]

--- Quote Start ---  I don't see how you arrived at your conclusion?  --- Quote End ---    In the attached PDF the highlighted green area represents the setup slack time. It does not make sense for this area to extend past the next rising edge. In other words, I don't understand why the data required time is AFTER the latch clock rising edge for satisfying setup time requirements. Perhaps there is some element of preparing the timing report that I am overlooking?

[Altera_Forum]

--- Quote Start ---  In the attached PDF the highlighted green area represents the setup slack time.   --- Quote End ---   The pdf is not showing enough details. if green area is slack then you got 19.38 ns of positive slack i.e. data settles at 19.38 ns before latch edge.      --- Quote Start ---  In other words, I don't understand why the data required time is AFTER the latch clock rising edge for satisfying setup time requirements. Perhaps there is some element of preparing the timing report that I am overlooking  --- Quote End ---  .  you need to show the launch and latch edges on waveforms. I think your observation and conclusion are not right.

[Altera_Forum]

Whoops! Sorry about that. My picture resized to fill the page when I printed to pdf. Here is the waveform in its entirety (I've also changed the attached waveform in the original post).

[Altera_Forum]

so you do have 19.38 +slack 

 The required time is drawn relative to clk delays while clk waveform is fixed to start at zero time (yes a bit confusing but I understand TQ does that to fit image)

[Altera_Forum]

Ahhh okay. So if the Clocks were shifted to reflect the clock delay then it would align with my expectations. Seems quite odd that TQ does this, but at least now I know! Thanks very much Kaz you have been quite helpful.

[Altera_Forum]

See this online training that goes into the details of data arrival time, data required time (based off of clock delay to the destination register), and slack calculations: 

 https://www.altera.com/support/training/course/odsw1115.html