[OT?] what's a FPGA?

Started by Richard Owlett March 22, 2006
OK already,it is a Field Programmable Gate Array.
I understand, but not grok, the definition.

Googling for   FPGA introduction    was not a satisfying experience.
searching Wikipedia.org was less so

If your life depended on giving a useful URL, what would it be?

Part of the inspiration for this question is recent thread discussing 
VHDL for FPGA to do FIR filter. Ain't that what DSP's are for?

Get the idea I know I'm missing something basic?

I've a "bright" idea but will not expose it to competent criticism until 
I understand just what is a FPGA and what it can/can't do and just how 
"programmable" it is.

PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/




Richard Owlett wrote:
> OK already,it is a Field Programmable Gate Array. > I understand, but not grok, the definition. > > Googling for FPGA introduction was not a satisfying experience. > searching Wikipedia.org was less so > > If your life depended on giving a useful URL, what would it be? > > Part of the inspiration for this question is recent thread discussing > VHDL for FPGA to do FIR filter. Ain't that what DSP's are for? > > Get the idea I know I'm missing something basic? > > I've a "bright" idea but will not expose it to competent criticism
until
> I understand just what is a FPGA and what it can/can't do and just how > "programmable" it is. > > PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/
G/Fr/oogle for FPGA vendors and study their data sheets. (Hint: Xilinx) Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Richard Owlett wrote:

> OK already,it is a Field Programmable Gate Array. > I understand, but not grok, the definition. > > Googling for FPGA introduction was not a satisfying experience. > searching Wikipedia.org was less so > > If your life depended on giving a useful URL, what would it be? > > Part of the inspiration for this question is recent thread discussing > VHDL for FPGA to do FIR filter. Ain't that what DSP's are for? > > Get the idea I know I'm missing something basic? > > I've a "bright" idea but will not expose it to competent criticism
until
> I understand just what is a FPGA and what it can/can't do and just how > "programmable" it is. > > PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/ > > > >
An FPGA is a collection of little configurable logic blocks, and a configurable connector matrix. Once configured, it acts like a big custom logic chip. You can use it to implement all sorts of glue logic, state machines, general-purpose processors, application-specific processors, etc. If my life depended on giving a useful URL I would make peace with my maker. I figured out how FPGA's work by studying FPGA data sheets, which you can download from FPGA vendors. Yes, DSPs are very good at implementing FIR filters. In the end, though, a DSP is limited in throughput by its memory interface and MAC architecture. Today's FPGAs include multiplier blocks, you can make any width of memory interface you desire and/or multiple memory interfaces, and you can put in any logic that you want in between. Ultimately, an FPGA will be less flexible than a DSP chip in implementing a digital signal processing application, but it will be faster (and probably consume less power). I can think of three reasons that you'd want to implement a FIR filter in an FPGA: One, you're going to dedicate the FPGA to the task, and it'll be faster than a DSP chip. Two, you're doing a bunch of other things on the FPGA, you need one stinking little FIR filter to complete the thing, and you don't want to stick a DSP on the board just for that. Three, an FPGA really isn't the right answer for you but you've either been swayed by an FPGA company's applications engineers, or you're just good at implementing stuff on FPGAs. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/
Richard Owlett wrote:
> OK already,it is a Field Programmable Gate Array. > I understand, but not grok, the definition. > > Googling for FPGA introduction was not a satisfying experience. > searching Wikipedia.org was less so > > If your life depended on giving a useful URL, what would it be? > > Part of the inspiration for this question is recent thread discussing > VHDL for FPGA to do FIR filter. Ain't that what DSP's are for? > > Get the idea I know I'm missing something basic? > > I've a "bright" idea but will not expose it to competent criticism
until
> I understand just what is a FPGA and what it can/can't do and just how > "programmable" it is. > > PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/
FPGA - Field programmable gate array Field: I've never actually programmed one in a field, unless you consider a place still a field after an office block has been built over it. (*) Programmable: The user can programme the thing. It used to be they were mostly programmed through flash or EPROM type cells within the device. These days most are programmed by loading the required configuration into RAM cells within the device. Gate: Very similar to using a 12AX7 for logic work, but smaller. Used to be cooler too, but these days silicon folk are working hard to catch up with the 12AX7. Typically FPGAs actually work in logic blocks, rather than individual gates. Hence, both the "F" and the "G" lack accuracy. Array: A collection in a flat sheet. It can be a ginormous collection these days. It could be a completely homogeneous collection. It could have areas committed to specific types of logic, which can achieve better density when those areas match your requirements reasonably well. The trick here is to work out the join the dots pattern to make the array of logic blocks do what you want. You then generate a pattern for the programming cells in the FPGA which will realise your join the dots pattern, and load it in. Typically these things can automatically boot load themselves from an external non-volatile memory, or a processor could pump the pattern in. Regards, Steve * - A RAM based FPGA would typically be programmed in a field, or anywhere else for that matter, if you switch on the appliance containing it in such a location.
in article 1223n1leklggtb8@corp.supernews.com, Richard Owlett at
rowlett@atlascomm.net wrote on 03/22/2006 18:22:

