Electronic – the XMOS series

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.

There's two criteria that you can use to evaluate a digital project that help you decide which part best matches your criteria. The first is design size/complexity - how much logic is involved. The second is the input and output requirements in terms of pin count. Speed can be factored in if you can estimate what your slowest function would be. The vendor tools (Altera Quartus II, Xilinx ISE, etc.) will help you once you get in the right ballpark.

• PAL/PLA/GAL: These are intended to replace a small to medium size circuits that you might normally implement as LSI logic chips (7400, 4000 series). These can offer better board layouts due to I/O remapping, and lots of simple logic functions. These chips contain non-volatile memory (or one time programmable fuses) and require no power-up configuration time. They may not contain data storage elements.

• CPLD: These are larger cousins of the PLA. The designs can be small state machines, or even a very simple microprocessor core. Most of the CPLD chips that I have seen do not have any on-chip SRAM, although the large Cypress CPLD you linked does. CPLDs are more likely to be re-programmable with flash memory, and they also do not require configuration time on power-up.

• FPGA: Unlike the CPLD, the logic blocks are based on SRAM instead of flash memory, resulting in faster logic operations. The major down-side with FPGAs is that since the configuration is stored in SRAM, every time the device is powered up the FPGA must load its programming into this SRAM. Depending on the size of your design and the speed of your non-volatile storage, this can cause a noticeable delay from power-on to fully functioning. Some FPGAs have on-chip flash for storing their data, but most use separate memory chips. FPGAs will often have hard-wired multipliers, PLLs, and other logic functions to improve computing speed. Large blocks of on-chip RAM is also available. You will also be able to use high-performance I/O specifications like LVDS, PCI, and PCI-Express.

• FPGA with Microprocessor Hard Core: I'm not familiar with these, but I would imagine that your design would center around the microcontroller programming, and the FPGA would augment the microcontroller. The parts you identified make it look like you would start your design with a microcontroller and a FPGA, and then combine the two into one chip/package.

How to decide which is right for you:

The best way is to have your code (Verilog/VHDL) finished, and then use the vendor's tools to try and fit it into the smallest part possible. I know Altera's tool lets you change programming targets fairly easily, so you could keep picking smaller FPGAs, and then smaller CPLDs until your design usage gets close to about 75%. If you require performance, then try to pick devices that have features (fast multipliers) that decrease the speed requirements of the logic. Again, the vendor tools will help you identify if you need to upgrade or if you can downgrade.

Another factor of which part to use is ease-of-use. Using PAL/PLA/GAL logic is probably more effort than constructing the function using discrete logic gates (74HC*, 4000, etc). CPLDs typically require only a single supply voltage, and don't require additional circuitry. They are effectively stand-alone. FPGAs begin to use multiple power supplies for I/O and the logic core, complex I/O standards, separate program memory, multi-layer (>2) PCBs, and BGA packages.

Steps to narrowing down your design requirements would include:

1. Identify all inputs and outputs for your FPGA/CPLD. This is usually an easy part of the design stage. This way you know what package you're looking at, and how close you can cut it to that margin.

2. Draw a block diagram of the internal logic. If your blocks look simple (each block would have a hand-full of logic gates and registers), then you probably can use a CPLD. If, however, your blocks have labels such as "Ethernet transciever", "PCI-Express x16 interface", "DDR2 Controller", or "h264 Encode/Decode", then you are almost certainly looking at a FPGA and using HDL.

3. Look and see if your interfaces have special I/O requirements, such as special voltages, LVDS, DDR, or high speed SERDES. It's easier to get a chip that supports it than to get an additional translator chip.

Example CPLD Applications:

• Multi-channel PWM with SPI interface
• I/O Expander
• CPU Address Space Decoding
• Clocks (Time keeping)
• Display Multiplexors
• Simple DSP
• Some simple programs can be converted into a CPLD design

Example Hobbyist FPGA Applications:

• Small System-on-Chip (SoC) designs
• Video
• Complex protocol bridges
• Signal processing
• Encryption/Decryption
• Legacy system emulation
• Logic Analyzer/Pattern Generator

For most hobbyist work, you'll be limited to relatively small FPGAs unless you want to solder BGA packages. I would choose between a large CPLD or a cheap FPGA, and the size/speed requirements would dictate which one I needed.