Unsuitable or unprofessional application and handling are not covered by our warranty. Our products include sensitive electronics and should be handled with care at all times.

Field failure of our products is exceedingly rare under normal operating conditions. In our experience, nearly all failures are due to mishandling, misapplication, or operating out of design specification.

The most common causes of hardware failure are:

• Over-voltage on a power input  – This can cause permanent damage and cause the board to become non-functional. Due to the possibility of multiple component failure diagnosis and repair is not typically practical.
  
• Over-voltage or over-current on a signal line – FPGAs have very high-performance I/O. These devices are not tolerant of voltages out-of-specification and are not designed as high current drivers. Exceeding the device specifications can cause I/O failure or device failure.
  
• Touching sensitive components – Many of our devices have high-performance power converters with sensitive feedback networks. Small external influences (such as human touch) can cause these devices to “self-destruct”. It is important not to touch these devices during operation.
  
• ESD events – ESD can cause product failure that can be difficult or impractical without extensive (and expensive) root cause analysis. Exercise common sense and professional engineering practices at all times.
  
• Hot-plug events – All handling and adjustments must be performed when the device is powered off.

USB connectivity and performance issues are generally related to host software configuration, host hardware configuration, and cabling. Some guidelines and suggestions are listed below.

• Host port hardware – USB disconnections or performance issues can be related to poor signal integrity. We strongly suggest using a good quality motherboard and ports mounted on the motherboard. Front-panel ports are often attached internally using poor quality cables to headers on the motherboard. These connections and headers degrade signal integrity and can cause problems.
  
• Cabling – We have tested a number of commodity USB cables using lab-grade cable testers and found that many are marginal to meeting the USB specification. Poor signal integrity can degrade performance or prevent reliable connections. We do not recommend the use of cable extenders or multi-segment cabling solutions without thorough qualification. Poor performance and/or occasional API timeouts are often symptoms of poor cable solutions.
  
• Bad Cables – While bad cables are rare (especially if we have provided them), they can happen. Check your system with a known-good cable to confirm.
  
• USB Version – Transfer performance is related to the USB connection speed (full, high, super). If you’re experiencing poor performance, confirm that you’re connected to an appropriate USB port and that your cable supports the performance.

When using very large pipe transfers over USB 2 in Linux (~16777214) you may see ENOMEM errors with the transfer failing. It is recommended to use a smaller pipe transfer size if you experience this issue. Alternatively, use block pipes to separate the transfer into smaller segments.

Currently, Digilent JTAG adapters are not able to be used with the XEM8350. More information is available in the XEM8350’s JTAG page.

Vivado version 2020.2 introduced new behavior that results in a naming conflict and critical warning when using certain Xilinx primitives in a design that includes the FrontPanel HDL. Specifically, use of the Xilinx FIFO Generator IP (and the modules used in that IP) has been found to conflict with modules in use within the FrontPanel HDL. The critical warning that we have seen Vivado throw is:

This or similar critical warnings may present themselves. We are actively working with Xilinx to resolve this issue. Until a viable resolution is reached, the recommendation at this time is to build designs with an earlier version of Vivado.

Through our own internal testing, we have found that ignoring these critical warnings when building and generating designs with Vivado 2020.2 did not have any noticeable effects on the FrontPanel HDL or user HDL. You could alternatively ignore these critical warning while we work to resolve the issue with Xilinx. 

Vivado 2021.1 and later removes support for sources encrypted with Vivado public keys older than five years from the Vivado version being used. If you are using FrontPanel HDL sources with expired Vivado public keys, you may encounter the following errors (or similar):

[Synth 8-5809] Error generated from encrypted envelope. ["…/Counters.srcs/okCoreHarness.v":14]
[Opt 31-31] Blackbox ep01 (okWireIn) is not supported or not found. This blackbox cannot be found in the existing library.
[Opt 31-30] Blackbox ep00 (okWireIn) is driving pin I0 of primitive cell led_OBUFT[0]_inst_i_1. This blackbox cannot be found in the existing library.
[Opt 31-236] Found primitives driven by Empty Hierarchy Cells/Black boxes.Code language: JavaScript (javascript)

Encrypted HDL using 2021 Vivado public keys are included in FrontPanel 5.2.5. Your version of Vivado must have support for the public key used to encrypt these sources. So you must use Vivado 2021 or later with the 2021 key encrypted sources. The previous sources, which were encrypted with earlier public keys, are still provided in the installation and must be used with that year’s Vivado or later. For more information, please visit FrontPanel HDL.

The okCoreHarness.v file contains code which requires that the default net type be wire. Issues arise when a Verilog source sets the default_nettype to none prior to synthesis of okCoreHarness. The following errors can occur:

ERROR: [Synth 8-6735] net type must be explicitly specified for ‘l233aa7bee2c916d8fab1c72e4c9ae55d’ when default_nettype is none
[Synth 8-1852] concurrent assignment to a non-net l233aa7bee2c916d8fab1c72e4c9ae55d is not permitted
[Synth 8-5809] Error generated from encrypted envelope.Code language: CSS (css)

To resolve this, ensure that okCoreHarness is located first in the “Compile Order” tab of your Vivado project. When importing files into your project, Vivado will usually determine to place okCoreHarness at the top of the “Compile Order” list, so this is usually not an issue.

Alternatively, you may add the following line to the last line of the first non-encrypted Verilog source file compiled prior to okCoreHarness:
`default_nettype wire

Prior to FrontPanel 4.5.6, flashloader bitfiles interfacing with 32 Mbit flash parts were incorrectly configured to use page addressing (two byte) for sector (64 kB) erase operations. This is because the flashloader software assumes sector (one byte) addressing. In FrontPanel 4.5.6 the HDL was fixed to use sector addressing for sector erase operations, and the flashloader bitfiles located in the FrontPanel install were updated to reflect this change.

This section offers a method for resetting the internal user logic on an AMD FPGA board after bitfile configuration. This process eliminates the need for the FrontPanel host interface to provide the reset.

1. Utilize the STARTUPE3 Primitive: Use the STARTUPE3 primitive’s End of Startup (EOS) signal to initiate a reset to internal logic. See Xilinx STARTUPE3 Documentation.
2. Program Start-Up Sequence: The specific order of start-up events is user-programmable. Optionally configure this sequence to fit your needs. See Xilinx Startup Sequence Documentation.