F
Finn S. Nielsen
Guest
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:
http://www.xilinx.com/support/answers/33456.htm
2. 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.
3. 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:
http://forums.xilinx.com/xlnx/board/crawl_message?board.id=Virtex&message.id=6576
4. 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.
5. 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
6. 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.
7. 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
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:
http://www.xilinx.com/support/answers/33456.htm
2. 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.
3. 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:
http://forums.xilinx.com/xlnx/board/crawl_message?board.id=Virtex&message.id=6576
4. 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.
5. 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
6. 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.
7. 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