using FPGA in control field

Hi all,

I want to use FPGA in control field. I know that uC or DSP processor is
a preferable choice to control engineer in general. But in my opinion,
the HDL-based logic inside FPGA is more appropriate for those high
performance needed but simple function tasks just as the role of a
controller in control system, while the C language can realize
complicated application. i.e. In my  control system, the controller
will be based on HDL inside FPGA to get a extremely high performance
and high reliability, while the rest of the work, such as
communication, data processing and human-machine interface will be
based on C language to get a more flexible system.

Certainly, the C-based embedded system may be implemented inside FPGA
to form a SOC system  and may be based on an OS for more convinent.

Can anyone give me some advice and papers about this idea?  thans a
lot.

Best Regards,

Wicky

wicky wrote:

> Hi all,
> 
> I want to use FPGA in control field. I know that uC or DSP processor is
> a preferable choice to control engineer in general. But in my opinion,
> the HDL-based logic inside FPGA is more appropriate for those high
> performance needed but simple function tasks just as the role of a
> controller in control system, while the C language can realize
> complicated application. i.e. In my  control system, the controller
> will be based on HDL inside FPGA to get a extremely high performance
> and high reliability, while the rest of the work, such as
> communication, data processing and human-machine interface will be
> based on C language to get a more flexible system.
> 
> Certainly, the C-based embedded system may be implemented inside FPGA
> to form a SOC system  and may be based on an OS for more convinent.
> 
> Can anyone give me some advice and papers about this idea?  thans a
> lot.
> 
> Best Regards,
> 
> Wicky
> 
Look at the highest sampling rate that will make a difference given the 
limitations of your plant.  If it's 10kHz or lower then you can just 
code your loop in C, run it on one of the newer DSP chips, and not have 
to mess around with FPGAs at all.  If it's 50kHz or lower then with a 
slight bit of extra work one of the newer DSP chips can be used with a 
moderate amount of assembly code and a careful trimming of other 
functionality.  If it's 100-200kHz then one of the newer DSP chips can 
be used, but the level of work necessary may be greater than the level 
of work necessary for your FPGA.

It's the rare plant that needs a loop sampling rate greater than 5-10kHz.

Don't expect the control rule to be all that simple -- one of the 
advantages of implementing a controller on a processor is that you can 
wrap it with all sorts of nonlinear frills to take care of corner cases 
that in an analog system you'd just have to live with, or do everything 
in your power to avoid.

Think hard about the reliability of implementing your controller in an 
FPGA.  Why should 1000 lines of Verilog be more reliable than 200 lines 
of C?

Ask yourself why you are stuck on one particular technology for 
implementing your control rule.  Control rules are just math; you should 
pick the implementation technology that makes the most sense for the 
problem at hand, be it a processor, FPGA, vacuum tube or hemp ropes and 
spinning mahogany drums.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Thanks for your rapid reply.

In fact, just as you said, It's the rare plant that needs a HDL-based
controller now, most of them will implemented with a DSP controller and
works well.

For the reliability, I know that HDL will be more complicated than C
language, what i mean is that something in hardware must be stronger
than that in software theoretically. As for the problem of code writing
of HDL, I think that G-language (graphic language tools such as DSP
Builder or System Generator) will decrease the difficulty observably.
Of course, they may loss some efficiency, but for the extremely high
performance you get in HDL controller, this problem will be less
sensitive than that of C language.

Now, G-language toos aren't mature enough. They can only generate codes
from simulink for some simple algorithm such as PID, if you want to try
some advanced alogrithm toolbox in simulink, you must write HDL codes
in hand.

For the consideration of cost, I think a HDL-based PID controller in a
low-cost FPGA such as ep1c6 will get at least a 10 times performance
than that of C2000 serials DSP  controller of TI.

Best regards,

Wicky

