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連結已複製
--- 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?
--- 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.
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.
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