> OK already,it is a Field Programmable Gate Array. > I understand, but not grok, the definition. > > Googling for FPGA introduction was not a satisfying experience. > searching Wikipedia.org was less so
wow. usually WP is good for this sorta thing. someone (knowledgeable) needs to write/edit the articles on this.
> If your life depended on giving a useful URL, what would it be? > > Part of the inspiration for this question is recent thread discussing > VHDL for FPGA to do FIR filter. Ain't that what DSP's are for?
FPGAs are really big. you can make a state machine out of them. maybe for cheaper than putting in a real uP that can do the same thing at the same speed. it doesn't surprise me that people make little dedicated DSPs out of them (and they might have some chip area left over for other little chores).
> Get the idea I know I'm missing something basic?
FPGAs came around right when i was getting out of this hardcore hardware, so this is from one ignorant to another. i dealt with straight TTL and CMOS logic, PALs, the AMD 2900 bit-slice stuff, and wiring good old microprocessors to memory and periphs. sorta ca. 1980 sorta stuff. biggest thing i ever wired up was a simple 68000 based thingie. Richard, did you deal with PALs (sometimes called "PLA" instead)? FPGAs are sorta like really big PALs that you can program like it's a peripheral on a computer bus. VHDL is some kinda language for programming these things (at least XILINX, if some other make of FPGA uses VHDL, i'm too ignorant about it).
> I've a "bright" idea but will not expose it to competent criticism
until
> I understand just what is a FPGA and what it can/can't do and just how > "programmable" it is.
oh, take a chance! i, at least, won't pick on you.
> PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/
other than the Heathkit HW-100 when i was a teenage ham radio guy, i hadn't had much experience with tubes. diddled with them a little for guitar amp purposes and have an idea of the V-I curves and such, but building a real computer with them sounds frightful. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
On Wed, 22 Mar 2006 17:22:44 -0600, Richard Owlett
<rowlett@atlascomm.net> wrote:

