Ouch, well i've never worked with firewire at this level before but here are some maybe helpful thoughts:
I read through the TI PHY datasheet that you linked, it looks like its designed to work with the TI Link Layer Controllers. Have you considered just using such a part rather than trying to implement its functionality from scratch?
Also the PHY <-> LLC link runs at full firewire speed, which for 400mbps and an 8bit link is ~50Mhz, the camera may let you get away with running the link much slower, maybe not. Point being you can't just take the pins of that PHY, blue wire them into the FPGA pins and expect a remotely functional or stable connection. You'll very likely have major signal integrity issues.
It looks like the LLC's from TI come in various configurations, some with rather simple, generic 8/16 bit microcontroller style interfaces which should be easy to implement. You can probably find verilog blocks for such an interface freely available. These links would still need to be fast, ~50Mhz so you'll still have the signal integrity issue. You could run it slower i guess but if the data feed overruns the FIFO in the LLC your SOL.
Once your done with the physical interface you still have an entire firewire driver stack to implement, i guess you'd have to do this in the DSP? Or put a small soft core into the FPGA to handle this work?
What I would really do is tell them they are crazy for forcing a firewire interface for something of this size/capabilities. Its going to take a significant amount of resources to build the firewire interface for no gain since you'll never use anywhere near its bandwidth.
If that fails, I'd try something like this which is a single part with the firewire PHY.LLC and an ARM7 core in a single chip. It offers a parallel data bus to get the information into the FPGA. This way you write the firewire driver to support communications to the camera and plunk it in the ARM7 core and all that has to get transfered to the FPGA are the raw images, no overhead work in the FPGA. You still need to carefully design a PCB for this, your still dealing with a very high speed firewire bus.
EDIT:
At 100MBit/s the firewire bus runs at 100MHZ so you have to deal with moving 100MHZ differential signals from the PHY to the firewire connector. On the PHY<->LLC<->FPGA side: I wouldn't personally try to breadboard a 13MHZ parallel data bus, it may be possible if your careful.
The critical issue for signal integrity is the rise/fall time of the signal, not its clock rate. High clock rate usually means faster rise/fall times but sometimes if you use a transceiver thats designed to run at high frequency at lower frequencies it doesn't actually slow down the rise/fall times.
If the wire carrying the signal is longer than:
Tr/(2*Td) with
Tr = the signal rise time at the source and
Td = the propagation delay per unit length of the wire/cable you are using.
Then you need to consider transmission line effects. You'll have to deal with reflections in the wire which will cause all sorts of junk on the line.
You also need to be careful to make sure all the wires of a parallel bus are the same length with the tolerance for variation depending on the clock frequency of the bus.
Is this thing really going to end up in an UAV/RC aircraft? If so you've got to deal with vibrations and G forces as well.
I'll add a bit to Brian Carlton's answer.
Within an FPGA, it's correct; gated clocks are not at all recommended. And the flip-flops will have a separate ENable input so that it's not necessary.
In your case, though, because your gated clock only goes to the output pin and isn't used internally to the FPGA, you can gate your clock without penalty. The way to do it is to make sure the clock gating is done in the output block. Assuming you're using Xilinx, instead of instantiating an OBUF for your clock output, use an OBUFT, and you'll get access to the tristate pin of the output buffer. If you're using another vendor's FPGAs there will be an equally easy way to do this.
If you prefer to do this using inference rather than instantiation, you'll need to be sure to enable an option during compiling to push logic into IO blocks. If the gated clock does actually fan-out (but you didn't show it in your diagram), you'll also need to enable an option that allows duplicate logic to be generated.
Best Answer
Your problem is in your choice of test equipment. An oscilloscope is generally not intended to be used as an accurate frequency-measuring tool. An oscilloscope can be used to verify that a signal is of approximately the correct frequency, but because frequency measurement in an oscilloscope is usually done by measuring the period of one cycle of the signal, it cannot be very accurate.
To verify that the clock is operating correctly, using a divider chain, as suggested by Brian Drummond and Dmitry Grigoryev in the comments, to slow down your clock is required to make it visible to your oscilloscope. This should be very easy to implement inside the FPGA and then output the divided-down signal to an I/O port. However, at only 25MSps (I assume, given your question. If this is an input bandwidth of 25MHz, you've got a better 'scope), you have a 4 ns uncertainty in the timing of the slower clock edges.
To verify the exact frequency of your FPGA clock source (frequency accuracy is necessary when sending signals to other devices using e.g. Ethernet, USB), you will need a frequency counter. These devices count the number of transitions a known internal time or measure the period between two transitions, then average the result to produce the resultant measured frequency. If you want to measure the parts-per-million frequency error in your FPGA's clock source frequency, you will need a calibrated frequency reference inside your frequency counter.
The PPM error in crystal frequency is caused by factors such as manufacturing tolerance, temperature, and aging. Generally the manufacturer will specify the typical and maximum errors in frequency for a device. Some devices will come in multiple precision grades where some devices are specified to have lower error.