Solution
The LabVIEW FPGA Module is used with LabVIEW to help engineers develop and debug custom hardware logic that can be compiled and deployed to NI hardware with onboard FPGAs. Every time an user compiles a LabVIEW FPGA Module bitfile, the entire design must to go through the place-and-route process. This FPGA design can contain multiple parts:
- Fixed Logic: These are components that always need to be present, even in empty LabVIEW FPGA VIs. These components connect the whole design to the FPGA IO (e.g. the bus interface for communication with the host, the front-end interface for interacting with the instrumentation part of the board, the triggers, etc.). Without them, the host would not be able to talk to the FPGA hardware, and the FPGA device would not know how to interface with its sensors or other components in the front-end. It is the essential part of a LabVIEW FPGA design.
- LabVIEW FPGA VI(s): This is what a user implements within the LabVIEW FPGA block diagram.
- Component-Level IPs (CLIPs): This consists of packaged IP that can be instantiated in the diagram, or can interface the diagram to the Fixed Logic for a specific purpose.
- CLIPs that interface the LabVIEW FPGA block diagram with the fixed logic are called socketed CLIPs because in order to communicate to a specific part of the Fixed Logic, they need to match a specific interface, or socket.
When the full FPGA build flow fails timing, and the paths that fail timing are inside the LabVIEW FPGA VI, the LabVIEW FPGA Module can map the paths from the timing report to specific locations in the VI diagram that correspond to those paths. This is helpful to the user because they can try to modify their design to improve timing. NI's goal when designing the LabVIEW FPGA Module is to try to minimize the chance that timing violations failures will ever happen outside the LabVIEW FPGA VI, because an user has little visibility of those parts.
Unfortunately, place-and-route is a process in which different logical parts of the design can interfere with each other due to physical restrictions (e.g. FPGA being too full or too congested). Therefore, it is possible that an aggressive FPGA design caused by an aggressive LabVIEW FPGA diagram can result in timing failures in the other parts of the FPGA. These are the non-diagram components. For example, sometimes the Vivado compiler spends substantial effort resolving a very difficult path in the FPGA diagram and succeeds. However, the remaining less-difficult paths have an increased probability of failing as a timing violation.
As a user, some things that are useful to remember are:
- This is part of the nature of designing reconfigurable high-performance instruments that try to get as much performance out of the FPGA as possible. While NI designs the Fixed Logic to be as timing-friendly as possible to minimize the risk of user-facing timing failures, NI also designs it to be as performant and resource-efficient as possible. The trade-off is always a balance between all those aspects.
- Diagram components can affect non-diagram components because they compete for resources. Improving a diagram component to make it more timing-friendly can fix a non-diagram component failure. Therefore, it is recommended to fix all diagram timing failures first before worrying about non-diagram component failures. They may go away once the former are fixed.
- Check utilization reports. If the FPGA resources are being aggressively used, failure may be unavoidable and whether it appears in a diagram vs non-diagram component is not an indication of the actual cause of the problem. A smaller, more resource-efficient design may help with timing by reducing congestion.