>OK already,it is a Field Programmable Gate Array. >I understand, but not grok, the definition. > >Googling for FPGA introduction was not a satisfying experience. >searching Wikipedia.org was less so > >If your life depended on giving a useful URL, what would it be? > >Part of the inspiration for this question is recent thread discussing >VHDL for FPGA to do FIR filter. Ain't that what DSP's are for? > >Get the idea I know I'm missing something basic? > >I've a "bright" idea but will not expose it to competent criticism
until
>I understand just what is a FPGA and what it can/can't do and just how >"programmable" it is. > >PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/
You're probably wondering why you would use something like an FPGA when you have a DSP or general purpose microprocessor available to you. Here are some apps: - Really fast stuff. Clock rates on FPGAs are about an order of magnitude behind current hi-end microprocessors. The advantage of an FPGA is that there is the potential for massive parallelism. Your FPGA design with (hypothetically) 50 MACs running in parallel at 200MHz is way faster than any general purpose processor. It's quite possible to clock small parts of an FPGA design at up to about 1GHz, but you wouldn't want to do that for something large. - You get to design your own memory interfaces. Want two independent DDR SDRAM interfaces? Well, just code them in. - You can design all sorts of oddball peripherals, like 17 channels of 500MHz timers with capture inputs. - When you want a high level of integration that can't be achieved with an off-the-shelf part. I'm seeing a lot of boards that are basically empty except for an FPGA + some I/O buffers. When NOT to use an FPGA. - When you think of yourself as a 'programmer' or 'software person' rather than a 'hardware engineer'. - When you want really low power consumption. - When you want really low cost. - When you don't need the special features of an FPGA. If you can use a microprocessor, do so. Disclaimer: I use large FPGAs for high end stuff, and this colours my opinions somewhat. There are smaller FPGAs and CPLDs that are quite cheap (< US$10 in huge volumes), but I don't use them. Regards, Allan
Allan Herriman wrote:
> When NOT to use an FPGA. > - When you think of yourself as a 'programmer' or 'software person' > rather than a 'hardware engineer'. > > - When you want really low power consumption. > > - When you want really low cost. > > - When you don't need the special features of an FPGA. If you can use > a microprocessor, do so. > > > Disclaimer: I use large FPGAs for high end stuff, and this colours my > opinions somewhat. There are smaller FPGAs and CPLDs that are quite > cheap (< US$10 in huge volumes), but I don't use them.
I'd say you missed the biggest factor saying when not to use an FPGA. Algorithm complexity seems like the most critical factor in many designs. You can churn through a bunch of simple filter algorithms at enormous speed using an FPGA approach. Try something more complex, like a speech codec. Implement something that complex in an FPGA usually dragged you down to building a state machine. That ends up being little more than a programmble DSP you built from scratch and for which you need to develop your own assembler. An off the shelf programmable DSP usually beat an FPGA into the dust for complex algorithms. The other big factor is turnaround time. You can take a C model and recompile it for a programmable DSP. You might only need to hand optimise a few small kernels to get respectable speed. Despite all the C based hardware design tools around today, you will generally get into some serious architectural design to do anything effective with an FPGA. There are many ways a problem might map to a hardware implementation, and that is largely up to you. Look at DSPs oriented towards specific applications, like comms or video. They usually add a few hardware accelerators for things which hardware does well, and software does poorly. Those accelerators are doing the kinds of thing an FPGA excels at. Regards, Steve
"robert bristow-johnson" <rbj@audioimagination.com> wrote in message