wicky wrote:
> For the reliability, I know that HDL will be more complicated than C
> language, what i mean is that something in hardware must be stronger
> than that in software theoretically. As for the problem of code writing
> of HDL, I think that G-language (graphic language tools such as DSP
> Builder or System Generator) will decrease the difficulty observably.
> Of course, they may loss some efficiency, but for the extremely high
> performance you get in HDL controller, this problem will be less
> sensitive than that of C language.


With good sized FPGA's falling in price, especially those with
processor cores or big enough for a soft processor core, it's actually
not that bad a design decision, and should just get better with time.

Consider Celoxica (Handel-C), Impulse (Streams-C) or even FpgaC as both
an HDL and an HLL for a lot of projects which might migrate from
microprocessors/DSP to FPGA.

"wicky" <wicky.zhang@gmail.com> wrote in message 
news:1139670926.240198.163270@f14g2000cwb.googlegroups.com...
> Hi all,
>
> I want to use FPGA in control field. I know that uC or DSP processor is
> a preferable choice to control engineer in general. But in my opinion,
> the HDL-based logic inside FPGA is more appropriate for those high
> performance needed but simple function tasks just as the role of a
> controller in control system, while the C language can realize
> complicated application. i.e. In my  control system, the controller
> will be based on HDL inside FPGA to get a extremely high performance
> and high reliability, while the rest of the work, such as
> communication, data processing and human-machine interface will be
> based on C language to get a more flexible system.
>
> Certainly, the C-based embedded system may be implemented inside FPGA
> to form a SOC system  and may be based on an OS for more convinent.
>
> Can anyone give me some advice and papers about this idea?  thans a
> lot.
>
> Best Regards,
>
> Wicky
>

