1. FPGAs for HIL and Engine Simulation

2. Field-Programmable Gate Array (FPGA)
Configurable Logic Blocks (CLBs)
Implement logic using flip-flops and LUTs
Multipliers and DSPs
Implement signal processing using multiplier and multiplier-accumulate circuitry
Memory Blocks
Store data sets or values in user defined RAM
Programmable Interconnects
Route signals through the FPGA matrix
I/O Blocks
Directly access digital and analog I/O
At the highest level, FPGAs are reprogrammable silicon chips that are configured to implement custom hardware functionality.
They consist of logic blocks (digital logic), programmable interconnects, i/o blocks
FPGAs instantly take on a brand new “personality” when you recompile a different configuration of circuitry. Like a CD-RW
You don’t have to understand the low level technical details of FPGAs to use them…
For those of you not familiar with FPGAs, an FPGA is a device that contains a matrix of reconfigurable gate array logic circuitry. When an FPGA is configured, it's quite different from programming a processor. The internal circuitry is connected in a way that connects the hardware implementation of the software application. Unlike processors, FPGAs use dedicated hardware for processing logic and do not have an operating system. FPGAs are truly parallel in nature, so different processing operations do not have to compete for the same resources. As a result, the performance of one part of the application is not affected when additional processing or logic is added. Also, multiple control loops can run independently on a single FPGA device at different rates.
FPGA-based control systems can enforce critical interlock logic and can be designed to prevent I/O forcing by supervisory control algorithms, or an operator. However, unlike hardwired printed circuit board designs which have fixed hardware resources, FPGA based systems can literally rewire their internal circuitry to allow reconfiguration after the control system is deployed to the field. This is a big advantage in areas where the requirements and IP is changing rapidly.
FPGA devices deliver the performance and reliability of dedicated hardware circuitry. A single FPGA can replace thousands of discrete components by incorporating millions of logic gates in a single integrated circuit chip. The internal resources of the chip consist of a matrix of configurable logic blocks and hardcore DSP slices, and these are surrounded by a periphery of communication interconnect and I/O blocks. Signals are routed with the FPGA matrix by programmable interconnect switches and wire routes.
Now, a big game changer in the FPGA world over the past few years is the incorporation of hardcore DSP slices. These are like mini DSPs inside the FPGA fabric that can communicate with the outside world with very low latency. DSP slices are ideal for implementing IP for complex mathematics.
What is an FPGA?

3. FPGAs - Why Are They Useful?
Hard determinism – Realistic simulation timing, local intelligence
Off-load processing – Achieve real-time performance with more complex simulations
Custom Hardware – Create custom H/W instruments
Reconfigurable hardware personalities – Adapt to multiple UUT types and changing UUT interfaces
Industry standard technology – Off the shelf chips used for specific applications get COTS benefits like Moore’s Law

4. FPGAs in HIL Test Systems
Test Application IO
UUT
Signal
Conditioning
Let’s look at how FPGAs fit into a HIL test system architecture. A traditional HIL test system consists a microprocessor connected to IO devices that communicate with the unit under test (UUT).

5. FPGAs in HIL Test Systems
Personality IO
UUT
Signal
Conditioning
Test Application
<click>
When using FPGAs to develop HIL test systems, one or more FPGA devices are placed between the microprocessor and the IO devices allowing them to access the test system tasks being performed by the microprocessor as well as the IO devices communicating with the UUT.

6. FPGAs in HIL Test Systems
NI Reconfigurable I/O (RIO) Platform µP
FPGA
Personality IO
UUT
Test Application
Interfaces
Hardware I/O
Interfaces
Signal
Conditioning
Test Application
To implement this test architecture, National Instruments provides a Reconfigurable I/O platform that couples a programmable FPGA with modular signal conditioning interfaces that convert the UUT signals to levels that can be handled by the FPGA.
<click>
The FPGA can be programmed with traditional hardware descriptive languages or with NI LabVIEW Graphical Development Environment. To improve development efficiency, LabVIEW provides blocks that abstract the communication between the FPGA and the microprocessor and IO interfaces to configurable blocks seen here.
Let’s look at some examples of how this architecture is used to create more powerful and flexible HIL test systems.

