How do hardware and software engineers talk to each other?
This is the extract from a recent conversation on LinkedIn between power electronics engineers of all different flavors. It sums up beautifully the issues between hardware and software engineers in digital power electronics control developments. (Names shortened to protect the innocent.)
‘Y. & A., I have no idea what half of the acronyms are which you (software) guys are using but, I get the feeling from A. that optimized C (whatever that is) is slower for a multiplication than assembly. Y. seems to be saying that a particular version of C he likes creates a faster multiplication.
So, I’m just left confused. Which is it?
I’m from the 80’s. This is when a multiply was a simple, understandable add-shift, add-shift,….repeat 8 times and you’re done. Many modern processors have one command – MUL AxB. Nowadays, digital guys are telling me that this method is so complicated. Why? Why is a simple multiply so complicated now when 30 yrs ago it was routine and easy to understand?’
Hamish from ELMG Digital Power
‘D. H. – there is a really big disconnect between the software able guys like Y. and the non software able guys ( I am guessing you – sorry if I am wrong). It is often that sort of cultural mis-alignment that causes lots of issues in the development. We fix the cultural alignment for companies sometimes. And its a process and there isn’t really an easy road and, I hate to say it, some teams go under doing it. We created our digital training course as the result of a customer R and D manager asking us when we were in the middle of a fix up “How could we have avoided this?” ‘
‘Hamish, You’re right about the cultural mismatch. (Yes, I’m not a software guy). My post a few days back concerned a software guy who had trouble communicating to me why his code was lengthy and complex, and I had trouble communicating with him as to why my view of a simple look-up table isn’t valid anymore. Maybe D. E. was correct, a “good” programmer should know how to deal with math.
Are these type of issues going to be addressed in your course?’
‘D. H. – In short yes. The slightly longer answer is. In the course we cover this culture issue both explicitly and implicitly. Team culture structure and organisation for digital power controllers are really important to success. And even more critical to sustained success when the “fix up” consultant has left the building. How we address this group culture issue in the course is by showing the attendees how to setup the conversation and documents so that the different types of people all can understand and contribute. Understanding and empathizing with the software engineers ethos, and what he values, is key to the power electronics converter engineer being able to do her job. And likewise. Engineers are technical people – which often speaks for itself in team dynamics. In the course we cover how matching the system partition to the team partition and to the system documents gives you a really good shot at success.’
‘D. H. , It is a known problem where software get hard time from hardware and vice versa ,many project fell because of this issue
I solved this problem long time ago when I decided to learn software (computer science ) after a good career as a hardware designer and since then all the hardware and software issue solve internally :-)’
Hamish from ELMG Digital Power
‘Y. is right that you can just learn it all; hardware, software and control. The problem comes when you leave the job and the team have to do it without you. Super engineers are great until they leave the team. And not every company can employ one and most companies prefer a team to manage this risk.’
Come to the course in Camarillo, California, August 22 through 24 and we’ll show you a good approach to dealing with this cultural mismatch.
How can I look at my digital signals in my power controller?
One of the big issues when working on digital control of power electronics is being able to look at the digital signals inside your controller. In order to see what is going on inside the control the digital signals need to be brought out so you can look at them.
When a DAC isn’t good enough.
One way to do this is with a digital to analog converter (DAC) where the digital stream is sent out as an analogue signal. These DAC channels are really useful and should be on every digital power electronics controller. However processing power usually limits the logging or data streaming to a DAC to a low number of channels. Each channel requires a scope channel of its own to do measurement. Any measurement is limited in length to the scope’s memory and the scopes sample rate.
ELMG Digital Power ControlScope
Data Collection in the Controller and Detecting Events
There is also the issue that collecting enough data to allow event detection such as;
single sample errors
underflow or precision loss and
bursty instability due to precision loss
can be a very difficult large load on the control processor and memory if the data logging rate is very high or if the rate of the problem is very low.
Control Scope Integrated into Digital Power Controller
To solve this problem we put the data collection and logging into the controller but without loading the controller.
Using the Xlinx Zynq system on a chip (SoC) we use the flexibility of running Linux on one of the two ARM 9 cores to provide the high speed gigabit Ethernet connectivity.
We also use the Linux for secure remote access if required.
Using ELMG Power Core IP blocks and know how we create firmware in the FPGA fabric of the Zynq. This connects to the Linux kernel and then the Linux user space. Data can be logged at full sample rates into SD cards or MMX memory and simultaneously out via the Gigabit Ethernet to the internet.
To be very clear no Linux code is included in the power electronics control function which is all implemented in the FPGA fabric on the Zynq.
Put a scope on the other end of the Ethernet
The video shows the ELMG ControlScope application connected to the ELMG Digital Power Zynq data collection system (named Dlog).
This system implements a fully functional oscilloscope that allows the internal operation of the digital control to be shown and logged.
With gigabit Ethernet logging rates of 25 M bytes per second are possible using Dlog.
This means that logging of your power converter performance and waveforms, scope function or debugging can be done over the internet.
To evaluate the Dlog and the ControlScope than click below.
Over the last two years ELMG Digital Power CTO, Dr. Hamish Laird, has helped supervise (the now Dr.) Rabia Nazir in the pursuit of her Doctoral studies.
Hamish Laird says
“The research that Rabia has completed in the area of fractional delays in recursive filters for current control in grid tied inverters gives great control tools in the implementation of control for GTIs in grids where the AC system frequency is varying. It is always great to help with PhD research as I learn so much so thanks to Rabia for letting me help.”
Congratulations to Dr. Rabia Nazir on her successful oral defense of here work. Dr Laird again
“It was fantastic to attend Rabia’s defense. I am so proud of and pleased with the work she did in analysing, simulating and building power converter hardware to show her findings. It was a great learning experience for me.”
Recently (now Dr.) Rabia Nazir presented a paper at a conference in Sicily on the use of Taylor Series expansion based fractional delay filters for recursive control of grid inverter currents.
In a recent discussion we were asked about the migration path from MCU/DSP to FPGA.
“I am probably not alone when I use MCU/DSP devices to implement control algorithms, protection, logic etc to control the power hardware, using code such as ASM, C or C++, but want the advantages of FPGA. What suggestions do you have to start this migration, both in terms of a cheap evaluation board, and software tools, that can be targeted at driving various topologies and speeds.”
Thanks to Anthony W. for the question. We get asked similar migration from MCU/DSP to FPGA for power electronics questions where the emphasis is more about retaining the value of an existing code base and coding team expertise while leveraging the flexibility of the FPGA.
As the first question states MCU/DSP devices are a common tool to implement control algorithms, protection, logic and sequencing for control power hardware, using code such as ASM, C or C++. However they do not have the power and flexibility of FPGAs. What is the best way to approach a migration from MCU/DSP to FPGA, both in terms of evaluation boards, and software tools, for a wide range of power electronic applications?
Best migration path MCU/DSP to FPGA for Power Electronics
There are a number of pathways to do this. The first one is High Level Synthesis. This is basically writing FPGA code in C. It is a very powerful tool but it does take some know how to make sure that you can get the most benefit out of the transition to FPGA. The downside of this is that it is quite expensive. There are however a couple of FPGA kits out there that do come with a kit-locked license (node-locked and locked to the FPGA model on the board).
Another way is to use an FPGA with a processor, or processors, inside it. These processor can be soft-cores like Xilinx’s Microblaze or hard-cores like the twin ARM A9s in Xilinx’s Zynq series. (Reports on FPGA development projects show that almost 50% have some sort of processor.) This processor allows you to directly port your code from your MCU/DSP to the Zynq/Microblaze and be ready to go. This may seem counter-productive as going from one processor to another without really gaining FPGA power is work for no reward. The advantages come when you move parts of your code (the high intensity tasks such as the control algorithms) from C to the FPGA hardware. This provides a power boost for the important parts of your code whilst still having the simplicity of C for the easy flow of your code. A good analogy would be that the FPGA parts are the equivalent of the ASM parts on the MCU/DSP but with the superman type speed advantage of doing things in parallel in the FPGA fabric.
Best of both
Xilinx has also combined the HLS and the C coding options with their SDSoC product. It is designed for the Zynq SoC . The coding is done in C. However you can use HLS to accelerate certain parts of the code for you to gain the most benefit.
Getting the most out of the Zynq solution does require either the expensive HLS toolchain and training in that or writing your own HDL. Another option is to purchase IP that other companies have written. This allows you to create a fast and efficient system without needing to know coding of an FPGA in HDL or C. ELMG Digital Power has a large suite of power electronics IP to get your application off the ground fast.
Prototyping and Development Platforms
In part 2 of this blog post, which is coming later, the answers to the questions
“How can I prototype this when the chip is BGA only?”
“What is an appropriate development platform or dev board?”