Source-synchronous constraints with the -reference_pin option

[Altera_Forum]

Hello All, 

 I have a Cyclone III with a large number of source-synchronous inputs and outputs that need to be constrained in the SDC file. I have tried to constrain then using the -reference_pin option as follows: # main OSC create_clock -period 10.000 -name CLK_100MHZ [get_ports {CLK_100MHZ}] # Memory Source Sync Interface set_output_delay -clock [get_clocks {CLK_100MHZ}] 1.000 [get_ports {SRAM0_CLK}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {S0DATA [*]}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {SRAM0_OEN}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {SRAM0_ADD [*]}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {SRAM0_BW*}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {SRAM0_CS*}] set_output_delay -clock [get_clocks {CLK_100MHZ}] -reference_pin [get_ports {SRAM0_CLK}] 1.000 [get_ports {SRAM0_CEN}]  set_input_delay -clock { CLK_100MHZ } -reference_pin [get_ports {SRAM0_CLK}] 0.200 [get_ports {S0DATA [*]}]  The problem is when I run it through timequest I get a bunch of the following warnings:  Warning: Reference pin SRAM0_CLK is invalid. It is not clocked by the clock specified in set_input_delay/set_output_delay's -clock option.  But when I look at it in the technology map viewer, CLK_100MHZ is tied directly into the input pin of an IO_OBUF then to the SRAM0_CLK pin. I am wondering here if the problem is that SRAM0_CLK is not a clock pin? I am in the process of switching back to the generated clock method but I've had just as many problems with that.  I noticed that a lot of people use a PLL for something like this, I dont understand how that would benifit me. In my case, I just pass the input clock to the output pin, is this the correct way to do it, or should I be using a PLL for some reason?  Thanks alot! Jason

[Altera_Forum]

Hi Jason, 

 The only reason for using a PLL is to have control over the phase relationship between the outgoing clock (the clock that the external device sees) and the internal FPGA clock that clocks out / latces data to / from the external device. If this is an SDRAM device you are interfaceing then typically you would use a PLL to compensate for the FPGA and SDRAM delays. You want to make sure that the SDRAM latches the data when it is stable and you want to make sure the FPGA latches data from the SDRAM when it is stable.   As for thew -reference_pin option, I have never used it. What I would do is to create a generated clock for the output clock. Something like:   create_generated_clock -name clk_mem -source CLK_100MHZ [get_ports SRAM0_CLK]   and then to use set_output_delay using this clock as the reference.   set_output_delay -clock { clk_mem } 1.0 [get_ports {S0DATA [*]}]   (typing this from memory, so syntax may not be 100% correct).   Regards, Niki

[Altera_Forum]

--- Quote Start ---  As for thew -reference_pin option, I have never used it. What I would do is to create a generated clock for the output clock.  --- Quote End ---  Do both methods give the exact same result?  According to this page (http://www.altera.com/support/examples/timequest/exm-tq-basic-source-sync.html) on the Altera website, "The -reference_pin option automatically includes the clock latencies to the specified port or pin." Does the create_generated_clock method achieve this as well?  Timing constraints is the aspect about FPGA development that I feel the least confident about.

[Altera_Forum]

Hi Kevin, 

 From the info on the web page, they should be identical. I have never tried the -reference_pin option. Maybe it is better to use the more standard methods instead of the -reference_pin option which is Altera specific.   I also usually struggle with the timing requirements, and I think it is because I do it once per project and once it is sorted out I do not need to think about it again. So each time the next project needs to be constrained, I have to go back and look up the details again (or copy and paste form the previous one!).   Regards, Niki

[Altera_Forum]

Hey thanks everyone for the input! 

 Kevin - I totally agree with you, meeting timing is always the worst part of any design for me. I am hoping someday I will have the moment when it all becomes clear!  I ended up using the generated clock - this seems to work better for me and as others have said it is standard across vendors, as opposed to the -reference_pin option.  I have one more question for the timing gurus here:  I have a Max II cpld that talks to a Sharc uP over a parallel data bus with RDN and WRN strobe signals to trigger bus reads and writes. One of the things the CPLD must do is freeze the bus by deserting a line called BUSS_ACK when it sees a WRN strobe and the address on the address line is within a certain range.   My code looks something like this:  if wrn"event and wrn=0 then  if a = X"0001" then  buss_ack = "0"  end if end if  the problem is that the address sets up 3 ns before the strobe and is valid throughout the cycle. I always miss the address. I have no idea how to write a constraint for the valid window of the address. I have tried set_input_delay min=-3ns but this does not seem to work. any ideas?  Thanks! Jason

[Altera_Forum]

Hi Jason, 

 Ther are two things you might try. The first is to use the se_max_delay command. Something like:   set_max_delay -from [get_ports addr*] -to [get_registers buss_ack] 3   I am not 100% if this will work, but give it a try.   The second option is to first create a clock for the WRN input. The period is not that critical - make it 10 ns for now:   create_clock -period 10 -name wrn_clk [get_ports WRN]   Now use the set_input_delay -max command (the -max option constrains the setup time, which is waht you want). Set the selay to 10-3 = 7 ns.    set_input_delay -clock { wrn_clk } -clock_fall -max 7 [get_ports addr*]   This in effect tell TimeQuest that you have a setup time of 3ns on the address input relative to the falling edge of the WRN input.   From your description I would say that it is the comparator that creates the D input of the buss_ack register that is the problem. You only have 3 ns for the address signals to be compared to the range (plus the clock latency, min the input latency). It is possible that setting the timing constraint is simply going to tell you you have a problem, but it may not necessarily fix it. You need to increase the clock latency or decrease the input delay of the address lines, through the comparator. Maybe also try to make the comparator as simple as possible - only use the lines that are actually required. This will lead to aliasing, but that may be acceptable.   Regards, Niki