7. Mechanical Systems – Engine Sensor SimulationµP
FPGA
(Engine Simulation)
I/O
UUT
RPMs
Crank
The grey block in this FPGA personality receives the current engine RPM value from plant simulation executing on the test system microprocessor and the generation of the simulated position sensor output is performed by the block in the middle. The blue block in this personality is used to specify the tooth pattern being used for this particular test.
Using this FPGA architecture, the processing necessary to generate the position signal corresponding to engine speed has been off-loaded to the FPGA - increasing the bandwidth available in the microprocessor to perform other test system tasks. Additionally, if the simulation of other mechanically coupled sensors such as a cam shaft sensor was necessary, the FPGA architecture is ideally suited for this task because of the nanosecond timing resolution and true parallelism it provides to preserve this relationship.

8. Free Engine Simulation Toolkit
Fully featured for Engine Control Unit (ECU) testing
FPGA-based sensor simulation and measurement for ultra-fast pin-to-pin response time & lifetime upgradability
Seamless integration with NI FPGA hardware and NI VeriStand
Scalable design for simple to complex ECU testing
Suitable for open loop or closed loop
Open source architecture customizable with LabVIEW FPGA
Supports any NI FPGA device
Deploy with NI VeriStand 2013 or later
Design with LabVIEW 2013 or later

9. Engine Simulation Toolkit Building Blocks
CPU
FPGA
ECU Event Waveform Capture
Angle Processing Unit (APU)
Digital Pattern Generation
(i.e. Hall)
ECU Event Waveform Capture
Digital Pattern Generation
ECU Event Waveform Capture
Digital Pattern Generation
Directional Sensor Simulation
Analog Replay (i.e. VR)
Directional Sensor Simulation
Analog Data Replay
Directional Sensor Simulation
Analog Data Replay
Slide has animations
Note we will not talk about the individual IP here, we do that later. This is just the overview.
The easiest way to describe how to create an engine controller HIL with a CPU and FPGA is with a block diagram showing the building blocks of the tester. First we start with the Engine Physics model running on the CPU. This talks back and forth with the FPGA personality built with the position simulation libraries provided by NI.
Animate. The main block in the FPGA is the Angle Processing Unit (APU) that takes speed from the physics model and simulates the rotational position of the engine.
Animate. It makes the variables for Speed, Crank Angle, and Cycle Angle available to the entire FPGA (like a global variable) so additional FPGA logic can be tied to speed or position easily.
Animate. We can attach foundational FPGA IP libraries like Digital Pattern Generation, Analog Data Replay, and ECU Event Timing Capture to this variable easily
Animate. We can also attach any other IP like ECU Event Waveform Capture, Directional Sensor Simulation, and Knock Sensor simulation
Animate. Finally, we can add any number of these IP blocks to do more stuff on a single FPGA. This means you can customize your particular FPGA personality depending on what your needs are and take advantage of the cost savings of a small FPGA or the flexibility of a large FPGA. As newer FPGAs are released giving more size for less $, you benefit
Knock Sensor Simulation
ECU Event Timing Capture
(Inject & Ignite)
Knock Sensor Simulation
ECU Event Timing Capture
Knock Sensor Simulation
ECU Event Timing Capture
Speed, Crank Angle, Cycle Angle

10. Engine Simulation Toolkit Roadmap
Item
Old AES Library
Angle Processing Unit (APU)
2 and 4 stroke engines
Digital Pattern Generation
N-M Teeth Generation
Custom Edges Generation
Analog Replay
Play back any file by angle
ECU Event Measurement
Digital input timing capture of single event per cycle
Knock Sensor
N/A
Directional Speed Sensor
FPGA space utilization
Baseline
The AES library has a long history at NI and many customers have used it and provided us feedback.

11. Engine Simulation Toolkit Roadmap
Item
Old AES Library
Engine Simulation Toolkit
Angle Processing Unit (APU)
2 and 4 stroke engines
Improved usability
Digital Pattern Generation
N-M Teeth Generation
Custom Edges Generation
Analog Replay
Play back any file by angle
ECU Event Measurement
Digital input timing capture of single event per cycle
Windowing, multi-event per cycle, error detection, & improved usability
Knock Sensor
N/A
Pseudorandom, amplitude & probability per cylinder.
Directional Speed Sensor
Different forward/reverse digital pulse width triggered at tooth centers
FPGA space utilization
Baseline
3x Reduction