news:C0478174.12106%rbj@audioimagination.com...
> in article 1223n1leklggtb8@corp.supernews.com, Richard Owlett at > rowlett@atlascomm.net wrote on 03/22/2006 18:22: > >> OK already,it is a Field Programmable Gate Array. >> I understand, but not grok, the definition. >> >> Googling for FPGA introduction was not a satisfying experience. >> searching Wikipedia.org was less so > > wow. usually WP is good for this sorta thing. someone (knowledgeable) > needs to write/edit the articles on this.
I briefly skimmed the WP article (http://en.wikipedia.org/wiki/FPGA) and it actually seemed quite good to me. Of course, I've programmed FPGAs, so I'm reading it from the perspective of someone who already knows what one is!
Jon Harris wrote:
> "robert bristow-johnson" <rbj@audioimagination.com> wrote in
message
> news:C0478174.12106%rbj@audioimagination.com... > >>in article 1223n1leklggtb8@corp.supernews.com, Richard Owlett at >>rowlett@atlascomm.net wrote on 03/22/2006 18:22: >> >> >>>OK already,it is a Field Programmable Gate Array. >>>I understand, but not grok, the definition. >>> >>>Googling for FPGA introduction was not a satisfying experience. >>>searching Wikipedia.org was less so >> >>wow. usually WP is good for this sorta thing. someone (knowledgeable) >>needs to write/edit the articles on this. > > > I briefly skimmed the WP article (http://en.wikipedia.org/wiki/FPGA) and it > actually seemed quite good to me. Of course, I've programmed FPGAs, so I'm > reading it from the perspective of someone who already knows what one is! > >
Well, that was the article I found ;) It was focused too much on the fine detail than on the "why use one?". What turned out to be useful to me was the broad strokes several replies used which helped define what were the questions I really wanted to ask. Now with those questions framed, the Wikipedia article is much more useful. And the hyper links address my request for "useful URL's". Thank you all. Now for a long session of reading.
Richard Owlett wrote:
> OK already,it is a Field Programmable Gate Array. > I understand, but not grok, the definition. > > Googling for FPGA introduction was not a satisfying experience. > searching Wikipedia.org was less so > > If your life depended on giving a useful URL, what would it be? > > Part of the inspiration for this question is recent thread discussing > VHDL for FPGA to do FIR filter. Ain't that what DSP's are for? > > Get the idea I know I'm missing something basic? > > I've a "bright" idea but will not expose it to competent criticism
until
> I understand just what is a FPGA and what it can/can't do and just how > "programmable" it is. > > PS in my day computers used 6J6's and/or 12AX7's and spoke to 026's ;/
The first electronic DSP was a field programmable heap of arithmetic and logic. To program the Eniac, the women spent hours/days hooking various elements together with patch cables. Then, after Von Neuman published some of the ideas of the Moore school team, processors came pre-wired, you got the functional units hooked together the way the CPU architected wanted, even if a mismatch for your algorithm. Need a 17.5-bit adder? Tough. Use the 16 or 32-bit one and live with it. FPGA's go back to letting the user hook together the elements (small lookup tables, MACs and flops) the way the user wants. "Field" is anything outside of the semi FAB line. There are limitations. From any gate, you hope to find an unused wire nearby going in the direction you want. FPGA's are incredably wasteful because over 90+% of the chip is taken up with switches to connect up a mass of mostly useless wires, only some of which are going in a direction your design needs, and with left over switches and gates you can't use. However this waste looks very attractive after you see the bill for custom tooling an ASIC in the range of a large fraction of million dollars minimum, not even including design, plus a 3 month wait to see if you got it right or have to wait another 3 months. FPGA's and DSP's are pretty much Turing complete (when hooked to a standard off-the-shelf infinite size memory chip). You can implement a DSP CPU inside an FPGA or simulate an FPGA in a DSP processor with enough memory. If your algorithm fits within the DSP functional units connected the way the chip architect put it together, then a DSP is fine. If you need one more MAC or one more bit in an adder... with some big FPGA's you can program your own 73-bit adders hooked to 47 parallel MACs for a 1-cycle FIR filter if you need. With a DSP you write a bigger program, and it goes slower... and slower... IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
"Richard Owlett" <rowlett@atlascomm.net> wrote in message 
news:123dj14mgtn4d44@corp.supernews.com...
> Jerry Avins wrote: >> rickman wrote: >> >>> BTW, I know you want to do it "your way", but sampling at 44
kHz will
>>> not give you any extra useful information that you won't get at 8 kHz. >>> The phone company is not dumb and they realized a long time ago that >>> the range of frequencies required to carry intelligible voice is less >>> than 4 kHz. The higher frequencies do not add much to the picture,
but
>>> will require a lot more power to analyze. Have you found any content >>> in the higher frequencies that others have not? >> >> >> I find that intelligibility of speech -- even screechy soprano speech -- >> is hardly impaired by my hearing loss. I can't hear the top two notes on a
>> piano. Now that's a brick-wall filter! > > I look for wider than telco land line bandwidth for 2 sets of reasons: > > A1. I've read articles saying telco speech is "intelligible" but it
is
> easier if higher frequencies available. The distinguishing features > of consonants are in the higher frequencies. *HUMANS* automatically > resolve ambiguities based on context (several layers of?).
This is easy to verify by having someone say a long set of random letters over the phone while you try to right them down. You might be surprised how poorly the accuracy is, especially in discriminating pairs such as s/f, v/z, p/t, etc.. This problem is probably also part of the reason the military uses the "alpha, bravo, charlie..." alphabet for spelling out things. So while the human brain does a very good job at understanding normal speech from context clues over a limited frequency channel, additional high frequencies make it much easier on the brain (and hence less tiring for long conversations). There is certainly a matter of diminishing returns, but in my experience, even extending from the normal phone high frequency response to 4-5 kHz makes a substantial difference.
Jerry Avins wrote:
> rickman wrote: > > ... > >> BTW, I know you want to do it "your way", but sampling at 44 kHz
will
>> not give you any extra useful information that you won't get at 8 kHz. >> The phone company is not dumb and they realized a long time ago that >> the range of frequencies required to carry intelligible voice is less >> than 4 kHz. The higher frequencies do not add much to the picture, but >> will require a lot more power to analyze. Have you found any content >> in the higher frequencies that others have not? > > > I find that intelligibility of speech -- even screechy soprano speech -- > is hardly impaired by my hearing loss. I can't hear the top two notes on > a piano. Now that's a brick-wall filter!
/ begin chuckle I'll see your "normal" hearing loss and raise you my *abnormal* loss / end chuckle I look for wider than telco land line bandwidth for 2 sets of reasons: A1. I've read articles saying telco speech is "intelligible" but it is easier if higher frequencies available. The distinguishing features of consonants are in the higher frequencies. *HUMANS* automatically resolve ambiguities based on context (several layers of?). A2. If I read correctly, speech recognition tends to use _AT MOST_ the first three formants (~150 -> ~1300 Hz) for vowels and presumably some similar range for consonants. B. I have a "good" ear and a *BAD* ear ;) "Bad ear" degraded due to scars on ear drum and nerve damage related to childhood ear infections. B1. If enough points are recorded, the response of my "bad ear" resembles a "picket fence" [Guess what a lifer seargant said when I took an *ENLISTMENT* physical with a bunch of _DRAFTEES_ during Viet Nam ;] B2.
> > Sampling at 44.1 will make recursive filters easier and transversal > filters harder. Given Richard's view that he needs linear phase, 44.1 is > asking for trouble. In his place, though I would plan to sample at > around 12 KHz or, if it's enough simpler, 22.05. You can't tell that the > high end isn't useful unless you have it. > > Jerry
rickman wrote:

   ...

