What is the latest news from the Linkedin Digital Power Electronics Control group?
The group now has over 600 3440 members (as of January 25 2022). To join the group please click here.
In the group we have lively discussions with people contributing their knowledge and experience. To all who have contributed and made the group so much fun – a really big thank you.
In the group we have had discussions that cover
Digital PWM modulators
ADC (analogue to digital converters)
Choosing the number of bits in a digitally controller,
Implementing digital filters,
Processor choices and coding.
How many bits are required in digital control of power electronics
Recently the how many bits are required was brought up and addressed in this way by John S.
There are two aspects to selecting the number of bits: measurement resolution and control variable resolution. For measurement resolution, the ADC resolution is the deciding factor, and this can be increased by oversampling.
In a current control application I was recently working on, I required 14 bits of resolution to meet a target requirement of +-1% of ADC quantitization error at 10% current. This resolution was relatively simple to achieve by oversampling the 12 bit ADC in the uC.
The resolution of the control variable, e.g. uC timer resolution, is just as critical in fast systems. If the resolution is too coarse, jitter in the control variable will appear at the output. With slower system dynamics, e.g. in voltage controlled systems, jitter in the control variable causes less jitter in the output variable because of the smoothing effect of the output capacitor. Ideally the resolution of the control variable should match that of the measured variable.
Thanks John.
Thanks also to all the other contributors.
Other discussions cover measuring stability of power converters, what is the effect of PWM timer quantisation and what is the best converter for isolated bi-directional DC to DC.
We acquired a shiny Avnet Display Kit for use with our Microzed board. Our first project on this kit was a basic dash display demo, which ran Xilinx Linux on a Zynq 7Z010 SoC with the aid of some Xylon graphics IP. However we hit a speed bump in our progress. Our touchscreen wouldn’t work under Linux!
Problems with the touchscreen driver TMG210
After a few days of discussions with various forums and our local Xilinx FAE we found the problem. The touchscreen chipset was the same but as the chipset (the TMG120 from Cypress) is basically a touch screen microcontroller – it can come with various firmware. It turns out Avnet had changed the firmware supplier with a new version of the kit. Not worrying about this we looked into the Linux driver for the old firmware. We identified the key code and with the aid of some standalone code drivers which worked, changed a couple of lines and it worked. It still needs some work but it was good enough for our demo!
If you are having driver issues with your kit, feel free to download the changed C file Touchscreen Driver TMG120 below and enjoy:
One question which is commonly asked is “how do I represent fractional numbers on my fixed-point MCU, DSP or FPGA?” One of the best solutions to this is use of the Q number system.
The Q number system is a fixed point system where the available bits are divided amongst the integer bits (those to the left of the decimal point), fractional bits (those to the right of the decimal point) and a sign bit. You may ask “I know how integers are represented in binary but not fractions?” The answer is that just like integers, fractional bits are just multiplied by powers of two, except the powers are negative. For example:
0.011B = 0*2-1+1*2-2+1*2-3 = 0.375
Q numbers can take on multiple forms with different numbers of fractional and integer bits. They are commonly written mQn or Qm.n where m is the number of integer bits and n is the number of fractional bits. Note m+n+1 = total number of bits available.
Arithmetic
Addition/Subtraction:
Q numbers of the same form can be added together with no issue. The only thing to consider here is overflow.
If you have different forms they need to be converted before the arithmetic. This can be done by shifting. For example:
2Q13 << 1 is now 1Q14 (lose an integer bit and gain a fractional bit) and
3Q12 >> 1 is now 4Q11 (lose an fractional bit and gain an integer bit)
Multiplication:
The rule when multiplying two Q numbers together is:
m1Qn1 * m2Qn2 = (m1+m2)Q(n1+n2)
Once the multiplication is complete, then a shift is needed to get it into the Q format the system needs.
The big issue with multiplication is overflow and precision loss. When there exists m > 0, then scaling back to your original system is difficult. For example:
2Q13 * 2Q13 = 4Q26
In order to scale this back to the original 16 bits you either have to sacrifice integer bits (you have to be very careful that the top integer bits don’t contain information – limit the overflow) or lose precision by discarding fractional bits. The solution to this is to try and use systems where m=0.
Digital Control
Choosing the Q number system for digital control is important. The general rule of thumb is you want as much precision as possible and you want to avoid overflows in multiplication. Therefore the best solution is to make all your bits fractional (i.e. m=0). This gives as much precision as your system allows and makes sure there are no overflows (<1 x <1 = <1). In a 16-bit system this is 0Q15 (referred to as Q15).
Once you have your system then you need to make sure that all inputs and outputs fit this system and falls within the range -1 <= x < 1. This is as simple as setting your inputs and outputs to be +1 = full scale positive and -1 = full scale negative.
The key for this to work in a digital control system is to remember the gains on the inputs and outputs. This means remembering what +1 and -1 stand for. For example a voltage input may be -230V to +230V and an output maybe -400V to 400V. The input gain is therefore 1/230 and the output gain 400. Once you have these gains you need to include them in your design of the control system, whether it be through calculation or simulation. Failing to include them leads to incorrect margins and possibly instability.
One potential pitfall of the m=0 approach is how to deal with numbers greater than one. In digital control these can come up quite often generally in biquad filters. The trick is to this is to scale the coefficients by ½, perform the multiplies and then scale back by 2 (shift left 1). This does lose one bit of precision in this particular calculation however it is better than losing one fractional bit in all calculations.
Conclusion
Q number systems allow the designer to use a reliable fixed point system to represent fractional numbers. This allows the use of less expensive fixed point processors instead of the more complex and generally more expensive floating point alternatives.
If you are following the Zynq pathway for your new control platform for power electronics or another application then welcome to the Xilinx Zynq SoC adventure. The Zynq definitely is a great choice and has the benefits of being both a processor and an FPGA at the same time.
We have had Zynq SoCs at ELMG Digital Power for a about three years now and have been developing our competence. We have built up a Linux system on them in the past on one dev board. We are in the process of rebuilding it for another board for use with an LCD application. We are at the end of the process of moving our Spartan 6 IP cores onto 7 series (including Zynqs) for use in newer designs using the Vivado toolchain. We are also in the process of becoming certified Xilinx engineers through the Xilinx Alliance Program (XAP). This includes a large amount of training on the Zynqs directly from Xilinx.
ELMG Digital Power Membership of the Xilinx Alliance Program, XAP, means Zynq Asymmetric Multiprocessing know how and expertise.
Asymmetric Multiprocessing AMP
Asymmetric Multiprocessing a really powerful way of getting the best of both worlds (RTOS for real-time performance, Linux for ease of use, HMI and communications) on the one device. There are some pitfalls of using an RTOS for complex communication and Linux is not real-time. It is not trivial and comes with quite a few pitfalls and things that you must take care of. We have made some of these pitfalls so can help you with avoiding them.
These include the boot process and boot order as well as assigning which core is the ‘master’ and which is the ‘slave’. One of the main things to consider and plan out in an AMP system is resource allocation. Each core will need its own RAM whilst there must also be some shared RAM. Inter-processor communications will also need to be considered as well as peripheral access (both allocated and shared). Level 2 cache use also becomes more complicated. With correct planning and execution however, the Zynq AMP is the powerful tool that you need. Making full use of the capability is critical in getting a successful control system.
One of the great things about the Zynq System on Chip Asymmetric Multiprocessing AMP, is that certain engineers can do certain roles without knowing much about the Zynq as a whole. The HDL engineer can design modules with only knowing about the logic side and a software engineer can write code only knowing about the processor side. However, it is the bit in between which makes the Zynq so powerful and provides the magic that makes it run as a whole SoC. Getting data from the logic to the software in a timely manner is not as trivial as it sounds. One of the issues to be aware of is cache coherence. This is because the time it takes for the data to reach the software can range from clk cycles to hundreds even thousands of clock cycles depending on the interface used (for example it takes 25 clock cycles just to get to level 2 cache and many more if a DDR fetch is required). In control systems, this latency is important and choosing the correct interfaces for suitable data flow latency is key.
There are many of things to cover on the Zynq. This include partitioning who does what, logic or software?
This demonstration of a simple car dash on 7z010 Zynq SoC from Xilinx implements an touch screen automotive car dash cluster with speedometer and rev counter.
The hardware target is the Avnet MicroZed which is mounted on a carrier board. The LCD is a seven inch touch display.