12. Engine Simulation Toolkit Roadmap
Item
Old AES Library
Engine Simulation Toolkit
Q4 2014
Angle Processing Unit (APU)
2 and 4 stroke engines
Improved usability
Digital Pattern Generation
N-M Teeth Generation
Custom Edges Generation
Analog Replay
Play back any file by angle
ECU Event Measurement
Digital input timing capture of single event per cycle
Windowing, multi-event per cycle, error detection, & improved usability
Analog input thresholding and waveform capture
Knock Sensor
N/A
Pseudorandom, amplitude & probability per cylinder.
Directional Speed Sensor
Different forward/reverse digital pulse width triggered at tooth centers
FPGA space utilization
Baseline
3x Reduction
In q we will be releasing new IP for ECU event waveform capture & thresholding

13. Space and performance comparison
PXIe 8130
PXIe 1082
AES Library
1 APU
1 N-M generation
4 Fully Custom generation
1 Analog Replay
12 Event Capture
Engine Simulation Toolkit
5 Digital Pattern Generation
Slices
6,703 of 17,280 (38.8%)
3,159 of 17,280 (18.3%)
Registers
14,882 of 69,120 (21.5%)
5,912 of 69,120 (8.6%)
LUTs
19,702 of 69,120 (28.5%)
8,239 of 69,120 (11.9%)
DSP
24 of 64 (37.5%)
2 of 64 (3.1%)
BRAM
21 of 128 (37.5%)
13 of 128 (10.2%)
40 Mhz Max
42.69
65.35
Compile time
37 minutes
21.7 minutes
RT Loop
Duration
305 to 335 uS
138 to 186 uS w/ RIO to 165 uS w/ RIO 15.0

14. Reconfigurable I/O Interfaces
V6 ECU µP
FPGA
I/O
V8 ECU
The ease with which FPGAs can be reconfigured to create custom hardware IO interfaces makes it possible to build a single HIL test system capable of adapting to multiple UUT types as well as changes to a UUT interface that occur during the development process. For example, a single HIL test system can be used to test several types of engine control units by simply changing the FPGA personality to provide the appropriate IO interface between the HIL test system and the unit under test.
Multiple UUT types
Evolution of UUT interface

15. NI VeriStand System Explorer

16. Analog Replay

17. Analog Replay Configuration
Load data from any dataplugin

18. Analog Replay: Voltage Scaling Configuration

19. Example FPGA: APU + 1 Analog Replay
Load Look Up Table
Walk through this.
Left most loop loads the memory with the look up table data from the host.
Top loop is the APU, which writes to the registers (the globals) of speed, crank & cycle angle.
Bottom right loop is the playback loop going out AO0 of this card
Play Look Up Table

20. Example FPGA : APU + 2 Analog Replay
Same as last one but we dropped two of the replay load loops instead of one and there are two playback subVIs instead of 1.

21. Digital Pattern Generation

22. Digital Pattern Generation of Two Cams and a Crank
This is a prototyping UI I used during development. This will eventually be inside NI VeriStand

23. Digital Pattern Generation Design
Define base pattern
Add and remove edges at specific locations

24. Digital Pattern Generation supports complex patterns easily

25. Example FPGA: 2 Digital Pattern Generations
Very similar to analog replay. We load a memory per pattern with edges and play it out.

26. Knock Sensor Simulation

27. Knock Sensor Simulation Configuration
Leverages FPGA technology to provide true pseudorandom generation
Configurable probability (0-100%) and amplitude
Base frequency can be hard coded or scale with engine speed

28. Example FPGA: Knock Sensor Simulation Loop

29. Knock Sensor with 4 Cylinders
This is a simulation VI. Real thing could be captured with a scope
(Probably had been set to 100% with 4 different amplitudes)

30. Directional Speed Sensor Simulation

31. Directional Speed Sensor
Generates pulses of different widths, depending on forward (Tf) or reverse (Tr) rotation, when passing tooth centers
Pulse slightly delayed from center by variable microseconds (Td)
Directional sensor: forward
Directional sensor: reverse
Crank

32. Directional Speed Sensor

33. Example FPGA: 1 Directional Speed Sensor
Load Tooth Centers Look Up Table
From APU

34. ECU Event Capture