I did this recently using only an FPGA, with no host CPU. As you suggest, 
the FPGA is great for creating high performance control functions (in my 
case the performance wasn't high - just a phase controlled SCR drive, but 
things like feedback filtering, PLL's for synchronizing, etc etc)

Since I had no host, I also implemented a communications protocol for a 
tuning and monitoring application hosted on a PC - I really wouldn't 
recommend this, such things are much easier in a processor.

One piece of advice - if you can afford it, use an FPGA with embedded 
multiplier blocks and plentiful RAM. In pretty much all control functions 
you're MAC'ing process variables and coefficients. In my design, I ate up 
most of an EP1C6 with multipliers. You can reduce this somewhat by creating 
long multipliers, or off-line calculation of LUT's for partial products, but 
on my next design (way bigger and multi-channel servo performance), I'm 
moving to Cyclone II just for the embedded multipliers.

Another thing that makes it somewhat harder on an FPGA than in MCU/DSP is 
implementing all the "what if" non-linear cases that are easy to code in C 
or assembler (simple example, avoid integral wind-up when some down-stream 
process saturates). Saturation versus overflow is also something that DSP's 
help you with. You will have to create saturating maths blocks.

With all the caveats, you can achieve some pretty breathtaking loop closure 
times - not that you usually need them.

G

Gary Pace wrote:
> "wicky" <wicky.zhang@gmail.com> wrote in message 
> news:1139670926.240198.163270@f14g2000cwb.googlegroups.com...
> 

> 
> I did this recently using only an FPGA, with no host CPU. As you suggest, 
> the FPGA is great for creating high performance control functions (in my 
> case the performance wasn't high - just a phase controlled SCR drive, but 
> things like feedback filtering, PLL's for synchronizing, etc etc)
> 
> Since I had no host, I also implemented a communications protocol for a 
> tuning and monitoring application hosted on a PC - I really wouldn't 
> recommend this, such things are much easier in a processor.
> 
> One piece of advice - if you can afford it, use an FPGA with embedded 
> multiplier blocks and plentiful RAM. In pretty much all control functions 
> you're MAC'ing process variables and coefficients. In my design, I ate up 
> most of an EP1C6 with multipliers. You can reduce this somewhat by creating 
> long multipliers, or off-line calculation of LUT's for partial products, but 
> on my next design (way bigger and multi-channel servo performance), I'm 
> moving to Cyclone II just for the embedded multipliers.
> 
> Another thing that makes it somewhat harder on an FPGA than in MCU/DSP is 
> implementing all the "what if" non-linear cases that are easy to code in C 
> or assembler (simple example, avoid integral wind-up when some down-stream 
> process saturates). Saturation versus overflow is also something that DSP's 
> help you with. You will have to create saturating maths blocks.
> 
> With all the caveats, you can achieve some pretty breathtaking loop closure 
> times - not that you usually need them.
> 
> G
> 
> 
> 
> 

Or you can make it pretty small using sequential multipliers (scaling 
accumulators)

Ray Andraka wrote:
> Gary Pace wrote:
> 
>> "wicky" <wicky.zhang@gmail.com> wrote in message 
>> news:1139670926.240198.163270@f14g2000cwb.googlegroups.com...
>>
> 
>>
>> I did this recently using only an FPGA, with no host CPU. As you 
>> suggest, the FPGA is great for creating high performance control 
>> functions (in my case the performance wasn't high - just a phase 
>> controlled SCR drive, but things like feedback filtering, PLL's for 
>> synchronizing, etc etc)
>>
>> Since I had no host, I also implemented a communications protocol for 
>> a tuning and monitoring application hosted on a PC - I really wouldn't 
>> recommend this, such things are much easier in a processor.
>>
>> One piece of advice - if you can afford it, use an FPGA with embedded 
>> multiplier blocks and plentiful RAM. In pretty much all control 
>> functions you're MAC'ing process variables and coefficients. In my 
>> design, I ate up most of an EP1C6 with multipliers. You can reduce 
>> this somewhat by creating long multipliers, or off-line calculation of 
>> LUT's for partial products, but on my next design (way bigger and 
>> multi-channel servo performance), I'm moving to Cyclone II just for 
>> the embedded multipliers.
>>
>> Another thing that makes it somewhat harder on an FPGA than in MCU/DSP 
>> is implementing all the "what if" non-linear cases that are easy to 
>> code in C or assembler (simple example, avoid integral wind-up when 
>> some down-stream process saturates). Saturation versus overflow is 
>> also something that DSP's help you with. You will have to create 
>> saturating maths blocks.
>>
>> With all the caveats, you can achieve some pretty breathtaking loop 
>> closure times - not that you usually need them.
>>
>> G
>>
>>
>>
>>
> 
> Or you can make it pretty small using sequential multipliers (scaling 
> accumulators)

Or you can make an ALU and use a state machine to schedule all the 
computations through it.  You'd be getting something suspiciously like a 
microprocessor, though.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

I have ordered a development board of Xilinx----ML403, based on
Virtex4-FX (with PPC405 core inside). So the resource should be enough
for my prototype test.

I am designing a daughter card with 8 channel A/D and 8 channel D/A,
the chips are:

1: 2 pieces of A/D chip---- ADS8361,   2+2 Channel, 500kSPS, serial
input 16-Bit,
                                      Simultaneous Sampling A/D
Converter

2: 2 pieces of D/A chip---- DAC8814 , Quad, 1uS settling time, Serial
Input 16-Bit
                                      Multiplying Digital-to-Analog
Converter

i will interface those 4 chips separately. IO pins of ML403 are enough.

Because i want to use system generator tools to autogenerate the HDL
code instead of writing them in hand, i have to write the custom block
of the resource on my daughter card. It seems i should use the black
box characteritics of system generator,  did anyone here have the
experience on it?

obviously, the cost of my prototype system will be expensive, but it
will only be for prototyping, in the real systems, i will chose such
low-cost FPGA such as CycloneII or SpartenIII.

Btw: can anyone give me some info of papers as reference in theory. And
I'm eager to know the current status of this research area.

Hi Wicky

Are you researching for a university or a company?

Regards

R
-- 
----------------------------------------------
Posted with NewsLeecher v3.5 Beta 3
 * Binary Usenet Leeching Made Easy
 * http://www.newsleecher.com/?usenet
----------------------------------------------

I am working for Xi'an Flying Science & Technology (www.rtdsp.com),
this project is a union of our company and one university of China.

Best regards

Wicky