Timing constraints ? Are *.ucf files created for a *typical* FPGA design ? I am designing an FPGA (xilinx spartan 3 family, xc3s400), which I have not done for years. (I have been designing relatively simple asic modules in the last couple of years, but I digress). I cannot seem to recall if timing constraints (*.ucf file) are user-entered OR IF timing-constraints entry is typically ignored and the fpga typically generates it for the user. (...I am in the process of going over the help files as I am typing this post...)
P.S by "typical design" I mean a design that does not push the FPGA to its limits (frequency limits, size limits, ect ..)
The .ucf (user constraints file) is typically required for pin assignments. If your design has *no* timing concerns (1 MHz or less, perhaps) then timing constraints aren't required. If you enter timing constraints in your synthesis tool, you often have the .ncf generated with the synthesizer's version of the timing constraints that make it to the place & route tool. The timing analyzer can give default analysis if nothing is specified.
Here's an old "buried gem" on the Xilinx website: ftp://ftp.xilinx.com/pub/documentation/M1/timingcsts1.5.zip
Slide 45 of that document answers your question. Timing constraints can be entered by the user in two places:
1) Pre-synthesis ( in .xcf for XST, ??? for your synth tool ). These constraints are propagated forward to the back-end tools (via .ngc for XST, via .ncf for edif flows).
2) Post-synthesis in the .ucf
Post-synthesis UCF constraints have priority over pre-synthesis (NGC or NCF) ones.
Here's a caution if you're going to use UCF constraints, from a toe-stub I ran into a short time ago.
Nobody here at c.a.f. had anything to suggest (even our FAE was stumped), I finally worked it out (like most things, it's obvious in hindsight).
I had a clock enable (CE_10MHz), derived from a decode of a counter running at 80MHz, and constrained in the UCF as shown on slide 36 of the ppt document referenced above. The trouble I had was that the TNM timegroup for the CE_10MHz signal was missing many elements it should have had. The reason was that synthesis re-partitioned logic such that for those missing elements, the CE_10MHz signal had been absorbed into a LUT, and no longer existed. Thus, the path tracing process could not find it and add those elements to the time group. This was fixed by changing the source of CE_10MHz to be a FF's output, instead of a decode from a counter, which prevented it from being absorbed. This was not the entire fix though... the synthesis tool may introduce register duplicates, which will have different net names.
I'd assume pre-synthesis constraints are properly expanded by synthesis tools to cover any register duplication or balancing that may occur, but have not tested this yet. The manuals don't explicitly say they do. Does anyone have any experience there?