Power Electronics Development Center
timing error
Hey everyone
I run into a timing error when compiling the program. If I don’t add the last part of the program it can be successfully compiled. However if I add the attachment part the program takes long time to mapping, placing and routing and in the end give me some timing error
The subvi are some non-reentrant vi to do some simple math(+,-,*,\) to save some DSP48S resource noting is in a single cycle time-loop
i want to know what is the most common cuase for the timing error. Which part should i check or change the most to make this code compied
thank you
We only need your top level FPGA VI that you are trying to compile and its subVIs. There is an easy way to get them in a folder for zipping. Just open the top level FPGA VI and go to File>Save As. Then select the option at the bottom, Duplicate hierarchy to new location. Select a location outside your project folders like C:\temp\.. Then Zip up and attach the folder (while preserving it's structure). It should be smaller than the 75 MB attachment limit.
Here is an example. I'm excited about getting my Rotor Flux Observer for field oriented control of AC induction motors working (shown below) and want to share it. I open it in the LabVIEW Project and go to File>Save As and Duplicate hierarchy to new location.
The generated folder structure is shown below, which I've zipped up. I also need to tell you where the top level VI is located. In this case it is C:\temp\[FPGA] Float Rotor Flux Observer - Current Model Folder\Control & Signal Gen\[FPGA] Float Rotor Flux Observer - Current Model.vi.
BTW, here is a screenshot of a simulation run with the LabVIEW FPGA rotor flux observer. Download the main power electronics code library and install the NI Electric Motor Simulation Toolkit for this simulation testbench code.
I added the top level FPGA VI to a new project and did some test compiles for sbRIO-9606 GPIC and sbRIO-9607 GPIC targets.
Notes:
1. The FPGA build specifications are set to maximize the compilation effort at all stages.
2. I created dummy memory items (initialized to 0) to enable compilation. You'll need to delete these items and copy/paste from your project for the code to be run-able with correct behavior. In my case, I just wanted to find the timing problem so initializing to all the memories to 0 is fine since I won't be running the code.
3. I used the NI cloud compile service so I could run multiple test compiles simultaneously.
Test results:
1. On the sbRIO-9606 (Spartan-6 LX45) FPGA, the FPGA is so full it cannot successfully route all of the logic. Therefore it remains in the Place & Route stage for a very long period of time before failing to compile. When the FPGA becomes too full this will happen. You must reduce the FPGA resource utilization or use a larger target like the new sbRIO-9607 GPIC (industry kit, academic kit).
2. The application fits easily on the sbRIO-9607 GPIC but still fails to meet timing requirements in the theta calculation loop- in particular the multiplier has no feedback node afterwards and it is impossible to do both a multiple and add and the other operations within a single 40 MHz clock tick. This is identified as the culprit by clicking the Investigate Timing Violation button in the Compilation Status window.
Note that the routing delay is a significant portion of the overall execution time. Routing delay gets worse when the FPGA is full due to congestion within the chip- so you can expect this to fail timing more severely on the sbRIO-9606 GPIC. Here's a representation of the inside of a reconfigurable system on a chip (RSOC) FPGA with just a few routing wires shown-- it's a massive oversimplification but gives you the idea. Note that the sbRIO-9607 Zynq-7020 chipset contains the ARM microprocessors internally in the die as shown, whereas for the sbRIO-9606 Spartan-6 LX45 chipset the microprocessor is external and it is a PowerPC running VxWorks rather than RT Linux.
To fix the problem you will need to either:
A. add a feedback node pipeline stage after the high throughput multiple operation (shown below) and free up more FPGA space, or
B. modify the loop to be a normal while loop (shown below) rather than a single cycle timed loop (SCTL) and change the settings of the high throughput multiply operation to be configured for use outside SCTL and free up more FPGA space. I'm guessing you don't need to calculate theta in one clock tick.
3. I made a modified version of your FPGA application where I commented out (diagram disable structure) the following loops: 3 analog input scaling loops for current, quadrature encoder, data transfer, theta calculation, PWM. This compiled successfully on the sbRIO-9606 GPIC and reduced the FPGA utilization as follows.
3. Suggestions for reducing FPGA resource utilization.
A. You are using the same offset and gain for all three current sensors but duplicating the math operations three times. Use the same math operators for all three current sensors. Also, I don't know why you are setting the current values to zero when A, B, C are false. Also consider using RAW analog inputs rather than fixed point values (right click on RMC and go to properties).
B. Consider converting the whole application to floating point and reusing the math operators per guidelines here. Note that you won't get a benefit from doing a mix of floating point and fixed point, so if you go this way you have to go all the way to get the full resource sharing benefit. You can do the conversion quickly using the Find & Replace function in LabVIEW. Once you go floating point, you'll never look back. You just need to benchmark the loop rate performance (while running in actual FPGA hardware) and make good decisions about how to share resources (using the polymorphic non-reentrant math operators). Also, put a feedback node before each register that's output from one loop to another-- this eliminates any timing variations caused by resource sharing. (In single precision floating point, the only numerical issue you commonly have to worry about a math operation between a very large number and a very small number, where the difference is greater than 24 bits.) There are lots of examples of similar applications in floating point that you could use as a reference (i.e. induction motor V/Hz control, state-space solver, ABC to DQ transforms, etc.) in the LV 2015 power electronics IP & examples library.
I've attached the updated code and LabVIEW Project used to run the tests above. Note that all of the FPGA memory items are initialized to zero and need to be replaced with your properly initialized versions (simply by copy/paste from one project to the other).
I hope workshopping this code together is helpful for you and others on the community that are becoming powerful LabVIEW FPGA developers for advanced power electronics control applications. Keep up the great work! As a community I see you and many others accomplishing great things and really becoming advanced power developers. The goal is this: If you can dream up a control algorithm, you can implement it at FPGA speeds.
I am trying to design a 3-Ph Active Rectifier using the GPIC, and I'm interested in using floating point numbers this time.
I was able to modify availalbe AI scale loop for my application in SGL. Now the next step is to build a PLL. I am planning to start with a simple PLL by calculating atan2(-Vd,Vq) in stationary ref. frame.
Is there a atan2(Y,X) type function for SGL numbers in LabVIEW? Also are there any example codes in SGL for this kind of stuff?
