Need a crash course in FPGAs

[Altera_Forum]

I just, uh, "discovered" FPGAs about a week ago and from what I've learned so far, they seem perfectly suited for vector control of an induction motor, compared to running a 100k lines of C code through a DSP. 

 The big, surprisingly basic problem I've run up against is that I don't have a clue as to how to start using them!  In the end I might decide to just license IP from someone else, but I'm the kind of engineer that can't totally outsource even a piece of a design - I have to have at least a vague understanding of what is going on inside, e.g., the microcontroller running my megawatt power conversion hardware.  So far it seems to me that MATLAB/Simulink in conjunction with, e.g., DSP or SOPC Builder would allow me to translate block-level models into working hardware the quickest, but I'm not 100% sure of that. I also know that MATLAB is pretty pricey software for a small company like ours, but maybe it isn't so bad compared to licensing someone else's IP?   Anyway, my goal is to make an FPGA with enough processing power and ADCs in it to do vector control (field oriented [FOC] or direct torque [DTC]) with space vector modulation of an induction motor. A separate microcontroller running our standard UI will tell the FPGA how much torque it wants from the motor (with RPM a secondary consideration) and the FPGA will do all the tedious calculations that would otherwise cripple all but the fastest DSPs.  I might end up licensing IP from someone else - but I'd really like to know what goes on first to make an informed decision one way or the other.  Thanks for any help!

[Altera_Forum]

Easiest start would be to get a development board like the DE2  

http://www.altera.com/education/univ/materials/boards/de2/unv-de2-board.html and download Quartus II Then read a book or watch the training videos  http://www.altera.com/education/training/trn-index.jsp As for vector control of induction motors. I have read several papers written by academics on the topic.    It will take a few weeks/days to get aquainted with the language as it is a hardware description language whereas you are describing the logic you need for a certain design.

[Altera_Forum]

early on you'll want to consider if you need fixed or floating point calculations. also consider what sample rates you'll need and if there are any feedback paths (slow things down). try to break the algorithm down into pieces that can be done in parallel 

 if you are going to look at design services a block diagram is a good idea

[Altera_Forum]

--- Quote Start ---  As for vector control of induction motors. I have read several papers written by academics on the topic.   --- Quote End ---    Same here - it was because of a couple of academic papers I read (and one better-than-average thesis) that I saw some serious advantages in offloading all of the math-intensive motor control functions in an FPGA. Prior to that mini-revelation I was resigned to trying to get a 200MHz+ DSP to work inside a 200kW+ inverter.     --- Quote Start ---  It will take a few weeks/days to get aquainted with the language as it is a hardware description language whereas you are describing the logic you need for a certain design.  --- Quote End ---    Huh. No mention of MATLAB/Simulink, just get a dev kit and download (er, run on the web?) Quartus II? As we say with tongue firmly ensconced in cheek around here: How Hard Can It Be? :D

[Altera_Forum]

--- Quote Start ---  early on you'll want to consider if you need fixed or floating point calculations. also consider what sample rates you'll need and if there are any feedback paths (slow things down). try to break the algorithm down into pieces that can be done in parallel  if you are going to look at design services a block diagram is a good idea  --- Quote End ---    Most of the field oriented control schemes can benefit greatly from floating point calculations; the direct torque control schemes are generally much simpler. Space vector modulation definitely needs floating point if calculated on the fly; lower-performance versions are done with lookup tables.  I don't have any hard Altera part numbers, but one paper did FOC + SVM with a Xilinx Spartan 3E. Not sure (yet) what the equivalent Altera part is. A related question would be, is it possible to estimate how many "gates" I'll need to perform a certain function or group of functions without totally designing the functions in a HDL? Ie - to sort of do a first pass evaluation of it is feasible/economical to use an FPGA for the task(s)?

[Altera_Forum]

Estimating gate usage on large designs is pretty impossible. Its easier just to implement it. You can usually work out the memory and multiplier requirements though.  

 Floating point isnt really suited to FPGAs. you need cores that use a large amount of resources and the latency is higher. fixed point is what FPGAs are good at. you can get a fixed point toolbox for simulink that should help you with that.   The Altera equivolent of the spartan is the Cyclone. Unless you need loads of IO and high speed interfaces, cyclone should be ok for you.   But dont underestimate how hard your task is going to be. If you're a software guy, forget all you know and go back to logic basics before you go near any HDL. Software guys can write some really bad HDL. You have to design the circuit before you write any HDL. Often this may mean re-architecting your controller design to better match your implemented hardware. This also makes verification easier.

[Altera_Forum]

