Of course, the tools are much better today, but one aspect is still true - the automatic place and route tool has the final word.  You can use the UCF file to control how fast the design goes, where the pins are located, and what attributes to use, but not everything can be done in the UCF.  What if you want one signal to be slightly delayed with respect to another one?  This was the problem that Crimble Micro Test (CMT) asked Memec Design Services (MDS) to solve.

FPGA's aren't supposed to be used for creating delays, unless it is a synchronous delay.  Silicon process changes make the chips faster and factory inventory control sometimes means a fast part is shipped to the customer marked as a slow part.  So how can you be sure that the delay created on one chip will be the same delay as on another?  And how do you tell the tools not to try to optimize timing for that signal during place and route?

The answer is - you don't.  At least, you don't try to create absolute delays, where a signal always takes x ns to get to the pin.  You can, however, create relative delays, where a signal is somewhat slower than another one.  The difference is that the value of the delay can change depending on the speed of the part, but the relative timing between the two signals won't.  This difference makes the faster silicon a non-issue.  But, how do you control the tools?  The delays that CMT needed were very small, around 50 ps.  You can't use inverters and logic to make delays that small.  So, we turned to the wires inside the Xilinx device.  If you load one wire more than another one of the same type, the loaded-down one is slower.  To find out how much slower, we needed to run some experiments.

That brings the issue back to tools.  How does one control the loading of the wire and make sure the two signals use the same type of wire (single, double, quad, long, etc.).  Initially, we looked at the EPIC Design Viewer/Editor included in the Xilinx Foundation tools.  We controlled the placement of the source and destination CLBs with a UCF, so that the same routing would be used for each signal by the place and route tool.  Once all the wires were placed correctly, we could start adding delays on some of them.  It was tedious work, and being graphical in nature, did not lend itself to automation.  After several iterations of adding delays with EPIC, generating a new bit stream, and measuring the delay, we decided there must be a better way.  And there was - Jbits.

CMT and Memec Design Services contacted Xilinx and learned of this tool that allows designers to change a bit stream using a Java program.  Jbits treats each Xilinx device as a grid, where each square in the grid is a CLB and surrounding routing.  The squares are given coordinates so you can specify which CLB you want to change.  Within the square, the routing channels are numbered in an orderly fashion and named according to their type (VERT_SINGLE1, HORIZ_QUAD2, etc.). 

We wrote a program to "read" the bit stream and check for what resources were being used so we wouldn't create any conflicts when we modified the design.  Then the program modified the routing of the design to use exactly the same routing for each signal.  We were able to add the delays by changing the routing of each signal very slightly with respect to the other signals.  The Java command to add the delay was very simple:
jBits.set (10,20,Routing.HORIZ_QUAD8_TO_VERT_SINGLE5,Routing.ON)
This command turned on the programmable interconnect point (PIP) that connects the horizontal quad line in the eighth position to the vertical single line in the fifth position in the CLB located at row 10 column 20.  Turning on that PIP caused the quad line to become loaded down with the capacitance of the vertical single line, resulting in some minor delays on the quad line.  We were also able to create pieces of the design using Jbits as the source.  For example, when larger delays were needed, we routed signals through CLB's using the feed-through path or look-up tables.  Our Jbits program created the look-up tables, configured them with the correct contents, and connected all of the inputs and outputs to the routing channels.  In fact, most of the design work was done with Jbits instead of a schematic capture tool or HDL.  When we wanted to make a change, we changed the Jbits program and re-compiled, which only took a few seconds compared with a few minutes for place and route times. Using Jbits cut down the testing experimentation phase by several days and allowed Crimble Micro Test to deliver incremental delays of around 50 ps.  While this application is quite esoteric, the possibilities for Jbits are exciting in many other mainstream applications such as in-field upgrades and reconfigurable hardware.