Executing S-Function or C code generated by Simulink on NI hardware requires matching the target architecture to the appropriate deployment tool. For host-based USB devices like the USB-6363, you must use standard driver APIs rather than real-time execution. For FPGA modules under NI-RIO, HDL Coder is required for synthesis, not Simulink Real-Time.
Understanding Hardware Constraints and Target Architectures
The first step in successfully deploying code is recognizing that not all NI hardware supports the same execution models. A common misconception is that all National Instruments devices can run real-time Simulink models directly. This is false. You must distinguish between host-connected devices and embedded real-time targets.
The USB-6363 is a USB-based data acquisition device. It connects to your computer via USB and relies on the host CPU for processing. It does not have an onboard processor capable of running independent real-time loops. Therefore, any code you write for the USB-6363 must execute on your main computer. Attempting to treat it as a standalone real-time target will fail because the hardware architecture does not support it.
In contrast, NI-RIO FPGA modules (such as those found in CompactRIO systems) contain Field Programmable Gate Arrays. These are programmable logic devices that operate independently of the host CPU. To deploy code here, you cannot use standard C code execution tools meant for processors. Instead, you need to generate hardware description language (HDL) code, which is then synthesized onto the FPGA fabric.
Deploying Code for Host-Based USB Devices
For devices like the USB-6363, your goal is to control the device from your host environment using MATLAB or C/C++. You do not deploy a compiled binary to the device itself. Instead, you use the Data Acquisition (DAQ) Toolbox or NI-VISA interface within your script.
If you are using Simulink, you should utilize the DAQ blocks provided in the library. These blocks communicate with the NI-DAQmx drivers installed on your host machine. The workflow involves:
1.
Install NI-DAQmx Drivers: Ensure the latest version compatible with your OS is installed. This provides the low-level API that higher-level tools call.
2.
Configure the DAQ Block: In Simulink, drag the "Analog Input" or "Analog Output" block from the DAQ library. Set the channel to match your USB-6363 configuration.
3.
Run Simulation: When you run the model, the simulation executes on your host PC. The DAQ blocks send commands to the USB device in real-time relative to the host clock.
If you prefer writing custom C code, you can link against the
naclapi.h or
daqmxdll.h libraries depending on whether you are using the newer NI-DAQmx C API or the legacy ANSI C API. The key point is that the executable runs on your Windows or Linux host, not on the USB stick.
Using HDL Coder for NI-RIO FPGA Modules
When working with NI-RIO FPGA modules, the process shifts from software execution to hardware synthesis. Simulink Real-Time is designed for processor cores (like ARM or x86), not for FPGA logic. To deploy to an FPGA, you must use HDL Coder.
The workflow for FPGA deployment involves generating Verilog or VHDL code from your Simulink model. This code is then synthesized using Xilinx Vivado or Intel Quartus, depending on the specific FPGA chip inside the NI module.
1.
Create an HDL-Compliant Model: Your Simulink model must follow strict rules for HDL generation. Avoid floating-point arithmetic if possible, as it consumes significant FPGA resources. Use fixed-point math instead.
2.
Generate HDL Code: Use the HDL Coder app to convert your Simulink model into synthesizable HDL.
3.
Synthesize and Deploy: Import the generated HDL into the NI RIO Project Manager. Synthesize the design and download it to the FPGA.
This approach allows your logic to run at the speed of light on the FPGA fabric, completely independent of the host processor. It is essential for applications requiring microsecond-level timing precision that a general-purpose OS cannot guarantee.
Common Pitfalls and Troubleshooting
Users often confuse the capabilities of different NI products. If you try to use Simulink Real-Time with a USB device, you will encounter errors because the target interface does not exist. Similarly, trying to compile C code directly for an FPGA will result in syntax errors because FPGAs require HDL.
Another frequent issue is driver conflicts. Ensure that no other software is locking the USB port when you attempt to run your DAQ scripts. If using FPGA, verify that the bitstream size fits within the available logic elements of your specific NI-RIO module. Exceeding resource limits will cause synthesis to fail.
For more information on system stability during heavy computational loads, see
Troubleshooting High CPU Temperature Values. Overheating can also affect the performance of host-based DAQ operations.
Frequently Asked Questions
Can I use Simulink Real-Time with the USB-6363?
No, Simulink Real-Time requires a dedicated real-time target machine with a supported processor. The USB-6363 is a peripheral device controlled by the host OS. You must use the DAQ Toolbox on your main computer instead.
What software do I need for NI-RIO FPGA deployment?
You need HDL Coder to generate the hardware description language code. Additionally, you must have the appropriate vendor tools like Xilinx Vivado or Intel Quartus installed to synthesize the code for the specific FPGA chip.
Why does my C code fail to compile for an FPGA?
FPGAs do not understand standard C code. They require Verilog or VHDL. You must use a tool like HDL Coder to translate your algorithmic description into synthesizable hardware description language before deployment.
How do I check if my NI-DAQmx drivers are installed correctly?
Open the NI MAX (Measurement & Automation Explorer) application. Navigate to the Devices and Interfaces section. If your USB-6363 appears there and responds to diagnostics, your drivers are correctly installed.
Is fixed-point math necessary for FPGA designs?
While not strictly mandatory, it is highly recommended. Floating-point units consume a large amount of FPGA resources and power. Fixed-point math is more efficient and predictable for most digital signal processing tasks on FPGAs.