Electronic – Sample time of PI controller

closed loopfpgapid controllersampling

I have designed a closed loop current control (PI controller) of a DC-DC converter in continuous time domain and it is working fine. The next task is discreetization of the controller and implement it in FPGA Spartan 6. FSW is 40 kHz and I am sensing inductor current with an LEM sensor and then a low pass filter of 400 Hz and then into my ADC in designed hardware.

Now the question is while discreetization of controller, what sample time do I use? In VHDL code I have written, I calculate PI output at every rising edge of clk (50 Mhz). This would mean a TS of 20 ns. Could there be any issue with sampling so fast? My understanding is that I should sample at least a decade faster than the controller bandwidth, which I have designed to be at least a decade lower than my switching frequency.

Any advice is much appreciated.

Best Answer

I believe you are conflating two rules of thumb

separation in loop bandwidths when dealing with nested loops
Sampling of data

Loop bandwidth

There is a general rule of thumb that inner control loops should have a bandwidth around 10x that of the outloop. The reason for this is so the reactions of the inner loop should not result in any major changes in the outer loop.

Position (10Hz) -> Velocity ( 100Hz) -> Current (1kHz) -> Voltage (10kHz)

Why 10x ? consider a 1st order system,

\$ mag = \frac{1}{\sqrt{ \frac{f}{f_c}^2 + 1 }}\$

\$ angle = atan(\frac{f}{f_c}) \$

If the demand was capable of changing at the bandwidth of the loop there would be 70% reduction in magnitude and a 45deg phase shift.

By ensuring the inner loop is 10x that of the outer, the inner loop should be able to track demand changes to within 99.5% of its amplitude and 5degree while ensure any change in feedback is at the loops bandwidth.

As with all rules of thumb, take with a pinch of salt... Sometimes more separation is required, sometimes due to other constrains a smaller separation has to be tolerated. However, a rule of thumb is a good place to start.

Imagine if that separation was to shrink... the inner loops ability to react to demand changes starts becoming extremely restrictive to the point of instability: The additional phase shift in the forward path with regards to the resultant feedback producing a phase shift that can produce a feed-forward loop.

Digital PI

The implementation of a digital PI is essentially a gain, and accumulator and a summation. However, it is a bit more than that. There is typically three types of digital integrators

Forward Euler \$y_n = y_{n-1} + K_i \Delta t \cdot x_{n-1}\$
Backwards Euler \$y_n = y_{n-1} + K_i \Delta t \cdot x_{n}\$
Trapizoidal \$y_n = y_{n-1} + K_i \Delta t \cdot (x_n -x_{n-1})/2\$

\$K_i \Delta T\$ is typically just reduced to the integral time constant to simplify implimentation

The forward Euler is extremely unstable, especially with large integral timesteps. Backwards Euler is the workhorse of digital integrators and Trapizoidal is reserved for those wanting the additional accuracy.

From your working example you have stated three key pieces of infomation

Fsw = 40kHz -> The current loop could operate at 4kHz
Fclk = 50MHz
ADC sampling rate ????
Anti-Aliasing filter at 400Hz

Your present implementation has the PI operating at system clock rate. There is two issues with this but it isn't to do with whether the PI can operate as a PI

As previously mentioned, the gain of a digital integrator is proportional to the integration time-step \$\Delta T\$. If you want a relatively large integral time-constant with a low time-step, you will need a very large \$K_i\$ to realise a specific integral gain. A multiplication block that can accept a high value but also realise a specific resolution will be physically quite large. You may choose to just operate this as an accumulator but then your effective s-domain gain is that of your system clock.

The second problem is the harsh constrains you are imposing on the synthesis. In one system clock period you are expecting the synthesis tool to complete

Difference
Proportional multiplication
Backwards Euler (multiplication + addition)
Anti-windup checks
Final summation

This is quite a demand, especially when it really isn't needed. You have not stated the ADC sampling rate, but you have stated the analogue anti-aliasing filter.

