Xilinx virtex-5 pitfalls

Hello People.

Thought I'd share with you, the latest harvest of pitfalls when using xilinx virtex-5 (FX) FPGAs. Pitfalls that makes the difference between a prototype and reliable product.

1. First. When using the xps_ll_temac version 2.03a, the core does not have extra logic for detecting and correcting an error in the temac, which sometimes causes the FCS byte to be duplicated. This occurs maybe in 1 of 100 packets.. Cause unknown. Since the code that fixes this error is not included, it will cause the loss of packets due to FCS errors in the transmit path. Something that will kill most packet streaming applications. Look at how this has been worked-around for virtex-4 and virtex-6 (yes the error was apparently never fixed).. and modify the code accordingly.

See also this answer record:

1. The proc_sys_reset core version 3.00.a is a synchronous design running on the "Slowest_sync_clk" input signal.

The following inputs are therefore ignored when there's no clock on the "Slowest_sync_clk" input:

2a. Dcm_locked 2b. Ext_Reset_In 2c. Aux_Reset_In 2d. Probably all other reset inputs.

Do NOT rely on the core to reset things if there is no clock applied to it. This means that you should not feed the core with the output of any of the DCM's or PLLs which you want to monitor for the locked state.

In about one out of 100 startup situations, the signal to the PowerPC called "ppc_reset_bus_0_Core_Reset_Req" is not released, causing the CPU (and therefore usually the whole system) to HANG indefinitely. Applying a reset to EXT/AUX_Reset_In removes the condition.

1. Depending on how fast clock sources to PLLs and DCMs start up and are stable, the DCM's and PLL's should be held in reset after configuration to ensure a stable clock. The lock outputs should also be filtered as they can possibly be temporarily unstable. We have never seen such stability but it could happen. See this forum thread:
   formatting link

1. Do not set the FPGA configuration startup sequence to wait for PLLs and DCMs to lock before releasing the global three state. It is not allowed and if selected anyway it seems that this combination is silently changed by bitgen.

2. If you enable the "C_STARTUP_WAIT" parameter on a DCM or PLL_ADV (not available on the clock generator core), the DEFAULT behaviour is for the startup logic to WAIT for the lock condition. The documentation says that NoWait is the default (obviously incorrect). To disable this behaviour, bitgen explicitly needs the option : -g LCK_cycle:NoWait

1. To work around the behaviour of the sys_proc_reset core, my recommendation would be to add the following functionality:

6a. Hold the PLLs and DCMs in reset until input clocks are stable. If the lock and reset pins are chained, only the first PLL/DCM is fed the reset signal. 6b. Also hold the EXT/AUX_reset_in inputs active until all PLLs and DCMs are detected to be locked and stable. Use the input clock for this (do not use a clock from any of the PLLs or DCMs). Or alternatively just wait long enough so that all PLLs and DCMs are expected to be locked. (see datasheet for worst case locking times (this data only exists for DCMs)). Applying this extra reset also works around the error with "ppc_reset_bus_0_Core_Reset_Req" not being released.

1. This one is not Virtex-5 specific. It's about the xps_iic version

2.03.a core. The reset states of the tri-state control outputs for the clock and data lines are only reached after the first rising edge of the bus clock. A zero of varying length can therefore be observed on the clock and/or data lines, which could cause a starting condition on the I2C bus. The first access to a I2C device will in that case probably FAIL unless all devices have an appropriate timeout . Means of retrying/recovering from this situation should be added to the software.

There's also a whole story about the spartan-6. But it will be another day..

Happy designing,

Finn