Controlling the setting of IO pad delays

[Altera_Forum]

I have a design which uses a PLL to create an internal copy of an external clock used to interface a processor to a Cyclone II. The aim is to optimise the transfers to and from the processor by ensuring data is centred in the "eye", the usual approach. All the signals to and from the FPGA are registered in the IO pads using "fast" commands so the timing margins should be dependent only on the programmable input and output delays in the pads and the PLL phase shift (boards track delays are taken into account in the SDC constraint values). 

 I've done offline calculations which suggest the optimum values would be 1250ps for phase shift (the numbers don't matter, just for example) with the output delay on step 1 (range 0-1) and the input delay on step 4 (range 0-7) based on min and max device parameters which are the extremes over both the slow and fast models.   Setting the phase shift in the Megawizard is trivial but on synthesis Quartus choses delays of 0 and 2 respectively. This still gives me positive slack by my calculations (so not too much of a problem on this project) but about half of what I would expect with the optimum values.   First question: does Quartus try to centre the sample point in the eye or does it have some other strategy?   If so, second question, does it use only one speed model, e.g. slow. I have set the "Enable multicorner timing analysis during compilation" option under the Timequest Timing Analyzer" settings but I expect that only affects reporting. The problem I foresee here is that, in a tight design, it might by centered for a slow chip but have negative slack on a fast one whereas more balanced choice might be able to achieve a smaller positive slack over the whole range of PVT.   Third question: if I choose to force my values on the design, is there a way to set these pad delays in the QSF or SDC? I have been able to fix them manually using the Resource Property Editor and then export the change as a TCL file but integrating and maintaining that as part of the design flow could be tricky to manage unless I can get Quartus to call the file at the appropriate stage.   George

[Altera_Forum]

--- Quote Start ---  I have a design which uses a PLL to create an internal copy of an external clock used to interface a processor to a Cyclone II. The aim is to optimise the transfers to and from the processor by ensuring data is centred in the "eye", the usual approach. All the signals to and from the FPGA are registered in the IO pads using "fast" commands so the timing margins should be dependent only on the programmable input and output delays in the pads and the PLL phase shift (boards track delays are taken into account in the SDC constraint values).   I've done offline calculations which suggest the optimum values would be 1250ps for phase shift (the numbers don't matter, just for example) with the output delay on step 1 (range 0-1) and the input delay on step 4 (range 0-7) based on min and max device parameters which are the extremes over both the slow and fast models.   Setting the phase shift in the Megawizard is trivial but on synthesis Quartus choses delays of 0 and 2 respectively. This still gives me positive slack by my calculations (so not too much of a problem on this project) but about half of what I would expect with the optimum values.   First question: does Quartus try to centre the sample point in the eye or does it have some other strategy?   If so, second question, does it use only one speed model, e.g. slow. I have set the "Enable multicorner timing analysis during compilation" option under the Timequest Timing Analyzer" settings but I expect that only affects reporting. The problem I foresee here is that, in a tight design, it might by centered for a slow chip but have negative slack on a fast one whereas more balanced choice might be able to achieve a smaller positive slack over the whole range of PVT.   Third question: if I choose to force my values on the design, is there a way to set these pad delays in the QSF or SDC? I have been able to fix them manually using the Resource Property Editor and then export the change as a TCL file but integrating and maintaining that as part of the design flow could be tricky to manage unless I can get Quartus to call the file at the appropriate stage.   George  --- Quote End ---    Hi George,  I can answer at least parts of your questions:  Setting "Optimize Multi-corner Timing"  Question 2 :Controls whether the Fitter optimizes a design to meet timing requirements at all process corners and operating conditions. The Optimize Timing logic option must be enabled for this option to work. When this setting is turned off, designs are optimized to meet timing only at the slow timing process corner and operating condition. When this option is turned on, designs are optimized to meet timing at all corners and operating conditions; as a result, turning on this option helps create a design implementation that is more robust across process, temperature, and voltage variations.  Turning on this option does not enable multi-corner timing analysis. To enable multi-corner timing analysis, see the TimeQuest Timing Analyzer page or Classic Timing Analyzer Settings page of the Settings dialog box.  Question 3:   What kind of FPGA do you use ? For StratixIII and StratixIV you could set the delay lines in the assignment editor. I will setup an example for you.  Kind regards  GPK

[Altera_Forum]

Thanks for that, it's a great help. The device is a Cyclone II. 

 I have attached a graphic of the editor where I tried making the change, you can see it turns blue at the bottom of the table. I had thought that making changes via the various editors stored the info in the QSF but that doesn't seem to be the case here, after making this change, a "save" stores an ECO and causes the fitter to be run but there was no difference in the QSF after I closed Quartus. We have configuration control of the QSF and SDC files but if the ECO data is stored elsewhere, we would need to include the relevant file(s).

[Altera_Forum]

--- Quote Start ---  Thanks for that, it's a great help. The device is a Cyclone II.   I have attached a graphic of the editor where I tried making the change, you can see it turns blue at the bottom of the table. I had thought that making changes via the various editors stored the info in the QSF but that doesn't seem to be the case here, after making this change, a "save" stores an ECO and causes the fitter to be run but there was no difference in the QSF after I closed Quartus. We have configuration control of the QSF and SDC files but if the ECO data is stored elsewhere, we would need to include the relevant file(s).  --- Quote End ---    Hi,  for Cyclone II unfortunately I have no solution.   BTW: A far as I know ECO change will be never stored in the QSF od SDC file automatically !

[Altera_Forum]

OK, thanks. I'm rebuilding with the multi-corner option on now which may persuade Quartus to choose the same values as I calculated. Thanks again for your help. 

 George

[Altera_Forum]

--- Quote Start ---  OK, thanks. I'm rebuilding with the multi-corner option on now which may persuade Quartus to choose the same values as I calculated. Thanks again for your help.   George  --- Quote End ---    Hi George,  good news. I found the setting for the assignment editor in order to set the delays for CycloneII. I have the project attached. For the input you have a valid range from 0 - 7, for the output 0-1. For the real delays look into the resource property editor. You can check the setting under:  Compilation report -> Fitter -> Resource section -> Delay Chain summary  Kind regards  GPK

[Altera_Forum]

Marvellous, thanks again. Setting the multi-corner optimisation has significantly improved the slack, I'll need to dig into the results to check the delays but I'm stuck in a meeting at the moment ;-) 

 George

[Altera_Forum]

Just a note to say that mostly worked, switching on "Optimise Multi-corner Timing" has persuaded Quartus to change the output delay to 1 and the input delay to 3. I expected 4 but the calculations are complex so within 1 step is understandable. Thanks very much for that. 

 George