Timequest Source Synchronous interface - Implicit Method

[Altera_Forum]

Please help with this example. Trying not to assume much and hoping to learn a lot. After studying the TimeQuest User Guide and Source Synchronous Timing by Ryan, I'm trying to follow the Implicit Method since the clock is from an internal PLL, but not in compensation mode and with no phase shift. The data bus is bidirectional, data is clocked into FPGA on the falling edge of an 8MHz clock and output on the rising edge (read/write cycles are independent of each other). The clock is sent out to the external device. So as long as I've identified the data sheet Tsu's and Th's correctly, the basic constraints for analyzing the data I/O's might look like this: 

 create_clock -name {sys_clk} -period 25.000 -waveform { 0.000 12.500 } [get_ports {Clk40MHz}]# base FPGA clock create_clock -name {datain_clk} -period 125.000 -waveform { 31.250 93.750 }# virtual clock for input data  create_generated_clock -name {clk_8} -source [get_pins {uPLLs|altpll_component|auto_generated|pll1|inclk[0]}]  -duty_cycle 50.000 -multiply_by 1 -divide_by 5 -master_clock {sys_clk} [get_pins {uPLLs|altpll_component|auto_generated|pll1|clk[4]}]  derive_clock_uncertainty # ##max in delay = (1/2 clock period - Data sheet Tsu) --(Tsu is T19 (21ns) in data sheet, 41.5= 62.5 - 21 ns)# ##min in delay = -(Data sheet Th) --(Th is T21 in data sheet, 37 ns)  set_input_delay -max -clock_fall -clock [get_clocks {datain_clk}] 41.5 [get_ports {DATA [*]}] -- <<<< Do These values look large? >>>> set_input_delay -min -clock_fall -clock [get_clocks {datain_clk}] -37 [get_ports {DATA [*]}] # ##max out delay = Data Sheet Tsu --(Tsu is T3 in data sheet, 3 ns)# ##min out dealy = -(Data sheet Th) --(Th is T4 in data sheet, 2 ns) set_output_delay -max -clock [get_clocks {clk_8}] 3 [get_ports {DATA [*]}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {DATA [*]}]  First, does this approach make sense? note, clk_8 and datain_clk are really the same thing, where datain_clk <= clk8MHz; happens asynchronously. Also what about the chip select and WR/RD, mode select signals to the device, should be constraining those too?  Using Quartus 13.0 64-bit; Cyclone IV E. I looked over many forum posts on multiple vendor sites, read many Altera docs and books on philosophy in addition to the guides mentioned above. Thanks in advance for any helpful guidance -- DL

[Altera_Forum]

Just taking a quick look and it looks good, but: 

- Your input delay constraints are based on a Tsu and Th. Is that of the FPGA's report_datasheet? The constraints should really be based on the external device's specs. (It may be that the external device is saying, "My outputs can meet a Tsu of 21ns", in which case what you're doing is correct, but just checking). - One thing that is wrong is using clk_8 on your output constraints. You need to add: create_generated_clock -name clk_8_out -source [get_pins {uPLLs|altpll_component|auto_generated|pll1|clk[4]}] [get_ports CLK_OUT] Then use clk_8_out for the -clock option in set_output_delay. If you don't do this, TimeQuest doesn't know how the clock gets out and your Data Arrival Path will show the clock coming into the FPGA, going through the PLL and to its output, but not the rest of the path through the global clock tree and output buffer, so the analysis is very wrong. (I wish TQ would error out about this, but there are supposedly some weird scenarios where someone might do this) What are the constraints on chip select and wr/rd? Often they're similar to the data(or they're less restrictive, and sometimes users constraint them just like the data because it's easy)  I'm glad you're reading everything you can, but concerned static timing analysis has driven you to reading books about philosophy. : )

[Altera_Forum]

