Motor Control with DSP builder Adv BlockSet

I have built several Field Oriented Controllers for induction machines and permanent magnet synchronous machines entirely in VHDL using Altera FPGA over the last then years.

IN short:

DSP Builder is somewhat useful, but a little bit over hyped. It tends to be clunky, but useful, particularly for "hardware in the loop" type testing. I have used it many times, and always end up writing native code and running a testbench at the VHDL level.

What I've found as a better tool is Aldec's Active HDL link to Simulink, it runs more reliability and is an excellent tool.

My suggestion:

Build a VHDL or Verilog based design, and create reference vectors in Matlab or Python.

Best, James

I would say that 10Ksps is too low for a decent Field Oriented Controller. Try at least 250 kSPS, using something like a PulsarADC from Analog Devices or the LTC1407 series from Linear, particularly for the current feedback.

Best, James

Hi James

Thanks for your input.

May I ask if your implementation is done in floating point or fixed point?

Also one of the selling point in the DSP builder is the logic Folding (Time-devision Multiplexing) that can minimize resource usage.

In our situation, the FPGA is limited to Cyclone III 3C25 or 3C40, the LEs may be a limiting factor.

Does the Aldec tool you mentioned do the same thing (TDM or somthing similar, Currently I am only using the ModelSim from Altera).

Your input is greatly appreciated.

Many thanks in advance

Steve Chan

Time Division Multiplexing? Hmmm. I don't see the need for this. Typically, a current loop FOC needs around 2500 LE's for a 12 bit datapath, that includes the clark transform, vector rotators, PI controllers, and SVPWM. I am not sure what Altera is touting here, but an FOC with a speed loop, sequential control unit to handle inputs, etc. shouldn't be any more that 4500 LE's. Of course, I implemented the rotators with a CORDIC algorithm, as well as compute square root with the vectoring mode of the CORDIC, so that helps. But I ran my latest FOC design at 100 MHz base clock for the entire design, with a loop execution time of around 1 usec.

Best,

James

James

Thanks

So you are using fixed point arithmetic.

The TDM I mentioned came from

/literature/wp/wp-01162-motor-control-toolflow.pdf?GSA_pos=1&WT.oss_r=1&WT.oss=field[/url] orient control

The floating point implementation is the one I am looking at. According to the graph in p.13 the Fixed point implementation is very close to what you are doing now.

I believe, I need to look up this CORDIC algorithm in my survey. Can you provide any pointers or reference?

Thanks for your input

Steve Chan

Ray Andraka's website has excellent references on the Cordic algorithm for FPGA implementation, and opencores.org does have a cordic available.

I have found excellent performance with the inner current/torque loop for a Field Oriented Controller in a fixed point format. For precision servo drives, double precision arithemetic or floating point can get you better performance for the position and or speed loops, particularly in a robotic type application. Notice I said double precision, which could be 16 bit for real and fractional parts, which is different from floating point.

James

Hi Steve,

Let me come in here with some background on the motor control toolflow using DSP Builder Advanced blockset highlighted in the whitepaper...

What Altera are showcasing here is a Matlab / Simulink design flow where a non-HDL designer can design their algorithm in Simulink with DSP Builder and then have the tool automatically generate VHDL for you that is optimized for the required latency, resource usage & device family. Folding or TDM is supported to allow hardware re-use of blocks such as multipliers and adders, and floating or fixed point data types can be mixed as necessary.

There are two demos shipped with DSP builder that cover a floating and fixed-point implementation of an example FOC algorithm with speed and position control.

As James mentions, another approach is to develop your own custom VHDL for the functions (park, clark, cordic, PI control etc) and create a bespoke implementation with good results. However this flow requires expert VHDL knowledge to get good implementation results whereas the DSP builder flow lets you design the algorithm and generate the VHDL automatically. So here we are trading off hand-written VHDL for a tool flow that generates the VHDL for you - with hopefully close to the same performance.

We have shown the DSP builder implementation of the FOC working reliably in hardware on the FalconEye FPGA dev kit from EBV. This uses a sample rate of 16kHz. The FalconEye reference design is available from EBV and the DSP builder FOC implementation is available from Altera. Both designs require license agreements (free of charge) to be signed for access to them.

-Kevin

Hi Kelvin

Thanks for your response.

This kind of information it exactly what I want from this survey.

So did you implement floating point in your motor control design.

Can your tell me about the total number of logic elements you used in the design, and the folding ratio (I believe you use the TDM).

I believe the DSP builder is a great way to go (if it work as advertised without too much caveat) just for the sake of the combination of the Design and implementation phase. It probably will be easier for documentation and maintenance too.

For writing the whole algorithm by hand in VHDL, it seems it will be tedious to arrange the state machine for reusing the same floating point arithmetic unit to save resource.

Hi James, what do you think of my thinking here? Please feel free to comment.

And Kelvin, Does the Falcon kit already come with the example design from using the DSP builder?

Many thanks in advance.

The reuse of various elements in the FOC algorithm is actually counter productive to having a smaller design. The hidden issue is the creation of wide bus muxes for the reuse of a given ALU configuration. In this regard, I recommend using the fixed point package now available for VHDL or using integer arithmetic. I do reuse the Cordic algorithm for rotation and inverse rotation, but the current feedback scaling, PI controllers, SVPWM, all have their own logic and arithmetic units.

The problem with Mathworks and Simulink is that its a great tool, but you will pay through the nose on these tools, and when there is an issue with hardware implementation, you are just familiar with the top level and you have to look at the bottom level to solve the issue. I equate it to TI giving away software so people will use there processors . . . . as crazy as it is to implement controllers in a TI DSP, giving away the software is simultaneously a nice gesture and indirect admission that there stuff is clunky.

As I mentioned before, the Aldec co-simulation tool is a better wager in terms of a mixture between high level and lower level design. Each VHDL/Verilog module can become a Simulink block, and then cosimulate between Simulink and Aldec. I recently did this with a PMSM type model in SimPowerSystems and Simulink with all the FOC core expressed as HDL blocks referencing the actual VHDL code. It's a client/server type approach made possible via the VHPI interface of VHDL. You need a decent computer to run this type of simulation, but it's very nice. And you are already at the VHDL level. Think of it as the inverse of the DSP builder approach: instead of having DSP builder generate the VHDL, you're simulating your own VHDL at the system level.

I did my first FOC controller in an FPGA in 2001, so have been at it for 11 years now on this technology.

James