35. Example FPGA : Typical MPI Injection Measurement (1 x Cylinder)
Event measurement block outputs:
Stuck active (Boolean)
Window all active (Boolean)
Window orphan start edge (Boolean)
Window orphan end edge (Boolean)
Digital Input
The measurement block does event measurements with respect to the window and time and has some general outputs about the measurement, mostly concerning errors. It will let you know if the event has stuck active because its been active longer than the timeout. It will also let you know if the event is active the whole window, or if there were orphaned start and end edges of an event inside the window (meaning half an event was present).
ECU event timing input can be done with any speed digital inputs and does not need to be in an SCTL. The resolution and accuracy of the data will reflect the speed of the digital inputs.
Event capture latches in data about a specific event # inside the window. You set which event you’re interested in latching the data for and it grabs if it was present, start angle, end angle, and duration.
Max and Min angle can wrap 0. For example a valid window is degrees. So is -100 to 200 degrees.
Capture outputs are in respect to a reference angle specified during host configuration. So if the start angle is 490 degrees and the reference angle is 500 degrees the start angle = -10 degrees. (Reference angle correction is actually done on host, not FPGA)
Event measurement block settings:
Angle Max (degrees)
Angle Min (degrees)
Active High (Boolean)
Time based ‘stuck active’ timeout (milliseconds)
Event capture block outputs:
Event Present (Boolean)
Start Angle (degrees)
End Angle (degrees)
Duration (milliseconds)

36. Example FPGA : Typical GDI or Diesel Injection Measurement (1 x Cylinder)

37. Example FPGA : Typical GDI or Diesel Injection Measurement (2 x Cylinder)

38. Example FPGA : Customize Windowing Per Event
Here you can apply a window (min/max angle) for capture on each event on a single digital pin in any configuration you like

39. ECU Event Capture Configuration

40. ECU Event Capture Configuration

41. Generation and measurement of two events neither wrapping 0 and window does not wrap 0
This is a prototyping UI I used during development.

42. Generation of one event wrapping zero and one not wrapping zero; window wraps zero and measures both
This is a prototyping UI I used during development.

43. Start of a full cycle event within window, causing an orphan start edge and a stuck active flag
This is a prototyping UI I used during development.

44. End of full cycle event within next window, causing an orphan end edge
This is a prototyping UI I used during development.

45. Future* FPGA : Typical GDI or Diesel Injection Timing & Waveform Measurement
Analog Input
Thresholding
Timing Measurement and Capture
Here you can apply a window (min/max angle) for capture on each event on a single digital pin
Waveform capture
*Q4 2014

46. Case Study Application
Creating a flexible HIL test system with I/O interfaces that require custom timing and synchronization schemes not easily implementable with traditional hardware.
NI Products
LabVIEW FPGA Module, PXI, and Reconfigurable I/O (RIO) hardware
Key Benefit
Gaining the ability to efficiently create custom hardware interfaces that can be reconfigured after deployment to adapt to different ECU types and changes to ECU interfaces.
"With LabVIEW FPGA and RIO hardware we were able to quickly and efficiently design custom analog and digital interfaces for our HIL test system.”
– Roy Kranz, Wineman Technology Inc.
HIL test system provider, Wineman Technologies, uses LabVIEW programmed reconfigurable IO devices in all of their HIL test systems because they provide the ability to quickly and efficiently design custom IO interfaces that can be easily reconfigured to adapt to different ECU types as well as changes to ECU interfaces.

47. Summary
FPGA-based I/O interfaces are used to expand the capabilities and performance of HIL test systems.
Hard determinism – Realistic simulation timing and local intelligence with 25 ns resolution
Off-load processing – Achieve real-time performance with more complex simulations
Custom Hardware – Create custom H/W instruments
Industry standard technology – Off the shelf chips used for specific applications get COTS benefits
Reconfigurable hardware personalities – Test multiple UUT types and adapt to changes in UUT interfaces without changing hardware
FPGAs enable test system developers to create custom hardware that can be easily reconfigured without physically modifying the device. In addition to being reconfigurable, for certain applications, FPGAs can offer superior performance compared to microprocessors due to the true parallelism and nanosecond determinism they provide.
In today's presentation, we looked at several examples of how the hard determinism, ability to off-load processing from the test system microprocessor, and capability to create custom, reconfigurable IO allow HIL test system developers to lowering total system cost and improving its performance.