Thanks for the reply 

  --- Quote Start ---  The constraints should really be based on the external device's specs  --- Quote End ---   I used something from the data sheet timing spec described as "Enable delay /RD low to data valid" -- I took that as "external device output data Tsu" My "output Th" from the external chip was described as "A0/A1 (mode select) set time to data valid when /RD low" Maybe these are not really Tsu/Th, I'm not totally comfortable with the choice, but seemed the most relevant thing in the data sheet.    --- Quote Start ---  One thing that is wrong is using clk_8 on your output constraints. You need to add: create_generated_clock -name clk_8_out -source [get_pins {uPLLs|altpll_component|auto_generated|pll1|clk[4]}] [get_ports CLK_OUT]   --- Quote End ---   The create_generated_clock command was generated by TQ after I ran the derive_pll_clocks command. I let TQ write the *.out.sdc file and I copied that text back into my working sdc. 'clk_8' is not a design element but just me renaming the pll clock for brevity in TQ reports. In the HDL, the PLL output is assigned as clk8mhz and then asynchronously passed to an I/O called DATA_CLK to go out to the external chip. It looks like you're saying to grab the PLL output as -source and then the I/O pin as the target, but when I do this TQ gives me PLL cross checking errors, wants to see the base clk40mhz as the base. [Node: uPLLs|altpll_component|auto_generated|pll1|clk[4] was found missing 1 generated clock that corresponds to a base clock with a period of: 25.000]    --- Quote Start ---   What are the constraints on chip select and wr/rd?   --- Quote End ---   I tried to tie everything to a value in the data sheet. I need a sanity check on these numbers so I'm attaching the data sheet:  set_output_delay -max -clock [get_clocks {clk_8}] 5 [get_ports {DATA_Clk}] -- guess set_output_delay -max -clock [get_clocks {clk_8}] 2 [get_ports {CS_N}] -- Tsu/Th is T5 in data sheet set_output_delay -max -clock [get_clocks {clk_8}] 2 [get_ports {Rd_N}] -- Tsu/Th is T13/T18 in data sheet set_output_delay -max -clock [get_clocks {clk_8}] 2 [get_ports {Wr_N}] -- followed Rd_N, as a guess set_output_delay -max -clock [get_clocks {clk_8}] 2 [get_ports {MODE_A0}] -- Tsu/Th is T1/T8 in data sheet set_output_delay -max -clock [get_clocks {clk_8}] 2 [get_ports {MODE_A1}] set_output_delay -min -clock [get_clocks {clk_8}] -5 [get_ports {DATA_Clk}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {CS_N}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {Rd_N}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {Wr_N}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {MODE_A0}] set_output_delay -min -clock [get_clocks {clk_8}] -2 [get_ports {MODE_A1}]  Does it look like the data sheet timing is being applied correctly? Do the data bus input delays make sense? Then, what are my requirements for the output clock DATA_CLK? (The timing specs appear on p.6 of the data sheet)

[Altera_Forum]

Note that you'll have two generated clocks, one that constrains the PLL output and one that constrains DATA_CLK in relation to the PLL output. I believe if you have both the PLL cross checking warning should go away. 

 Data sheets can be a complete pain to go through. I've had occasions where we can't really decipher them(or the user expects me to), and I've had to say they need to ask the vendor for clarification. Sorry, but I'm swamped right now and just don't have time to go through it. Hopefully someone else on the forum can help.

[Altera_Forum]

Thanks again for the replies and help. And fair enough regarding the data sheet. 

 Now I see that you were suggesting to add the create_generated_clock command, rather than modify the existing. Yes that works, errors are gone. I suppose this would be the same strategy to use with other output clocks (I have 4 source synchronous interfaces to constrain). This seems to work except with the SPI clock I'm sending to an ADC. TQ tells me that it does not see a path to target SPI_CLK.  The 20Mhz PLL output is further divided to 10Mhz using SPI_CLK_int <= not SPI_CLK_int inside a 20Mhz process. This is passed asycnronously to SPI_CLK. The toggling is enabled periodically when adc reads occur. So in this case how do I target the output SPI_CLK?