Driving them all with DDR signals isn't putting you at the edge of the spec, but only at the edge of the spec assuming everything is matched nominal no-skew. Since we KNOW that output matching is not perfect, and we don't have a manufacture guaranteed bias (a guarantee that if any output if faster, it will be this one), we are starting outside the guaranteed specs. Yes, you can pull some tricks to try and get back into spec and establish a bit of margin, but this puts the design over into the realms of 'black arts', and best avoided if possible.
Both you and rickman seem to be missing the entire point of my original post; i.e. you wrote earlier:
The built in dual-edge I/O logic on many FPGAs provides EXACTLY this capability, but with much better PVT tracking.
Although my ancient Spartan-3 example code didn't explicitly adjust the edge delay with either a DCM/PLL or IOB delay element (although I did mention DCM duty cycle tweaks), this is very straightforward to do in many recent FPGA families.
Relying on characterized minimums to meet hold times is not a 'black art'; it is the underlying reason why synchronous digital logic works at all.
I.e. connecting two sections of a 74LS74 in series at the board level requires that Tplh/Tphl (min) of the first flip-flop be greater than the hold time of the next. (And yes, I realize that some logic technologies require dummy routing or buffers in the datapath to avoid hold time violations.)
Particularly with a vendor evaluation board like I used for that 2004 Spartan-3 Starter Kit SRAM example, it is far more likely that signal integrity problems with the WE line, rather than buffer delay behavior, causes problems.
The 'Black Art' I was referring to was NOT datasheet min/maxs but using strong/weak drive and bus loading to convert timing that doesn't meet guaranteed performance (since given two outputs, there will be some skew, and absent some unusual specification that pin x will always be faster than pin y, we need to allow that x might be slower than y) into something that likely 'works'.
As I explained to rickman several posts ago, the Spartan-3 I/O buffer base delay vs. IOSTANDARD/SLEW/DRIVE is fully characterized and published by Xilinx:
If you don't want to rely on a guaranteed minimum delay between I/O buffer types at the FAST device corner, that's fine with me, but please stop with the baseless criticism.
Looking at the datasheet for the Spartan-3 family, I see no minimum times published. There is a footnote that minimums can be gotten out of the timing analyzer. There are maximums fully specified out, including adders for various cases, allowing you to do some of the analysis early in the design, but to get minimum timing you need to first get the program and a license to use it (license may be free, but you need to give them enough information that they can contact you later asking about your usage).
Being only available in the program, and not truly "Published" indicates to me some significant uncertainty in the numbers. Timing reports out of programs like this tend to be disclaimed to be valid only for THAT particular design and the particular operating conditions requested. You need to run the analysis over as many condition combinations they provide and hope (they never seem to promise it) that the important factors are at least monotonic between the data points so you can get real min/maxs.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.