> BTW, I know you want to do it "your way", but sampling at 44 kHz
will
> not give you any extra useful information that you won't get at 8 kHz. > The phone company is not dumb and they realized a long time ago that > the range of frequencies required to carry intelligible voice is less > than 4 kHz. The higher frequencies do not add much to the picture, but > will require a lot more power to analyze. Have you found any content > in the higher frequencies that others have not?
I find that intelligibility of speech -- even screechy soprano speech -- is hardly impaired by my hearing loss. I can't hear the top two notes on a piano. Now that's a brick-wall filter! Sampling at 44.1 will make recursive filters easier and transversal filters harder. Given Richard's view that he needs linear phase, 44.1 is asking for trouble. In his place, though I would plan to sample at around 12 KHz or, if it's enough simpler, 22.05. You can't tell that the high end isn't useful unless you have it. Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Richard Owlett wrote:
> I often drive experts nuts. > I ask a question they -- *THROUGH EXPERIENCE* -- 'recognize' as ill > defined. They try to *FORCE* me into asking what they consider a "well > defined" question. > > _BUT_ I *did not* want to ask their "well defined" question. > > I WANTED TO ASK *my* QUESTION ;) > In this case, due to possibility of parallelisms, FPGA's came to mind. > So my question is much more about > "How much of this would fit on what size FPGA?" > rather than > "Would a sane person use a DSP or FPGA for this application?"
Ok, I get it, you are not trying to actually solve a problem in the best manner given the available tools. You want to explore the domain of tools available for solving the problem. Then knock yourself out! It will take considerable resources to do this sort of algorithm on an FPGA if you are going to do it all in parallel. With speeds of hundreds of MHz, both DSPs and FPGAs are capable of processing audio signals by multiplexing a single processing element. But if you want to build lots of little processing units and clock them all slowly, that will work as well. It is hard to advise you to reasonable answers to your questions until you frame them in a way that can be answered. Regardless of whether I think you are using the best string for the job or not, I can't answer the question, "how long is a piece of string"... or in other words, "how large of an FPGA do I need"? You need to define the processing first. BTW, I know you want to do it "your way", but sampling at 44 kHz will not give you any extra useful information that you won't get at 8 kHz. The phone company is not dumb and they realized a long time ago that the range of frequencies required to carry intelligible voice is less than 4 kHz. The higher frequencies do not add much to the picture, but will require a lot more power to analyze. Have you found any content in the higher frequencies that others have not?
Richard Owlett wrote:
> While looking at "the problem", I started wondering if a massively > parallel solution would be worth exploring.
Please note that parallelism and FPGA implementation are two orthogonal concepts. Current large FPGA's do allow one to implemently highly parallel algorithms on certain classes of problems. But there are products other than those marketed as FPGA's which also offer various forms of parallelism (forms of VLIW, SIMD, multi-core, multi-thread, and configurable arithmetic, to name just a few). IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
rickman wrote:
> Richard Owlett wrote: > >>I have a interest in speech recognition. I haven't purchased anything >>because users *and* VARs have told be I probably wouldn't be satisfied. >>[My desires would be better met by a 'discrete speech' rather than the >>current orientation to 'continuous speech -- but that discussion goes >>far OT] >> >>That said, I read in comp.speech.users and comp.speech.research of what >>my gut says are excessively tight constraints on the acoustic >>environment [especially normal office noise and careful mike placement]. >> >>I envision an external signal conditioning module containing >>5-8 band pass linear phase with 5 < Q < 20 >>2-10 band pass linear phase with 20 < Q < 200 >> [all above outputs in time sync with a latency of < .1 second] >>{ How I combine this to get off chip is up in the air.] >> >>The above is based on some almost *TOTALLY UNTESTED* ideas of what I >>really want to accomplish. I was thinking the parallel nature of what I >>envisioned lent it to a FPGA approach. > > > Given that what you really want, but did not state, is an evrironment > for exploring your ideas, I would recommend that you focus on your > algorithms by writing software on a PC.
I'm already doing almost that. I'm using Scilab to explore various pieces of "the problem" [N.B. not "the solution" ;] While looking at "the problem", I started wondering if a massively parallel solution would be worth exploring. /start side bar I think in different paths than most modern engineers [won't say what family thinks ;] Jerry's old enough to pick up on inferences of following 1. My father a. helped build and *LEGALLY* operate a spark gap transmitter b. perused a BS(ME) as it had more EE than a BS(EE) at that time c. published article(s?) on "magnetic amplifiers" 2. I a. remember chopper stabilized op amps b. have used op amps which required >= 1 inch of 19" rack [ how many youngsters even know what a 19" rack is ] c. read of/on/about *ANALOG COMPUTERS* while still used ;) /temporary end side bar :) I suspect that the key to my thought pattern is 2.c. YEPP want 'digital' implementation of *ANALOG COMPUTER* How many analog simulation blocks can I stuff in a FPGA? Jerry, you program/use FORTH, do you get an idea of where I wish to attempt and possibly to go?
> The decision of whether to use > an FPGA or a DSP is an implementation decision. Given that your > signals are audio frequency, even lower that the full range of human > hearing most likely, I would say you can do anything you can think of > on a DSP. There are low power, fixed point devices that can process > 100's of millions instructions per second. There are larger, more > power hungry units that can process up to a billion or more useful > instructions per second. So it is unlikely that you can create an > algorithm that requires more processing than this from an 8 kHz sampled > audio stream.
Initial sampling will be at 44 kHz or greater. My "gut" says that this is part of problem with modern speech recognition systems -- they "ignore"/"throw away" *too* much data. The output of my 'black box' would be "sampled" as speech recognizer _PRESUMES_.
> > That said, there is also the development effort to consider. Typically > before you even begin working with DSPs the algorithm is fully explored > and tested on a PC in C or other environment of your choice such as > Matlab. Once you have a fully functional model, then you can be > concerned with the implementation. This goes double for FPGAs because > they are not nearly as flexible to significant archetecture changes. > Sure, you can change your code (VHDL or verilog), but typically the > code is woven tighter and changes can impact the code a lot more.
Now you come up against another aberrant aspect of how I think. I often drive experts nuts. I ask a question they -- *THROUGH EXPERIENCE* -- 'recognize' as ill defined. They try to *FORCE* me into asking what they consider a "well defined" question. _BUT_ I *did not* want to ask their "well defined" question. I WANTED TO ASK *my* QUESTION ;) In this case, due to possibility of parallelisms, FPGA's came to mind. So my question is much more about "How much of this would fit on what size FPGA?" rather than "Would a sane person use a DSP or FPGA for this application?"
> > The main difference between the two is that the DSP has just one or two > ALUs to do the MAC operation (which is the most often used function in > DSP). It runs at a high speed and, just like in a PC, it switches > between functions to do things serially, but appear to be in parallel. > The FPGA is capable of actually doing things in parallel. With very > high speed sample rates this can be important since there is not time > to switch a DSP between different tasks. But at audio rates there is > normally tons of time for the DSP to do many different processing on > the data before the next sample or batch of samples come in. > > So in summary, it would be prudent to simulate your algorithm on a PC > to get the idea fleshed out and working. Then you can decide if you > want to implement on a floating point DSP, a fixed point DSP or an > FPGA. Then you get all the fun of actually doing the real work. >
rickman wrote:
> Richard Owlett wrote: > >>I have a interest in speech recognition. I haven't purchased anything >>because users *and* VARs have told be I probably wouldn't be satisfied.
...
> Given that what you really want, but did not state, is an evrironment > for exploring your ideas, I would recommend that you focus on your > algorithms by writing software on a PC.
... That and the rest of what you wrote makes good sense. (I suppose that's why most of us work that way.) I'm glad you wrote it. I was only beginning to formulate it, and you said it better than I would have. Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Richard Owlett wrote:
> I have a interest in speech recognition. I haven't purchased anything > because users *and* VARs have told be I probably wouldn't be satisfied. > [My desires would be better met by a 'discrete speech' rather than the > current orientation to 'continuous speech -- but that discussion goes > far OT] > > That said, I read in comp.speech.users and comp.speech.research of what > my gut says are excessively tight constraints on the acoustic > environment [especially normal office noise and careful mike placement]. > > I envision an external signal conditioning module containing > 5-8 band pass linear phase with 5 < Q < 20 > 2-10 band pass linear phase with 20 < Q < 200 > [all above outputs in time sync with a latency of < .1 second] > { How I combine this to get off chip is up in the air.] > > The above is based on some almost *TOTALLY UNTESTED* ideas of what I > really want to accomplish. I was thinking the parallel nature of what I > envisioned lent it to a FPGA approach.
Given that what you really want, but did not state, is an evrironment for exploring your ideas, I would recommend that you focus on your algorithms by writing software on a PC. The decision of whether to use an FPGA or a DSP is an implementation decision. Given that your signals are audio frequency, even lower that the full range of human hearing most likely, I would say you can do anything you can think of on a DSP. There are low power, fixed point devices that can process 100's of millions instructions per second. There are larger, more power hungry units that can process up to a billion or more useful instructions per second. So it is unlikely that you can create an algorithm that requires more processing than this from an 8 kHz sampled audio stream. That said, there is also the development effort to consider. Typically before you even begin working with DSPs the algorithm is fully explored and tested on a PC in C or other environment of your choice such as Matlab. Once you have a fully functional model, then you can be concerned with the implementation. This goes double for FPGAs because they are not nearly as flexible to significant archetecture changes. Sure, you can change your code (VHDL or verilog), but typically the code is woven tighter and changes can impact the code a lot more. The main difference between the two is that the DSP has just one or two ALUs to do the MAC operation (which is the most often used function in DSP). It runs at a high speed and, just like in a PC, it switches between functions to do things serially, but appear to be in parallel. The FPGA is capable of actually doing things in parallel. With very high speed sample rates this can be important since there is not time to switch a DSP between different tasks. But at audio rates there is normally tons of time for the DSP to do many different processing on the data before the next sample or batch of samples come in. So in summary, it would be prudent to simulate your algorithm on a PC to get the idea fleshed out and working. Then you can decide if you want to implement on a floating point DSP, a fixed point DSP or an FPGA. Then you get all the fun of actually doing the real work.
Richard Owlett wrote:
> Jerry Avins wrote: > >> Richard Owlett wrote: >> >>> Andor wrote: >>> >>>> Jerry Avins wrote: >>>> >>>>> Richard Owlett wrote: >>>>> >>>>> ... >>>>> >>>>> >>>>>> I envision an external signal conditioning module
containing
>>>>>> 5-8 band pass linear phase with 5 < Q < 20 >>>>>> 2-10 band pass linear phase with 20 < Q < 200 >>>>> >>>>> >>>>> >>>>> >>>>> I'm left wondering how "Q" and "linear
phase" are implemented
>>>>> together. >>>> >>>> >>>> >>>> >>>> >>>> For FIR (and some IIR) systems, magnitude and phase response can
be
>>>> specified independently. I don't see any problems in implementing
those
>>>> specs. >>>> >>> >>> My recollection of a definition of Q was simply ratio of (center >>> frequency) to (bandwidth). I'm implicitly leaving flatness in the >>> passband loosely (if at all) constrained. >>> >>> Also I thought that FIR filters had intrinsically constant group >>> delay -- which is what's needed. Should I've not said "linear
phase",
>>> thought they were implicitly equivalent? >> >> >> >> I suspected that you meant bandwidth. Q has other implications that I >> imagine you don't mean. >> >> Jerry > > > What other implications does Q have? > Q was a natural fit as, at least for the Q < 20 an series R-L-C , would > have a magnitude response appropriate to my ideas. [Would it have > constant group delay though?]
Your RLC with a Q of 20 won't have a flat top. A good IF passband may have the same 3-dB points as as a tank with a Q of to, but it will be a lot flatter in the passband and have much better skirt selectivity. The tank will have leading phase above midband and lagging below. The IF filter will better approximate a constant group delay. Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Jerry Avins wrote:

> Richard Owlett wrote: > >> Andor wrote: >> >>> Jerry Avins wrote: >>> >>>> Richard Owlett wrote: >>>> >>>> ... >>>> >>>> >>>>> I envision an external signal conditioning module containing >>>>> 5-8 band pass linear phase with 5 < Q < 20 >>>>> 2-10 band pass linear phase with 20 < Q < 200 >>>> >>>> >>>> >>>> I'm left wondering how "Q" and "linear phase"
are implemented together.
>>> >>> >>> >>> >>> For FIR (and some IIR) systems, magnitude and phase response can be >>> specified independently. I don't see any problems in implementing
those
>>> specs. >>> >> >> My recollection of a definition of Q was simply ratio of (center >> frequency) to (bandwidth). I'm implicitly leaving flatness in the >> passband loosely (if at all) constrained. >> >> Also I thought that FIR filters had intrinsically constant group delay >> -- which is what's needed. Should I've not said "linear phase", >> thought they were implicitly equivalent? > > > I suspected that you meant bandwidth. Q has other implications that I > imagine you don't mean. > > Jerry
What other implications does Q have? Q was a natural fit as, at least for the Q < 20 an series R-L-C , would have a magnitude response appropriate to my ideas. [Would it have constant group delay though?]