Defining I/O delay constraints (Timequest)

[Altera_Forum]

I'm currently writing timing constraints for my design and, since it's the first time for me with such a big project, I'm having some problems at doing it. I'm using Timequest Timing Analyzer and I've already taken a look to the Rysc user guide on alterawiki (which I found anyway a really helpful first step). My questions are the following: 

 _In the TimeQuest User Guide, p. 19, with reference to the previously discussed commands: "set_output_delay -clock dac_clk_ext -max 0.0 [get_ports DAC_DATA[5]] set_output_delay -clock dac_clk_ext -min 0.0 [get_ports DAC_DATA[5]]" it is said:  "With both -max and -min at 0, we are stating that there are no external delays, and basically have no affect on the analysis." In my understanding, I would expect these commands to already say that those ports are synchronous to dac_clk_ext clock, so default setup and hold relationships should be applied as the sink registers were into the FPGA. I suppose I'm wrong, but where?  _I've got a source synchronous output interface (to the LTM by Terasic): it is a RGB interface and I generate the 33.2 MHz clock I need from the 50 MHz on board clock through a PLL. This clock signal is sent to the sink, controlling the timing of the other interface signals. I should put this clock signal in the -clock field of the I/O delay assignments, although it is not virtual as in Rysc example, right? My clock signal is in reality generated through a NOT gate from the PLL output: I should use the command create_generated_clock for describing it, right?  _My design has a module controlling the I/O interface with on-board SRAM, which works as a frame-buffer. I'm currently writing to SRAM at 50 MHz (which is my Qsys clock frequency) and reading from SRAM at 33.2 MHz (which is my LCD clock frequency). So I've got my address output which works alternatively at 50 MHz and 33.2 MHz, depending on the current state of a FSM into the module. How can I constrain this output?  Thank you in advance for any help you will give me.  Regards, Lorenzo

[Altera_Forum]

Take a look at the following: 

http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest For a quick overview... Put a generated clock on the output port that sends the clock off chip, where the source is the PLL output clock. Use that for the -clock option in your set_output_delay. You probably need to add a -invert option to account for your not gate, but double-check your setup and hold margins. I assume your setup relationship should be half a clock period(10ns) and your hold should be negative half a clock period(-10ns). That basically means your data path can vary by +/-10ns and still meet timing. Then add in your external delays to show how much of that margin is chewed up externally.  Also, make sure you run report_timing -detail full_path to the output ports, and make sure your latch clock traces all the way through the FPGA, from the oscillator coming in, through the PLL, through the global, and out your output port. If you see that, then your generated clock is correct(also need to verify the -invert). As for the read, I'm not sure how you're switching between 50MHz and 33Mhz, but generally you do a set_input_delay where the -clock is the same clock being sent off chip. Your -max value is the total external roundtrip delay max, and the -min is the minimum for this delay.  Again, that's the quick and dirty write-up. Good luck.

[Altera_Forum]

--- Quote Start ---  _In the TimeQuest User Guide, p. 19, with reference to the previously discussed commands: "set_output_delay -clock dac_clk_ext -max 0.0 [get_ports DAC_DATA[5]] set_output_delay -clock dac_clk_ext -min 0.0 [get_ports DAC_DATA[5]]" it is said:  "With both -max and -min at 0, we are stating that there are no external delays, and basically have no affect on the analysis." In my understanding, I would expect these commands to already say that those ports are synchronous to dac_clk_ext clock, so default setup and hold relationships should be applied as the sink registers were into the FPGA. I suppose I'm wrong, but where?  --- Quote End ---    The set_output_delay constraint describes what happens to the signal once it leaves the chip, using an "ideal" reference. With the constraint above you're telling that the signal DAC_DATA[5] - after it leaves the FPGA pin, the signal will go through a zero delay - and then it will be captured at the instant of the rising edge of dac_clk_ext  Ie, you're describing an ideal system where  - there's no delay from the FPGA pin to the DAC pin - there's no delay from the source* of the dac_clk_ext to the DAC's clock pin - the DAC input has zero tSU and zero tH   * source, as specified in the create_clock/create_generated_clock constraint.

[Altera_Forum]

Hi Rysc, I didn't know about the existence of the document you linked and I thought you left the source-synchronous interfaces argument not discussed yet. Anyway, as I start reading your document, I see that it is not so easy as I supposed.  

Maybe I'll clarify my ideas and I'll ask more.  Hi rbugalho, thank you for the explanation: I'm getting it now.  For this moment, I have just another short question: since the whole peripherals on the DE2-115 board are clocked through the FPGA, I suppose that every synchronous interface I'm dealing with (e.g., FLASH, SDRAM, etc.) is a source synchronous one, isn't it right?  Thank you for your help.  Regards, Lorenzo

[Altera_Forum]

Most likely.  

Source synchronous is surprisingly complex, but I think a lot of that is due to the various situations that can occur. My document is long, but the main bulk deals with four different situations(receiver or transmitter and if the FPGA phase-shifts the clock or not). It then covers a different way of analyzing them that some users like. That's six different cases, whereby you'd really only have to read one of them for a particular interface. They're also very similar too, so once you get the hang of it, hopefully the rest go easily. I believe there is a "quick and dirty" description early on too. Finally, I realized the altddio blocks are erroring out in Quartus 11.1 when compiling, so if you look at a sample project, you just have to re-generate these blocks. I need to go back in and do this myself and update the example files.

[Altera_Forum]

I'm constraining my output RGB interface (33.2 MHz) and that should be kind of easy.  

I checked the setup and hold relationships through waveforms in TQ and they should be ok (my latch clock is produced directly from the launch clock through a NOT gate and I can see the inversion).  I could find Tsu and Th for my receiving device (they're both 5 ns); for determining my -max and -min output delay value I have to account for delay through the data path and the clock skew.  My datas travel on an ATA cable along with the clock, so I have to suppose that the data delay from the FPGA board to the receiver is almost the same of my clock delay. So I could avoid to estimate these probably long delays (which should compensate on both paths) and I should instead estimate my delays as my receiving register was on board, where my GPIO socket is, right? Sorry for the probably stupid questions but I would need a feed to understand if I'm getting correctly the terms of the problem. Anyway, thank you in advance.  Regards, Lorenzo