Modules#
Here we introduce the models that has been created in order to deal with the programming and repetitive/similar tasks.
module debounce_core #(
parameter DEBOUNCE_TIME = 5000
)(
output o_switch,
input i_clk,
input i_reset,
input i_switch
);
module debounce #(
parameter DEBOUNCE_TIME = 5000,
parameter N = 1
)(
output [N-1:0] o_switch,
input i_clk,
input i_reset,
input [N-1:0] i_switch
);
Converter Simulator#
The objective is to have some blocks able to simulate, i.e. compute the next value, the current and voltage in a resonant convert. These values are used to test the part in a more realistic scenario.
SRC simulator#
The dynamics equations governing the SRC are the following
LLC simulator#
We can model the part before the rectifier considering an equivalent resistor as load. This is reasonable since the input current and voltage of the rectifier are in-phase. The three state that we chose to describe the system are \((v_C,i_S,v_o)\), the dynamical equations are:are
Now, we want to move toward a digital implementation of a module that can simulate the behavior, i.e. integrate the differential equations. Since it is quite a simple dynamics, we can rely on explicit Euler integration scheme:
Moreover, in the FPGA we can only work (in our setting) with integer numbers, therefore we need to ensure sufficient precision to not lose too much information. With this is mind, we apply the following modifications:
All the parameters are described by integers.
The states are described by submultiples.
Relative magnitude will be joined together.
If a constant appear to be smaller than zero in magnitude, we can adjust by multiply and divide by a power of two (which then correspond to a logic shift).
With this in mind, we can apply the following change of dimensions:
With these transformations, we can write the following equivalent discrete dynamical equations
where we can highlight the coefficient multiplying the variables and scale them in order to have only integer operations
Note
Indeed, going to an integer representation of the parameters is pretty useless if then we combine them all in a unique constant.
In a compact way, we can write:
In the end, we reach this representation that can be implemented in an FPGA. To compute the parameters we have the following Python script
# parameters
L = 10 # uH
C = 850 # nF
Lm = 36 # uH
Req = 10000 # mOhm
Vg = 48000 # mV
dt = 10 # ns
print('Considering integer operations')
print(' mu_1 = '+str(round( (dt*(2**20))/(1000*C),2)))
print(' mu_2 = '+str(round(-dt/L,2)))
print(' mu_3 = '+str(round( (dt*Vg)/L,2)))
print(' mu_4 = '+str(round(-(dt*Req*(2**10))/(L*1e6),2)))
print(' mu_5 = '+str(round(-(dt*Req*(2**17))*(1+L/Lm)/(L*1e6),2)))
print(' mu_6 = '+str(round( (dt*Req*Vg)/(L*1e6),2)))
Computation of the gain without considering the normalization wrt the unit of measure
mu(1) = round( (dt*(2^20))/(1000*Cr),2);
mu(2) = round(-dt/Lr*1e3,2);
mu(3) = round( (dt*Vg*1e6)/Lr,2);
mu(4) = round(-(dt*Req*(2^10))/(Lr),2);
mu(5) = round(-(dt*Req*(2^17))*(1+Lr/Lm)/(Lr),2);
mu(6) = round( (dt*Req*Vg)/(Lr*1e-3),2);
Then, the modules code is the following (take care of the priority of the arithmetic operations over logic one):
module simulator_LLC #(
parameter mu_1 = 12,
parameter mu_2 = -1,
parameter mu_3 = 48000,
parameter mu_4 = -10,
parameter mu_5 = -1675,
parameter mu_6 = 480
)(
output signed [31:0] vC_p,
output signed [31:0] iS_p,
output signed [31:0] Vo_p,
input CLK,
input RESET,
input signed [1:0] sigma
);
// INTERNAL VARIABLE
integer vC; // equivalent to reg signed [31:0] vC;
integer iS;
integer Vo;
wire signed [31:0] sigma_32;
// assign output variable
assign vC_p = vC;
assign iS_p = iS;
assign Vo_p = Vo;
assign sigma_32 = { {30{sigma[1]}} , sigma };
// variable initialization
initial begin
vC = 0;
iS = 0;
Vo = 0;
end
always @(posedge CLK or negedge RESET) begin
if (~RESET) begin
vC <= 0;
iS <= 0;
Vo <= 0;
end else begin
vC <= vC + ((mu_1*iS)>>>20);
iS <= iS + mu_2*(vC + Vo) + mu_3*sigma_32;
Vo <= Vo + ((mu_4*vC)>>>10) + ((mu_5*Vo)>>>17) + mu_6*sigma_32;
end
end
endmodule