--- Quote Start ---  Estimating gate usage on large designs is pretty impossible. Its easier just to implement it. You can usually work out the memory and multiplier requirements though.   --- Quote End ---    Ok. That's not ideal but, well... nothing ever is, really.    --- Quote Start ---  Floating point isnt really suited to FPGAs. you need cores that use a large amount of resources and the latency is higher. fixed point is what FPGAs are good at. you can get a fixed point toolbox for simulink that should help you with that.   --- Quote End ---    *groan* - I thought that the massively parallel structure would effectively make them good at floating point?!    --- Quote Start ---  The Altera equivolent of the spartan is the Cyclone. Unless you need loads of IO and high speed interfaces, cyclone should be ok for you.   --- Quote End ---    Excellent. I don't need lots of I/O on the FPGA - just the inputs to the delta-sigma ADCs for monitoring phase current and bus voltage, and the encoder inputs for rotor position feedback. All the other i/o will be handled by the supervisory processor (probably one of those Stellaris ARM's with built-in ethernet MAC/PHY).    --- Quote Start ---  But dont underestimate how hard your task is going to be. If you're a software guy...  --- Quote End ---    Ah - I forgot to mention that. I'm the hardware guy. Worse is that my specialty is in high power switchmode conversion so I am probably hopelessly out of my depth here. I already figured that dumping this on our software guy wouldn't be good, and maybe taking it on myself wouldn't be any better, but it is, nevertheless, my responsibility to give this FPGA stuff a fair shake, maybe even the ol' college try, before buying/licensing IP or relying on the free motor control libs from TI for their DSPs.  That said, I still feel that putting the motor control functions into an FPGA is the way to go. It just seems like it will get the job done better and faster. I am basing this on relatively scant information at this point, I will admit, but it just seems right.

[Altera_Forum]

--- Quote Start ---   *groan* - I thought that the massively parallel structure would effectively make them good at floating point?! .  --- Quote End ---    The big question is do you really need floating point? do you really use the entire dynamic range? fixed point gives you good precision with the bonus that all the arithmatic is just integer arithmatic (using very few resources and 1 clock to complete).

[Altera_Forum]

--- Quote Start ---  The big question is do you really need floating point? do you really use the entire dynamic range?...  --- Quote End ---    Dunno for sure - that's technically above my pay grade (these days even janitor is above my pay grade, but that's another issue altogether)...  Hmm... I notice that a lot of these buggers run on 1.5V. 1.5V logic and 200kW motor drives tend to not get along. Definitely don't want to implement the ADCs in the FPGA if nothing else.

[Altera_Forum]

FPGAs dont have internal ADCs. You need external ones.

[Altera_Forum]

--- Quote Start ---  FPGAs dont have internal ADCs. You need external ones.  --- Quote End ---    That makes sense. An ADC that runs off 1.2 or 1.5V doesn't make much sense in my applications.  Anyway, I just downloaded and installed Quartus II - Web edition. My first impression is that the program is a bit intimidating, but also bass-ackwards. I have to choose a target device BEFORE I design the hardware??? Why can't I design the hardware then have Quartus tell me which devices will work?  I feel stymied already, and I haven't even placed a single pin. :(

[Altera_Forum]

--- Quote Start ---   Why can't I design the hardware then have Quartus tell me which devices will work?   --- Quote End ---    You can. Just set Quartus to auto select and it will chose a device to fit your design into. But in many cases, you need to design the board the same time you're designing the firmware. But its usually the IOs that is the most important.

[Altera_Forum]

--- Quote Start ---   I also know that MATLAB is pretty pricey software for a small company like ours, but maybe it isn't so bad compared to licensing someone else's IP?    --- Quote End ---    I'm unsure of the extent of your requirements, but you could look at some opensource alternatives to Matlab/Simulink, such as Octave/Scicos or SciLab. I did a quick search and found Scicos-HDL:  http://scicoshdl.sourceforge.net/projectscreenshots.html  which may or may not help depending on your requirements.   Remember that these projects are done independently of Altera or Xilinx (unlike MATLAB/Simulink) so I'm not very sure how well it would work. Worth giving it a try though, it's free anyway.

[Altera_Forum]

I have been doing Field Oriented Control in FPGA's before, well, it was even considered, going back to 2001 timeframe. Back in 1999, when I started, it was considered crazy. Now, beginning around 2005, every IEEE publication has a "FPGA" motor control topic. In short, I would say that it is getting more and more difficult for the DSP to compete with the FPGA, not only in terms of performance, but also cost. An Altera EP3C10 device in TQFP144 is very competitive . . .  

 There are many issues for you to address to build your design in an FPGA, and doing an induction machine controller is the most advanced AC drive versus even a permanent magnet synchronous machine (PMSM) or switched reluctance machine.   In short, I would suggest the following: 1. VHDL or System Verilog 2. Aldec Active-HDL cosimulation with Matlab/Simulink (I prefer this over Modelsim's solutions, as Aldec has a simple option for cosimulation versus buying yet another add on tool.) 3. Development boards 4. Go with fixed point implementation first, particularly on the PI controllers. I have had good performance with fixed point, and cosimulation between Simulink and your RTL simulation (Aldec) will give you good scaling results.   I have development kits available if you are interested.  James Bonanno Atlantix Engineering