With an anti-aliasing filter at 400Hz, you cannot be interested in any component above 4kHz ( 1% amplitude, 84degree phaseshift). If this is the case, why update the PI loop every 20ns when it is being present with new relevant information every 250us?

There is a massive disparity between your forward path and your feedback and this is fundamentally where the problem is. Your feedback should be acquired again at least 100x that of the loop in question. Why? the proportional term is extremely susceptible to feedback delays. If the bandwidth of the loop in question has a bandwidth which equals that of the forward path, the loop response will exhibit +5dB at the natural frequency, something you do not want

You have selected 40kHz switching frequency for some reason, hopefully due to a current ripple requirement with respect to the forcing voltage. I am going to assume the reason you have a 400Hz analogue LPF on the current feedback is to completely suppress the switching component.

My recommendation is

Confirm the needed switching frequency.
Tune your current loop to be a 10th of this.
Have the ADC's clocked at least 10x the switching frequency.
Strobe your PI loop at the ADC rate
Constraints on implementation such that the PI calculations are completed within the ADC sample window
IF the switching component is causing a problem, implement a biquad filter and tune it as a band-stop. This should roll off the 40kHz component a lot steeper than your 1st order analogue

Related Solutions

Electronic – Why is the simple counter VHDL not working? Where did the signals go

the rising_edge() parameter is only really for clock signals. One option would be the following:

clk_proc: process( clk, switch1, switch0 )
begin
    if switch1 = '1' then
        counter <= ( others => '0' );
    elseif rising_edge( clk ) then
        if switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

This is known as an asynchronously reset process, which means that it'll reset the counter whenever reset (switch1) is high, regardless of clock state. A synchronously reset process would look the same as your second example:

clk_proc: process( clk, switch1, switch0 )
begin
    if rising_edge( clk ) then
        if switch1 = '1' then
            counter <= ( others => '0' );
        elsif switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

You did state though that your second example didn't work as expected. My suspicion is that this is because the signals driving it are switches rather than clocked logic signals. Switches don't actually switch instantaneously, instead bouncing between on and off a few times before settling. You need to implement some sort of debounce process to produce a signal which is synchronous with your clock and can control your timer.

It's also worth mentioning that FPGA design is a lot easier if you simulate stuff first. Xilinx ISE includes a simulator - create a testbench and use it! That lets you easily see what's happening in your implementation before you ever get near hardware.

Electronic – Combining components and timing in VHDL (And probably verilog) / FPGA

It sounds like you understand this correctly. To answer your questions individually:

This could be a real problem, but the FPGA registers and clock infrastructure work in a way that means you do not have to worry about this problem in a fully synchronous system such as the one you have described.
There a few factors that allow you to reliably register data on the same clock edge that is altering said data:
- The hold times for internal registers are very small, well under 1 nanosecond in for example a Xilinx Spartan 6 FPGA, and less than 0.2 nanoseconds for the block memory in said FPGA.
- The clock network typically uses a very low skew design, so that the clock edge in one part of the FPGA happens very close in time to the edge in other parts. Contrast this with the data path, where your changing data signal has to propagate along the wire from one register to the next.
- Each clocked element has a propagation delay from it's D input to its Q output.
Combining these factors, when a clock edge occurs, the data seen by the second register (in your case a memory element) will not change until the register propagation delay plus the wire delay. As long as this total is more than the hold time for the receiving register, the design will work reliably. The clock skew does play a role here, but as before, this should (but see point 3.) be small compared to the other two factors.
Your FPGA design tool chain will perform very detailed timing analysis of the entire design, provided that you have given it the right information in the form of constraints. This analysis will include any internal clock skews, delays, temperature and process verations, etc. It is always important to create constraints for clock periods, and any I/O timing. With these in place, the tool chain will tell you if there were any timing problems in your design. Even though the particular scenario you describe would never actually have a timing problem, I think this is an important point.