Creating or Acquiring IP

To add component-level IP (CLIP) to an FPGA target, you must provide IP, in the form of VHDL code, to compile into the FPGA target. You can provide the VHDL code in the following ways:

  • Create VHDL.
  • Generate IP cores through the Xilinx IP generator.
  • Purchase IP from Xilinx or partners.

Supported IP File Types

You can use IP defined using VHDL, Verilog, or the Xilinx IP generator. If you use IP defined using Verilog, you first need to compile this IP into a netlist file, then wrap the netlist file in a VHDL file. If you use IP defined using the Xilinx IP generator, you can import a constraints file directly to a CLIP signal. You can specify constraints using a constraints file, depending on your specific FPGA target. However, if you apply a constraint to a CLIP signal, the LabVIEW block diagram must use that signal or else LabVIEW returns a Xilinx error when you compile the VI.

Custom User Libraries

CLIP does not support custom user libraries in the VHDL. If your VHDL uses custom user libraries, you have the following workarounds:

  • Create a netlist from the VHDL and integrate the netlist using CLIP.
  • Reference the default reference library instead of a custom user library.

IP Design Rules

To fit inside the FPGA target and interface properly with the LabVIEW FPGA Module, VHDL code must obey several rules. These rules govern the I/O ports, clocking, and reset behavior of the VHDL code.

I/O Data Types

All I/O that interface with LabVIEW must be of a supported LabVIEW data type. The table below lists the data types that the FPGA Module supports and the corresponding VHDL data type that you must use for the IP interface.

FPGA Module Data Type VHDL Data Type
Boolean

std_logic

U8 and I8

std_logic_vector(7 downto 0)

U16 and I16

std_logic_vector(15 downto 0)

U32 and I32

std_logic_vector(31 downto 0)

U64 and I64

std_logic_vector(63 downto 0)

Fixed-point std_logic_vector(x downto 0) where x is in range [0,63].

For example, the FPGA Module represents an IP input port of type std_logic_vector(31 downto 0) as a 32-bit unsigned integer (U32). If the VHDL code requires a port with an unsupported width, such as std_logic_vector(65 downto 0), you must create a wrapper VHDL file to adapt this port to a data type the FPGA Module supports. Refer to the NI website for an example of this adaptation.

Note Some CLIP sockets allow additional data types. The availability of CLIP sockets varies by FPGA target. Refer to the target hardware documentation for more information about CLIP sockets.

CLIP Clocking

All base and derived FPGA clocks are stable and free-running immediately after the Reset signal declared in the XML file deasserts. However, external clocks may stop or have glitches. If possible, avoid using a clock that may stop or have glitches. If you have code that resets a clock, ensure that other code does not depend on that clock to remain stable and free-running.

You must consider the CLIP clock when accessing CLIP I/O. CLIP I/O timing is dependent on the IP, so the IP must be able to read and write CLIP I/O on the appropriate clock. If you read from and write to the CLIP I/O in different clock domains, you must include synchronization registers in the Advanced Code Generation page of the FPGA I/O Properties dialog box, Advanced Code Generation page of the FPGA I/O Node Properties dialog box, and/or the VHDL code of the CLIP. However, if you access the same I/O from CLIP and a VI in the same clock domain, you can minimize latency by setting the number of synchronization registers to 0.

You also can declare clocks in the CLIP that the FPGA VI can use. You can use CLIP clocks in the same way you use FPGA clocks provided by the target except that the CLIP clock cannot be a top-level clock.

Note Socketed CLIP also might have access to global clocks directly from the FPGA. The availability of socketed CLIP varies by FPGA target. Refer to the target hardware documentation for more information about the behavior of the socketed CLIP clocks.

Resetting VHDL Code

All VHDL code can include a single asynchronous reset input so that the VHDL code is reset with the FPGA VI when you use the Reset method. NI recommends that you include a single asynchronous reset. If you do not include a single asynchronous reset, you must develop an alternate reset mechanism to ensure the VHDL code functions properly before, during, and after an asynchronous reset.

Constraints and Hierarchy

You can include CLIP-specific user constraints in the compilation using a constraints file, depending on your specific FPGA target. You can use this mechanism for all constraints except pin placement constraints. For example, you can access a clock directly from a global clock input pin through a global clock buffer for socketed CLIP. You must constrain the period of this clock.

For constraints on specific components within CLIP, you might need to specify the location of the component within the overall VHDL hierarchy. In such cases, consider prefacing the constraints with the following macros. Prefacing allows the constraints to be applied regardless of the component location in the VHDL hierarchy. If you want to use this example code, copy the code to a text file and save the file as (Xilinx ISE) DemoClipAdder.ucf or (Xilinx Vivado) DemoClipAdder.xdc. Add this constraints file along with the VHD file as synthesis files in the Configuring CLIP wizard to implement this constraint.

(Xilinx ISE)

NET "%ClipInstancePath%/myCLIPIO*" TNM_NET = %ClipInstanceName%myCLIPIO; TIMESPEC TS_%ClipInstanceName%ThruMyCLIP = TO "%ClipInstanceName%myCLIPIO" 10 ns;

(Xilinx Vivado)

create_clock -period 10.000 -name %ClipInstanceName%Clk -waveform {0.000 5.000} -add [get_pins %ClipInstancePath%/clk] set_clock_latency -clock [get_clocks {%ClipInstanceName%Clk}] 10.0 [get_pins {%ClipInstancePath%/cAddOut[0]}]

To instantiate the CLIP multiple times, each CLIP instance must have a unique name, and the name must follow VHDL naming conventions. Name each CLIP constant uniquely, and do not prefix CLIP constant names with k. When you include these macros, you do not need to include a separate constraints file for each instance because the FPGA Module creates a unique instance name.

If a CLIP signal is not used, the Xilinx compilation tools might remove the signal from the bitstream. In such cases, you might get an NGBuild error during compilation. To resolve this issue, remove the constraint or use the signal in an FPGA VI.

(Xilinx Vivado) For each compilation, the FPGA Module generates a file named unapplied_constraints.xdc that lists all unapplied constraints. To verify if a constraint is applied in the compilation, complete the following steps:

  1. Navigate to the following default directory: C:\NIFPGA.
  2. Open the folder specific to your compilation.
  3. Unzip the output_files.zip file and save the unapplied_constraints.xdc file to an easily accessible place.
  4. Open the unapplied_constraints.xdc file and search for the constraint.

Refer to the CLIP Tutorial, Part 1: Creating VHDL Code for an example of creating VHDL code.

Caution In order to guarantee data integrity and timing closure, verify that I/O nodes from the CLIP are written in the same clock domain in which they are read on the LabVIEW diagram and that I/O nodes to the CLIP are read in the same clock domain in which they are written on the LabVIEW diagram.
Note Do not to write constraints that rely on paths outside of the CLIP logic since NI can not guarantee that those paths will not change.