Interfacing to a source synchronous bus with an FPGA can be a bit tricky.  Today’s FPGA tools provide lots of resources to help achieve timing closure inside the chip.  Sometimes though, the FPGA needs a little help external to the chip to meet timing.

I recently ran into a case where an FPGA connected to an Ethernet PHY over a GMII bus.  The GMII bus uses simplex point to point connections for transmit and receive.  The source end of the connection drives the clock.  Both the clock and data for the GMII “Transmit” connection were sourced from the FPGA.  Close inspection of the FPGA timing report revealed that the data could come out 118 picoseconds before the clock came out. It is important that both the setup and hold time requirements of the PHY be met.

It was necessary to ensure the clock arrived at the PHY before the data lines changed (zero hold time) and that the PHY’s setup time requirements were met.   The easiest way to do this was to delay the data lines a small fixed amount by running them as longer nets than the clock line.   This ensures most of the clock period for setup time at the PHY and still maintains a 0 ns hold time.    The exact board propagation delay number is based on the dielectric constant of the circuit board and can be calculated by a circuit board vendor given the details of a board.   My general rule of thumb for delay in a stripline trace is about 165 ps/inch.  Sometimes a little propagation delay is a good thing!

Xilinx has a technology called SystemAce that allows you to boot Linux directly from a Compact Flash device.  People see this and ask us: “why use a bootloader in my project?”   The short answer is that, while it’s quick and easy to boot directly from CF for development and demo purposes, for production there are other things you should consider.

Key issues for production hardware include:

1. How will you set permanent information such as per board Ethernet MAC addresses and serial numbers?  This needs to be quick and simple for a manufacturing environment.  Clumsy scripts and hokey workarounds bring no end of headaches here.
2. How will you store persistent information, such as static IP addresses, that may change occasionally but must be recalled after a power cycle or reset?
3. How will you upgrade your operating system?  Do you need to do this in the field?
4. Do you need diagnostics?  How will whoever manufactures your device test it?  Typically, manufacturing diagnostics are required to support debug of faulty units for any processor based system.  Also, some devices need to run a power-on-self-test (POST) before becoming operational for safety or other reasons.
5. Will you ever need to change system behavior at boot time?  For example, would it be handy to easily switch between an NFS mounted and a RAM based root file system to debug certain problems?

A well developed, flexible bootloader, such as U-boot,  provides ways to bring these important features to a product.