What do you think of the new system level design methodology and platform for FPGA-based power electronics control?

[BMac]

If you have  test driven the new LabVIEW FPGA/Multisim co-simulation tools, would you mind sharing a few comments on your experiences and thoughts?

Please share some comments, positive or negative, related to the following:

• How do the new graphical system design tools for power electronics compare to other tools you have used?
• What are the benefits of being able to test your actual embedded FPGA code in the co-simulation environment, rather than a model of the embedded code that must be hand-tweaked after code generation?
• What are benefits of being able to test your simulated and physical SMPS control system using the same software tools and reuse your test code and FPGA code throughout development? 
• What are the benefit of using commercial off the shelf (COTS) embedded systems like NI Single-Board RIO and CompactRIO rather than doing full custom embedded design?
• How are we doing on advancing forward with the "NI vision for power electronics"? What do you expect to be the impact for your product development, research or teaching efforts? Are we focused on the right things?

Here are some of the primary goals of the the NI R&D investments to deliver an improved toolchain for power electronics design. How are we doing on these 7 items, based on your experiences with the new tools?

REQUIREMENTS FOR SYSTEM LEVEL METHODOLOGY AND PLATFORM

This section examines the application-specific needs of SMPS designers and researchers in regards to system-level FPGA programming tools and introduces a new platform developed through significant commercial R&D effort in consultation with researchers and commercial design engineers.

Key Requirements

1. The system-level FPGA design tool must integrate with a full-featured power electronics circuit simulator in a way that provides behaviorally and temporally accurate co-simulation to capture the high-speed, coupled dynamic interaction between the FPGA and the SMPS. The simulation platform must also have the capability to model power device parasitic elements, thermal effects and other non-idealities as required to discover design flaws before target deployment.
2. The software development flow should be bi-directional rather than unidirectional. Changes made to FPGA code at any stage from prototype to post-production should automatically be reflected wherever the synthesized code is referenced in the tool-chain, thereby enabling automated testing.
3. The FPGA resource utilization efficiency must be comparable to hand written register transfer level (RTL) code, thereby eliminating the need to hand tweak and thereby “contaminate” the generated code.
4. The FPGA code used in the final target must be exactly identical to the code used for design validation simulations. While this seems obvious, most designs today use different sets of code in the system-level simulation and the final hardware target, thereby invaliding simulation results.
5. The tool must include fixed-point math blocks and power electronics IP libraries that enable efficient development of fixed-point control, signal processing and power analysis algorithms.
6. The tool must target pre-validated COTS control boards which meet the specific control, I/O and performance and cost needs of modern high volume commercial SMPS products.
7. The tool should also be suitable for developing fast, real-time hardware-in-the-loop (HIL) SMPS simulators for the purpose of enabling comprehensive validation of the production control system.

If you prefer to share your comments more privately, just shoot me an email at brian.maccleery@ni.com.