analog sim of FPGA control loop

Why? If the system being driven has fusible wiring, why not just supply a socket for a fuse-of-choice? The customer can, one hopes, choose his fuse more easily than keep track of some software-program current limit.

It doesn't take an operator's manual to select/inspect/replace a physical fuse.

I sure wouldn't buy a power supply that blows a fuse every time it's overloaded.

The front-end of the customer's gadget, our load, is a shunt regulator. Sometimes that's a short.

What defines 'overloaded' isn't a power supply issue, though, it's the system being powered that defines a fault-current threshold.

Hmm. This is reminiscent of the secondary-breakdown test conundrum; it takes very fast shutdown (microseconds) to do nondestructive transistor testing. They sensed I and dI/dt both, and maybe looked for BE junction bias, too. Like in a transzorb, secondary breakdown caused the DUT to fail short.

I like to distrust programmed limits, because they don't usually log useful info about the event, and make it hard to trace a fault.

Why not use automatic fuses? If there is an overload, the fuse cuts out. When the overload is gone, it is re-enabled. This can be done automatically, or thermally, or with a reset signal from the controller. A programmable current limit seems overkill. You have the maximum current your system is specified to deliver, the maximum current you know it will tolerate, and you put an automatic fuse with a rating between these values.

I must be missing something here. Multiplying by 3 is simple - so simple that it barely makes sense to describe the steps for it. But if you find it hard in the design, do it with two additions. It is certainly vastly easier than multiplying by 0.75 !

Whats wrong with A+A+A = 3A ?

Yeah, or shift (to double) and add. But I think JLs point was that the

piglet

That's not what he wrote. He said he wanted to multiply by 3, and is doing it by shifting two bits (multiplying by 4), then multiplying by

But if your interpretation is correct, and you've figured out what he meant rather than what he said, then it makes a little more sense. Still, multiplying like this is not hard, even in an FPGA - any synthesis software will handle the details for you and give you a fast and compact multiplier for your FPGA of choice.

no it is not crazy, there is no difference it is just how you interpret the data

his data is in Q1.15 format thus in the range -1,+1 so he can't multiply by 3 but he can multiply by 0.75 (which is the same operation) and the interpret the result as if the decimal point was moved 2 (binary)places, iow shifted two bits so the range is now -4,+4 (Q3.13)

Yeah, I don't get that. I think he is saying he needs to do a calibration multiplication step, so the starting point for that will be 0.75 rather than 1.0 which eliminates a multiplication step in favor of moving the radix point.

I think much of the rationalization is being left out.

Multiplying by 0.75 in Q1.15 format is multiplying by 24576, then shifting right by 15. Then he shifts left by 2.

Ultimately it ends up with the same things - and synthesis tools can probably see that 24576 is 3 shifted left by 11 (if I've counted my bits correctly). But it is all just a lot of messing around due to a poor choice of formats and ranges.

Maybe there is more to this than he has indicated so far. Things change a lot, for example, if the factor is not actually 3 but a value in the region of 3 that is determined at run time.

the hardware is the same, some shifting and an add

x*2+x = x*3

(x/2+x/4)*4 = x*3

yes

The load is a FADEC. We are simulating the 3-phase PM alternator that powers it. The most common way to regulate a PM alternator is to short it when the rectified DC is too high. Even motorcycles do that. Every time you fly on a jet plane you are trusting your life to this process.

An automatic fuse would continuously crash and reboot the FADEC.

The FPGA logic uses 16-bit signed fractionals. That can only express values between +0.9999 and -1. So multiplying by 3 is worth thinking about some. The 0.75 is a tweakable cal factor to tune loop dynamics.

Eventually, after all our math is done, we have to load a 16-bit DAC and not do crazy stuff.

A 16x16 > 16 frctional multiply, by itself, is simple. One line of VHDL. But it only multiplies things in the +-1 range.

It doesn't fit into a 16-bit signed fractional, and the final DAC only goes 0 to 5 volts with 16 bit data.

My fix was a multiply by 4, then multiply by about 0.75, and constrain the result to (1,-1) to match the math format and the DAC bits. That forces the proportional term to rail now and then, which seems to be ok with the loop dynamics.

mandag den 11. januar 2021 kl. 17.26.42 UTC+1 skrev snipped-for-privacy@highlandsniptechnology.com:

it works for any range, you just have to keep track of where your decimal point ends up

The decimal point doesn't move in signed 16-bit fractional format. The DAC doesn't accept floating-point data.

That wasn't my point at all. The proportional gain term can clip now and then and does no harm.

According to the analog simulation, 3 is about right, but 2 would work almost as well. But 2 is also too big to fit into fractional 16 format, or into the DAC. Hence railing the gained-up proportional term, and doing saturating math everywhere.

The analog simulation was fast and, I think, demonstrates the consequences of railing and saturating and such.

I was sort of wondering if anyone else uses Spice to simulate the real-world issues in a fixed-point digital control loop. Probably not.

mandag den 11. januar 2021 kl. 17.52.58 UTC+1 skrev snipped-for-privacy@highlandsniptechnology.com:

by multiplying by 0.75 instead of 3 you have effectively moved the decimal point when you multiply by 4 you move it back, if won't always fit so you clip it which is fine

a more usual way of doing it would be to divide all the factors with 4 and do the x4 and clip on the final output just before the DAC