AREF bypass capacitance on ATMega2560?

On 9/7/2013 11:17 AM, krw@attt.bizz wrote:
> On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com>  wrote:
>
>> On 9/6/2013 7:10 PM, Joerg wrote:
>>> That is often the problem. Sometimes a buck fifty is the pain threshold.
>>> Not in this ATMega case, the 2560 is very expensive but comes with lots
>>> of ADC and analog muxes and all that. Things that will cost extra with a
>>> FPGA solution and eat real estate.
>>>
>>>
>>>    For $3 however, you can get a
>>>> chip large enough for a CPU (with math) and room for your special logic.
>>>>
>>>
>>> For $3 I can get a big DSP.
>>
>> What "big" DSP can you get for $3?  It has been a while since I looked
>> hard at DSP chips, but I don't recall any I would call remotely "big"
>> for $3.  The TI chips that would be "big" are the TMS6xxx line which
>> start somewhere around $20 the last time I looked and that requires all
>> memory and I/O to be separate.  The smaller DSP chips that you can get
>> for the $3 range are not "big" in any sense and only a very few of them
>> include Flash memory.  So you still need another chip.
>
> We pay less than that for the largest of the ADI sigma DSPs.  I just
> received a quote for the smallest CPLD for around $.75.  I have use
> for CPLDs and FPGAs but they're simply too expensive for most of my
> applications.

It seems the prices have come down in recent years, but still, the parts 
I have seen have no Flash.  So you need to add in that cost.  But the 
Sigma parts aren't really general purpose.  They are good if you can 
make you app fit the DSP design, otherwise they aren't much use.  I 
pursued them hard a few years ago until an FAE just threw in the towel 
and said I couldn't do my app on their part.


>> Even a "small" FPGA can run rings around a DSP when it comes to
>> performance.  Usually "big" in DSPs means fast and when you want really
>> fast DSP you use an FPGA with all the parallelism you can handle.  DSPs
>> can't touch FPGAs for speed, even with low power.
>
> Comparing the two is silly.  Each has its place.

That makes no sense.  There will always be some designs that a given 
part is a perfect fit for, but that doesn't mean different devices can't 
be compared.  The question is what is the best fit for a given job.  I 
am hearing some say that FPGAs aren't the best fit and I find they often 
are a better fit than an MCU.  Much of it has to do with mis-information 
about what FPGAs can and can't do and what is required to make them run. 
  Just read Joerge's post.  Much of the stuff he objects to is specific 
to the individual devices he has worked with.


>>> What I often find is people only doing Altera or only Xilinx. With uC
>>> it's a bit easier, a PIC guy can be cajoled into programming an AVR,
>>> usually.
>>
>> I'm totally device agnostic.  I have worked with all brands other than
>> MicroSemi (formerly Actel).  I even worked with Lucent which was bought
>> by Lattice and I believe is still sold and supported (but not the GD XP
>> line which I had designed into a cash cow product and will have to
>> redesign now).  Ever hear of Concurrent?  They were bought by Atmel.
>> Their devices were followed by the AT40K.  I worked with the Concurrent
>> devices. lol  So you can see I go way back.
>
> The difference anymore is very small.  The only reason I prefer one
> over the other is software and that takes a back seat to most other
> variables (in rough order of importance, 1. cost, 2. cost, 3. cost).

I have not found a big difference in software.  The software is 
different, but those differences are not important.  It all compiles my 
HDL fine (mostly because they often use the same third party tool 
vendors) and simulation just works anymore.


> The one feature that isn't universal is programming modes.  This can
> make a big difference in indirect costs (field upgrade, SKU
> personalization, etc.) that may not show up directly on the raw BOM.

I don't know what devices you work with, but the ones I use are easy to 
program.


>> I've used schematic based tools and both VHDL and Verilog.  I've worked
>> with the vendor's tools and third party tools including the NeoCAD tools
>> which became Xilinx tools when Xilinx bought them.
>>
>> If anyone tells you they only know one brand of FPGA you are talking to
>> an FPGA weenie.  I find MCUs to vary a *great* deal more than FPGAs in
>> terms of usage.  MCUs need all sorts of start up code and peripheral
>> drivers, clock control, etc, etc, etc.  FPGAs not so much.  They mostly
>> have the same features and most of that can be inferred from the HDL so
>> you never need to look too hard under the hood.
>
> Sure, the feature set and peripherals of micros varies widely.  We use
> a variety of SoCs from just about everyone.  Since most are settling
> on ARM, switching from one to the other is pretty simple.  Our last
> port from one manufacturer to the other took a couple of weeks.

The CPU is the easy part to port, the compiler handles that for you.  It 
is the drivers for the I/O that is harder.  Their libraries have to have 
compatible interfaces and every port is a port.  With FPGAs, all you 
need to do to switch between brands is normally a new pin list and 
timing constraints.  The HDL just compiles to suit the new device.  It 
has been a while since I ported between brands but it would make sense 
if they provide tools to port the timing constraints.  That is the only 
part that might be any work at all.


>> In short, there is a lot of FUD about FPGAs.  Talk to someone who
>> doesn't buy into the FUD.
>
> The FUD is on both sides.  The support costs aren't as low as you
> pretend.

Care to elaborate?


>>> Things quickly unravel when you start relying on real hardware that is
>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.
>>
>> If you really need it all on a single chip, then yes, you won't find
>> that on so many FPGAs although Microsemi has their Fusion line with
>> analog.  My cash cow uses a single FPGA and a stereo CODEC.  That was
>> smaller than any MCU design because the MCU would still require the
>> CODEC (CD quality) and some of the control logic and interface could not
>> be done with any conventional MCU.  I had to vary the speed of the CODEC
>> clock via an ADPLL to synchronize it with an incoming data stream.  I
>> don't know how to do that with an MCU and no logic.  But I can do it all
>> with FPGA logic and no MCU.
>
> Nonsense.  DSPs are also available with CODECs, as are UCs.

You can find a small number of DSPs with CD qualitity CODECs and the 
same for MCUs.  I know, I did this search recently.  I didn't find much 
and none that suited my other critera.  So the redo of my board will 
likely have another FPGA on it.

I would appreciate a list of the MCUs/DSPs which have stereo CD quality 
CODECs on chip.  The Sigma parts from ADI don't count because their DSPs 
can *only* be used for certain coding like filters, not general purpose 
use.


>>> Last week I reviewed a design with some larger FPGA on there. What I
>>> found fairly disgusting was how much they had to be babied with the
>>> power sequencing. uCs don't have that problem.
>>
>> If you want to work with the wrong device, then you will find it hard to
>> work with.  There are still single voltage devices on the market.  If
>> this was an old design, most likely it was a Spartan 3 or similar era
>> device when they (for still unknown reasons) used three, yes, count
>> them, *three* voltages on the FPGA.  The 2.5 volt aux supply was there
>> solely for the configuration interface which was normally to a 3.3 volt
>> device!  Only from Xilinx...
>>
>> If this was a new device, then I guess they picked one based on
>> something other than ease of use, eh?  Don't assume all FPGAs are the same.
>
> I thought you just said that there weren't many differences between
> FPGA manufacturers?

You are mixing apples and oranges.  One manufacturer has many different 
families of FPGAs, no?  Some are huge power hungry devices that burn a 
hole in your board.  Others are much lower power and don't burn a hole 
in your pocketbook either.

-- 

Rick

On 9/7/2013 11:32 AM, krw@attt.bizz wrote:
> On Sat, 07 Sep 2013 10:00:51 -0400, rickman<gnuarm@gmail.com>  wrote:
>
>> On 9/7/2013 4:24 AM, John Devereux wrote:
>>> rickman<gnuarm@gmail.com>   writes:
>>>
>>>> If your FPGA designs are expensive or power hungry, then you are doing
>>>> things you can't do in an MCU or you are not using FPGAs properly.
>>>> They don't need to use any more power than an MCU and in many cases
>>>> less. They certainly don't need to be significantly more expensive
>>>> unless you consider every dollar in your designs.  At the very low end
>>>> MCUs can be under $1 and still have reasonable performance.  For $1
>>>> you can't get much in the way of programmable logic.  For $3 however,
>>>> you can get a chip large enough for a CPU (with math) and room for
>>>> your special logic.
>>>
>>> I've never used an FPGA, microcontrollers have increased in speed faster
>>> than my needs so far. So I can usually bitbang everything or use a
>>> peripheral. I used PLDs for glue logic back in the day but that's it. Oh
>>> and I bought a small xilinx dev kit which I got to make a led flash then
>>> put in a drawer for 15 years.
>>
>> So your use of MCUs is based on inertia?
>
> It seems that the "when all you have is a nail..." argument is
> prevalent on both sides of this discussion.

Nonesense.  I constantly look for MCU solutions for my designs.


>>> But could you give an example of your $3 one? Or a favorite?
>>
>> A startup company called Silicon Blue came out with a line of FPGAs
>> targeted to the high volume, low power market that exists for portable
>> devices.  They were preparing their second device family and were bought
>> by Lattice Semi.  The first family was dropped and the second family is
>> the iCE40 (for 40 nm).  They are very low power although smallish.  The
>> largest one has 8 kLUTs, the smallest 384 LUTs.
>
> Everyone has $3 parts, now.  It's a matter of finding the FPGA that
> fits the application.  The line between CPLDs and FPGAs isn't very
> sharp anymore and is mostly marketing.  CPLDs go well under a buck.

I won't argue that.  But I don't consider CPLDs in the same vein as 
FPGAs, but you are right, the distinction is blurring.


>> Last winter I was looking at designing a very low power radio controlled
>> clock to run in one of these.  They were still playing a shell game with
>> the devices in the lineup and the 640 LUT part I wanted to use was
>> dropped... :(  The only real problem I have with these devices is the
>> packaging.  Because of the target market the packages are mostly fine
>> pitch BGAs.  Great if you are making a cell phone, not so great if you
>> are designing other equipment.
>
> A very good point.  I've beat up all of the FPGA supplier on exactly
> this point.  I can't use fine-pitch BGAs.  Less than .8mm pitch is a
> real problem, though with some arm twisting we can go to .5mm.  The
> business case for an FPGA hasn't materialized (it affects the entire
> board design), though.  There is always another solution.
>
>> You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
>>   It has been a while since I got a quote.  The 1 kLUT part is big
>> enough for a soft core MCU plus some custom logic.
>
> IMO, a soft core MCU negates the whole reason for an FPGA.  You're
> using *expensive* realestate to do what a cheap piece of silicon can
> easily do.  There is probably an application somewhere that makes
> sense but I've always found a better/cheaper solution.

That is the sort of thinking that is just a pair of blinders.  I don't 
care if the real estate is "expensive".  I care about my system cost. 
Gates in an FPGA are very *inexpensive*.  If I want to use them for a 
soft core CPU that is just as good a use as a USB or SPI interface.


>> BTW, with MCUs Digikey will give you a realistic price quote.  In the
>> FPGA world the distis never give you a good price unless you ask for a
>> quantity quote.  I have gotten prices quoted to me that were half the
>> list price.  FPGA companies play a different marketing game and have a
>> lot of room to negotiate in order to buy a socket.
>
> "DigiKey" and "realistic quote" don't belong in the same sentence. For
> any quantity catalogs just don't cut it.

Your opinion.  I don't sell 100,000 quantities, so the prices I get at 
Digikey are often competitive with the other distis.  Certainly they 
give you a ball park number for comparison purposes.  The point is that 
with FPGAs, *no one* gives you a good price unless you get the 
manufacturer involved.  That is one down side to FPGAs.

-- 

Rick

On 9/7/2013 12:32 PM, Joerg wrote:
> rickman wrote:
>>
>> You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
>>   It has been a while since I got a quote.  The 1 kLUT part is big enough
>> for a soft core MCU plus some custom logic.
>>
>
>
> Got a mfg and part number? Or a Digikey link?

At Digikey search on iCE40.  That will give you a listing of all the 
parts.  Looks like Digikey's prices are a little high, not just because 
they are Digikey.  The $3 figure I gave is from quotes I got from 
Silicon Blue before they were traded through Digikey.  Like I said, you 
need to get a quote on any FPGA to find the "real" price.


>> BTW, with MCUs Digikey will give you a realistic price quote.  In the
>> FPGA world the distis never give you a good price unless you ask for a
>> quantity quote.  I have gotten prices quoted to me that were half the
>> list price.  FPGA companies play a different marketing game and have a
>> lot of room to negotiate in order to buy a socket.
>>
>
> Yeah, the old haggle game. Beats my why they still cling to such
> medieval sales tactics. The only other market where that is customary is
> with used car salesmen.
>
> They don't even know how much in business opportunity they are missing
> because of this. Guys like me need pricing info here, this minute, right
> now. If there is even as much as a label "Call" I usually move on.

I don't think it is all about the "haggle".  I think no small part is 
about doing what it takes to get the design in and deny the competition. 
  When you get quotes from Digikey web site they never even know you are 
looking at their parts.  Think of it as a live auction vs. sealed bids. 
  They prefer to be in the live auction.

-- 

Rick

rickman wrote:
> On 9/7/2013 11:10 AM, Joerg wrote:
>> rickman wrote:
>>> On 9/6/2013 7:10 PM, Joerg wrote:
>>>>
>>>> That is often the problem. Sometimes a buck fifty is the pain
>>>> threshold.
>>>> Not in this ATMega case, the 2560 is very expensive but comes with lots
>>>> of ADC and analog muxes and all that. Things that will cost extra
>>>> with a
>>>> FPGA solution and eat real estate.
>>>>
>>>>
>>>>    For $3 however, you can get a
>>>>> chip large enough for a CPU (with math) and room for your special
>>>>> logic.
>>>>>
>>>>
>>>> For $3 I can get a big DSP.
>>>
>>> What "big" DSP can you get for $3? ...
>>
>>
>> For example, this:
>>
>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf
> 
> I don't see it for $3.  Did you get a quote for your project?  TI says
> it is $5 to $8 at qty 1k depending on the flavor.  You still need to add
> Flash.
> 

1k qty is $3.67 at Digikey:

http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713

$3.02 with 12wks leadtime at Arrow:

http://components.arrow.com/part/detail/51425505S8988412N7713?region=na

ROM is included.


> 
>>>                           ... It has been a while since I looked
>>> hard at DSP chips, but I don't recall any I would call remotely "big"
>>> for $3.  The TI chips that would be "big" are the TMS6xxx line which
>>> start somewhere around $20 the last time I looked and that requires all
>>> memory and I/O to be separate.  The smaller DSP chips that you can get
>>> for the $3 range are not "big" in any sense and only a very few of them
>>> include Flash memory.  So you still need another chip.
>>>
>>
>> It has tons of memory on board.
> 
> Yes, and many FPGAs have "tons" of memory on board although not for
> $3... but then this isn't a $3 part either...
> 

It is a $3 part. See above.

> 
>>> Even a "small" FPGA can run rings around a DSP when it comes to
>>> performance.  Usually "big" in DSPs means fast and when you want really
>>> fast DSP you use an FPGA with all the parallelism you can handle.  DSPs
>>> can't touch FPGAs for speed, even with low power.
>>>
>>
>> Most of the really powerful FPGA that I connected to or had to review
>> designs with them in there were painfully expensive.
> 
> Because you were looking at FPGAs that were "painfully" large I'm sure.
>  How many pins, 256, 400+...?  20,000 LUTs, 40,000 LUTs?
> 

Sure, that's why I wrote "powerful". The less powerful ones have never
impressed me much but I have to admit that I haven't looked the last
five years. So, tell us, which FPGA can fully replace the above DSP for
three bucks and where could one buy it off the shelf?


> 
>>>> It's the same with myself. For many assigments I could as well live on
>>>> East Rarotonga. But not for EMC or noise fixing jobs with larger
>>>> installations.
>>>
>>> I'm confused.  Are you saying that on most jobs you don't care where the
>>> programmer lives and works? ...
>>
>>
>> Yes, on most but _not_ all. That's key.
> 
> So you could use FPGA instead of an MCU on most of your designs?  I'm
> still confused.  Are you saying if you can't use a part on all of your
> designs you don't want to use it on any?
> 

No, what I am saying is the it doesn't matter much which parts I use (my
clients decide that anyhow) but that finding a programmer locally can be
important. Some projects will not really come off the ground if the
programmer isn't local. Or it can take forever.

> 
>>>                        ...  I think that is what you said, but it
>>> sounds like you are trying to disagree with me.
>>>
>>
>> I disagree with the statement "it doesn't matter where the worker is".
>> Because sometimes (not always) it does matter. And when it does, close
>> proximity is very important. Then you need to literally work
>> side-by-side. Done it many times.
>>
>> Our local SW guy sold his horse ranch and moved out of California. Only
>> to Reno which is under 2h drive but that's already a bit far. And in
>> winter you might not get through the pass or can't get back home.
> 
> I have done many jobs remotely and it has *never* been a problem.  If
> debugging is needed in the field, that is not the same thing as saying
> the developer has to be in the field.  You are welcome to disagree on this.
> 

I do disagree.


> I can only remember one time where I iterated through design changes in
> the field and that was actually a case where I could have done it all
> remotely, but I was pleasing the customer to be there.  Turns out he
> wasn't initializing the design right and it was hard to detect.
> 

Well, if you are standing next to a huge roaring engine and this, that
and the other subtle disturbance has to be ironed out it would be a
major problem if the programmer is three time zones away. You don't have
to believe me but that's how it is with some of my assignments.

Just like EMC jobs on large gear can simply not be done remotely. Which
is why I bought the Signalhound analyzer (fits into carry-on).


> One big advantage to FPGAs is the ability to simulate at a low level. it
> is very easy to emulate the I/O in an HDL simulation.  I don't know how
> they do that with MCUs, but in the FPGA world I've never had a problem.
> 

That is undoubtedly true. Plus probably less in errata headaches.

[...]


>>> I've used schematic based tools and both VHDL and Verilog.  I've worked
>>> with the vendor's tools and third party tools including the NeoCAD tools
>>> which became Xilinx tools when Xilinx bought them.
>>>
>>> If anyone tells you they only know one brand of FPGA you are talking to
>>> an FPGA weenie.  I find MCUs to vary a *great* deal more than FPGAs in
>>> terms of usage.  MCUs need all sorts of start up code and peripheral
>>> drivers, clock control, etc, etc, etc.  FPGAs not so much.  They mostly
>>> have the same features and most of that can be inferred from the HDL so
>>> you never need to look too hard under the hood.
>>>
>>> In short, there is a lot of FUD about FPGAs.  Talk to someone who
>>> doesn't buy into the FUD.
>>>
>>
>> Yeah, maybe next time I need major logic we should talk. But better not
>> about politics :-)
> 
> Yeah...  Even if you need minor logic let's talk.  I find the real
> advantage to FPGAs is in the fact that I can do almost *anything* in
> one.  I don't need to add stuff unless it is very application specific
> like the CD quality CODEC on my current production board.  I could get
> CD quality from an FPGA design, but it wouldn't be worth the work to
> save a $3 part.
> 

So far the next project on the books that will contain logic is 2nd half
of next year. It will need a 16-bit audio codec as well but we can use
an external chip for that, PCM29xx series et cetera. Would (probably)
even keep it external with a uC because the 16-bit ADCs on those aren't
very quiet.

> 
>>>> Things quickly unravel when you start relying on real hardware that is
>>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.
>>>
>>> If you really need it all on a single chip, then yes, you won't find
>>> that on so many FPGAs although Microsemi has their Fusion line with
>>> analog.  My cash cow uses a single FPGA and a stereo CODEC.  That was
>>> smaller than any MCU design because the MCU would still require the
>>> CODEC (CD quality) and some of the control logic and interface could not
>>> be done with any conventional MCU.  I had to vary the speed of the CODEC
>>> clock via an ADPLL to synchronize it with an incoming data stream.  I
>>> don't know how to do that with an MCU and no logic.  But I can do it all
>>> with FPGA logic and no MCU.
>>>
>>
>> Hmm, I was looking at audio interfacing just yesterday because I am
>> going to need that on one new project. There's plenty out there that
>> should be directly adressable via MCU. For me it's probably going to be
>> something from the PCM290x series but there's also SPI variants and so
>> on.
>>
>> Anyhow, I am also going to need ADC and comparator, including muxes for
>> them, so this one will likely be a uC case again because otherwise all
>> this has to be added externally.
> 
> You do know that it is not hard to add an ADC to an FPGA?  No need for a
> mux if all the inputs can be connected to separate pins.  It all depends
> on the resolution you need.  8 bits is easy, 16 bits - not so easy.
> 

Mine are never less than 12-bit, often 16-bit.

> 
>>>> Last week I reviewed a design with some larger FPGA on there. What I
>>>> found fairly disgusting was how much they had to be babied with the
>>>> power sequencing. uCs don't have that problem.
>>>
>>> If you want to work with the wrong device, then you will find it hard to
>>> work with.  There are still single voltage devices on the market.  If
>>> this was an old design, most likely it was a Spartan 3 or similar era
>>> device when they (for still unknown reasons) used three, yes, count
>>> them, *three* voltages on the FPGA.  The 2.5 volt aux supply was there
>>> solely for the configuration interface which was normally to a 3.3 volt
>>> device!  Only from Xilinx...
>>>
>>> If this was a new device, then I guess they picked one based on
>>> something other than ease of use, eh?  Don't assume all FPGAs are the
>>> same.
>>>
>>
>> Well, this guy is a real expert on high-end FPGA and the project
>> requires stuff with tons of horsepower.
> 
> That's fine, just don't judge all FPGAs by the ones you have seen.  If
> the only MCU you had worked with were ARM 11s using 3 Watts and running
> a cell phone down in 8 hours, would you think the PIC MCUs were the same?
> 

Well, give us all here an example of a FPGA that can fully emulate a
TSM320 and costs $3 :-)

> 
>>> You are aware that there are Flash based FPGAs that don't require the
>>> external Flash chip, right?
>>>
>>
>> Same with uCs, since a very long time :-)
> 
> You are missing my point.
> 

I guess then I don't see your point. Flash is available on almost
everything nowadays.

-- 
Regards, Joerg

http://www.analogconsultants.com/

rickman skrev 2013-09-06 23:12:
> On 9/6/2013 4:33 PM, Joerg wrote:
>> rickman wrote:
>>> On 8/22/2013 1:51 PM, Joerg wrote:
>>>> Tim Williams wrote:
>>>>> "Joerg"<invalid@invalid.invalid>   wrote in message
>>>>> news:b7l1blFlu93U2@mid.individual.net...
>>>>>>>> I saw people
>>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like
>>>>>>>> that,
>>>>>>>> as usual.
>>>>>>> It doesn't really matter.
>>>>>>>
>>>>>> However, not everyone knows that because they don't say much about
>>>>>> the
>>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd.
>>>>>
>>>>> Finally gave up and bit the uC bullet?  ;-)
>>>>>
>>>>
>>>> Sometimes you need it. A while ago I even had a switcher design that
>>>> would have been totally impossible to do without a uC. But it does
>>>> raise
>>>> eyebrows if I request timers and port pins and MIPS, probably
>>>> because of
>>>> my analog background. "YOU want some of the uC resources? What for?"
>>>
>>> Sounds to me like you need FPGA resources moreso than an MCU.  Are you
>>> using the ADC or DAC, guess so or are you using the reference for the
>>> brownout or something else?  DACs are easy in FPGAs, ADCs not as easy.
>>> Otherwise FPGAs do everything an MCU does plus...
>>>
>>
>> I nearly always need ADC capability. Not for the brownout, I never trust
>> anything on those chips for that, the POR/BOR/WDT goes external. FPGA
>> have some downsides, they tend to become large, expensive and sometimes
>> power-hungry when you need math capability or an MCU core.
>
> If your FPGA designs are expensive or power hungry, then you are doing
> things you can't do in an MCU or you are not using FPGAs properly.  They
> don't need to use any more power than an MCU and in many cases less.
> They certainly don't need to be significantly more expensive unless you
> consider every dollar in your designs.  At the very low end MCUs can be
> under $1 and still have reasonable performance.  For $1 you can't get
> much in the way of programmable logic.  For $3 however, you can get a
> chip large enough for a CPU (with math) and room for your special logic.
>
>
>> But the main
>> issue for many projects is people. If the client has the experts in
>> house like in this case, fine. But if not then one is better off using a
>> uC where one can find a programmer in nearly every town. This is one
>> reason I am often partial to the 8051.
>
> Do you work in *every* town?  I find if I need a skill, it doesn't
> matter where the worker is.  I also find FPGA design is pretty common
> these days.  If you are ever short on FPGA design skills, give me a shout.
>
>
>> Of course the beauty of FPGA is that the availability of very fast glue
>> logic. Most uC are sorely lacking in that domain.
>
> Yes, the ideal chip would add a section of FPGA fabric to a conventional
> MCU and vary the size just as they do the RAM and Flash.  I think at
> this point the problem is cultural.  Most FPGA companies are all about
> the big iron selling for $100 a chip min and the MCU makers don't
> understand programmable logic.  Xilinx and Cypress is good examples.
> Zync is a very high end solution, great if it matches your problem. PSOC
> is not a bad idea, but their idea of programmable logic isn't worth much.
>
> Give me a good $10 MCU/FPGA combo and I'll design the world!  In the
> meantime I'll be using soft cores.  They are a lot easier to program
> than an MCU anyway.
>

That was available with the FPSLIC. AVR core with 5/10/40k gates.
Unfortunately the combination of features didn't make sense.

40 MHz AVR with only 36 kB SRAM.

It would have been much better with an ARM7 core
with an external memory bus.

Since it was implemented in a technology, and not shrinked,
it eventually become cheaper to use a softcore with
a standard FPGA in a fine geometry technology.

I came to the conclusion that an MCU company cannot compete with an FPGA 
company unless the programmable logic part is only a small percentage of 
the die.

It would make sense to have a 5 kgate FPGAs in a modern micro.

The Xilinx Zync and Altera SoC are nice tries, except that most
of the standard peripherals suck and it is still beyond the price
most customers I've seen are prepared to pay.


BR
Ulf Samuelsson

On 9/7/2013 1:59 PM, Joerg wrote:
> rickman wrote:
>> On 9/7/2013 11:10 AM, Joerg wrote:
>>> rickman wrote:
>>>> On 9/6/2013 7:10 PM, Joerg wrote:
>>>>>
>>>>> That is often the problem. Sometimes a buck fifty is the pain
>>>>> threshold.
>>>>> Not in this ATMega case, the 2560 is very expensive but comes with lots
>>>>> of ADC and analog muxes and all that. Things that will cost extra
>>>>> with a
>>>>> FPGA solution and eat real estate.
>>>>>
>>>>>
>>>>>     For $3 however, you can get a
>>>>>> chip large enough for a CPU (with math) and room for your special
>>>>>> logic.
>>>>>>
>>>>>
>>>>> For $3 I can get a big DSP.
>>>>
>>>> What "big" DSP can you get for $3? ...
>>>
>>>
>>> For example, this:
>>>
>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf
>>
>> I don't see it for $3.  Did you get a quote for your project?  TI says
>> it is $5 to $8 at qty 1k depending on the flavor.  You still need to add
>> Flash.
>>
>
> 1k qty is $3.67 at Digikey:
>
> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713

Not the same part pal.  You're trying to pull a fast one on me?  Are we 
talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 
with *much* less memory?


> $3.02 with 12wks leadtime at Arrow:
>
> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na
>
> ROM is included.

ROM is not Flash.. is it?  Are you thinking in terms of a mask ROM?


>>>>                            ... It has been a while since I looked
>>>> hard at DSP chips, but I don't recall any I would call remotely "big"
>>>> for $3.  The TI chips that would be "big" are the TMS6xxx line which
>>>> start somewhere around $20 the last time I looked and that requires all
>>>> memory and I/O to be separate.  The smaller DSP chips that you can get
>>>> for the $3 range are not "big" in any sense and only a very few of them
>>>> include Flash memory.  So you still need another chip.
>>>>
>>>
>>> It has tons of memory on board.
>>
>> Yes, and many FPGAs have "tons" of memory on board although not for
>> $3... but then this isn't a $3 part either...
>>
>
> It is a $3 part. See above.

No, you need to pick a part number and stick with it.


>>>> Even a "small" FPGA can run rings around a DSP when it comes to
>>>> performance.  Usually "big" in DSPs means fast and when you want really
>>>> fast DSP you use an FPGA with all the parallelism you can handle.  DSPs
>>>> can't touch FPGAs for speed, even with low power.
>>>>
>>>
>>> Most of the really powerful FPGA that I connected to or had to review
>>> designs with them in there were painfully expensive.
>>
>> Because you were looking at FPGAs that were "painfully" large I'm sure.
>>   How many pins, 256, 400+...?  20,000 LUTs, 40,000 LUTs?
>>
>
> Sure, that's why I wrote "powerful". The less powerful ones have never
> impressed me much but I have to admit that I haven't looked the last
> five years. So, tell us, which FPGA can fully replace the above DSP for
> three bucks and where could one buy it off the shelf?

Lol, I don't know where you are coming from now.  You don't like the 
large FPGAs because they use power like they are... well, large.  You 
don't like the small FPGAs because they are, well... small.

When you stop using terms like "powerful" and want to actually consider 
an FPGA for a design I can help you.  Gut feel is nice as long as it is 
based in fact.


>>>>> It's the same with myself. For many assigments I could as well live on
>>>>> East Rarotonga. But not for EMC or noise fixing jobs with larger
>>>>> installations.
>>>>
>>>> I'm confused.  Are you saying that on most jobs you don't care where the
>>>> programmer lives and works? ...
>>>
>>>
>>> Yes, on most but _not_ all. That's key.
>>
>> So you could use FPGA instead of an MCU on most of your designs?  I'm
>> still confused.  Are you saying if you can't use a part on all of your
>> designs you don't want to use it on any?
>>
>
> No, what I am saying is the it doesn't matter much which parts I use (my
> clients decide that anyhow) but that finding a programmer locally can be
> important. Some projects will not really come off the ground if the
> programmer isn't local. Or it can take forever.

That is the point I am trying to dispute.  My experience has been that a 
remote team is a very capable team and can do pretty much any job. 
Colocation is seldom an important issue.  So far your statements have 
all supported that with a few exceptions.  At least that is how I have 
read the words.  "Some projects", "For most work it doesn't
matter where the worker is", etc...  YMMV


>>>>                         ...  I think that is what you said, but it
>>>> sounds like you are trying to disagree with me.
>>>>
>>>
>>> I disagree with the statement "it doesn't matter where the worker is".
>>> Because sometimes (not always) it does matter. And when it does, close
>>> proximity is very important. Then you need to literally work
>>> side-by-side. Done it many times.
>>>
>>> Our local SW guy sold his horse ranch and moved out of California. Only
>>> to Reno which is under 2h drive but that's already a bit far. And in
>>> winter you might not get through the pass or can't get back home.
>>
>> I have done many jobs remotely and it has *never* been a problem.  If
>> debugging is needed in the field, that is not the same thing as saying
>> the developer has to be in the field.  You are welcome to disagree on this.
>>
>
> I do disagree.

Ok, but the examples you give tend to support remote work except in a 
few cases.  I'm just reading the words you wrote, I'm not putting them 
in your mouth.


>> I can only remember one time where I iterated through design changes in
>> the field and that was actually a case where I could have done it all
>> remotely, but I was pleasing the customer to be there.  Turns out he
>> wasn't initializing the design right and it was hard to detect.
>>
>
> Well, if you are standing next to a huge roaring engine and this, that
> and the other subtle disturbance has to be ironed out it would be a
> major problem if the programmer is three time zones away. You don't have
> to believe me but that's how it is with some of my assignments.
>
> Just like EMC jobs on large gear can simply not be done remotely. Which
> is why I bought the Signalhound analyzer (fits into carry-on).

I don't argue your needs.  You keep saying these special jobs are a 
small percentage of your work.  So most assignments will work just fine 
with remote support, no?


>> One big advantage to FPGAs is the ability to simulate at a low level. it
>> is very easy to emulate the I/O in an HDL simulation.  I don't know how
>> they do that with MCUs, but in the FPGA world I've never had a problem.
>>
>
> That is undoubtedly true. Plus probably less in errata headaches.
>
> [...]
>
>
>>>> I've used schematic based tools and both VHDL and Verilog.  I've worked
>>>> with the vendor's tools and third party tools including the NeoCAD tools
>>>> which became Xilinx tools when Xilinx bought them.
>>>>
>>>> If anyone tells you they only know one brand of FPGA you are talking to
>>>> an FPGA weenie.  I find MCUs to vary a *great* deal more than FPGAs in
>>>> terms of usage.  MCUs need all sorts of start up code and peripheral
>>>> drivers, clock control, etc, etc, etc.  FPGAs not so much.  They mostly
>>>> have the same features and most of that can be inferred from the HDL so
>>>> you never need to look too hard under the hood.
>>>>
>>>> In short, there is a lot of FUD about FPGAs.  Talk to someone who
>>>> doesn't buy into the FUD.
>>>>
>>>
>>> Yeah, maybe next time I need major logic we should talk. But better not
>>> about politics :-)
>>
>> Yeah...  Even if you need minor logic let's talk.  I find the real
>> advantage to FPGAs is in the fact that I can do almost *anything* in
>> one.  I don't need to add stuff unless it is very application specific
>> like the CD quality CODEC on my current production board.  I could get
>> CD quality from an FPGA design, but it wouldn't be worth the work to
>> save a $3 part.
>>
>
> So far the next project on the books that will contain logic is 2nd half
> of next year. It will need a 16-bit audio codec as well but we can use
> an external chip for that, PCM29xx series et cetera. Would (probably)
> even keep it external with a uC because the 16-bit ADCs on those aren't
> very quiet.

Not sure what the requirements are for your CODEC, but I have been using 
the AKM parts with good results.  Minimal or *no* programming, 
configuration is done by a small number of select pins, very simple.  I 
have yet to find another one as small, AK4552, AK4556.


>>>>> Things quickly unravel when you start relying on real hardware that is
>>>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.
>>>>
>>>> If you really need it all on a single chip, then yes, you won't find
>>>> that on so many FPGAs although Microsemi has their Fusion line with
>>>> analog.  My cash cow uses a single FPGA and a stereo CODEC.  That was
>>>> smaller than any MCU design because the MCU would still require the
>>>> CODEC (CD quality) and some of the control logic and interface could not
>>>> be done with any conventional MCU.  I had to vary the speed of the CODEC
>>>> clock via an ADPLL to synchronize it with an incoming data stream.  I
>>>> don't know how to do that with an MCU and no logic.  But I can do it all
>>>> with FPGA logic and no MCU.
>>>>
>>>
>>> Hmm, I was looking at audio interfacing just yesterday because I am
>>> going to need that on one new project. There's plenty out there that
>>> should be directly adressable via MCU. For me it's probably going to be
>>> something from the PCM290x series but there's also SPI variants and so
>>> on.
>>>
>>> Anyhow, I am also going to need ADC and comparator, including muxes for
>>> them, so this one will likely be a uC case again because otherwise all
>>> this has to be added externally.
>>
>> You do know that it is not hard to add an ADC to an FPGA?  No need for a
>> mux if all the inputs can be connected to separate pins.  It all depends
>> on the resolution you need.  8 bits is easy, 16 bits - not so easy.
>>
>
> Mine are never less than 12-bit, often 16-bit.

What about delay time?  Is sigma-delta ok?


>>>>> Last week I reviewed a design with some larger FPGA on there. What I
>>>>> found fairly disgusting was how much they had to be babied with the
>>>>> power sequencing. uCs don't have that problem.
>>>>
>>>> If you want to work with the wrong device, then you will find it hard to
>>>> work with.  There are still single voltage devices on the market.  If
>>>> this was an old design, most likely it was a Spartan 3 or similar era
>>>> device when they (for still unknown reasons) used three, yes, count
>>>> them, *three* voltages on the FPGA.  The 2.5 volt aux supply was there
>>>> solely for the configuration interface which was normally to a 3.3 volt
>>>> device!  Only from Xilinx...
>>>>
>>>> If this was a new device, then I guess they picked one based on
>>>> something other than ease of use, eh?  Don't assume all FPGAs are the
>>>> same.
>>>>
>>>
>>> Well, this guy is a real expert on high-end FPGA and the project
>>> requires stuff with tons of horsepower.
>>
>> That's fine, just don't judge all FPGAs by the ones you have seen.  If
>> the only MCU you had worked with were ARM 11s using 3 Watts and running
>> a cell phone down in 8 hours, would you think the PIC MCUs were the same?
>>
>
> Well, give us all here an example of a FPGA that can fully emulate a
> TSM320 and costs $3 :-)

There are a number of $3 FPGAs.  I can't imagine why you would want to 
emulate a DSP in an FPGA.  I would rather design a project using an 
FPGA.  TI likely has a restriction about running their code compiled 
with their tools in an FPGA softcore.  So what is your project?


>>>> You are aware that there are Flash based FPGAs that don't require the
>>>> external Flash chip, right?
>>>>
>>>
>>> Same with uCs, since a very long time :-)
>>
>> You are missing my point.
>>
>
> I guess then I don't see your point. Flash is available on almost
> everything nowadays.

I was comparing FPGAs to FPGAs.  Many FPGAs require external Flash, some 
don't.  Just like most DSPs require external flash, most MCUs don't.

-- 

Rick

On 9/7/2013 2:11 PM, Ulf Samuelsson wrote:
> rickman skrev 2013-09-06 23:12:
>> On 9/6/2013 4:33 PM, Joerg wrote:
>>> rickman wrote:
>>>> On 8/22/2013 1:51 PM, Joerg wrote:
>>>>> Tim Williams wrote:
>>>>>> "Joerg"<invalid@invalid.invalid> wrote in message
>>>>>> news:b7l1blFlu93U2@mid.individual.net...
>>>>>>>>> I saw people
>>>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like
>>>>>>>>> that,
>>>>>>>>> as usual.
>>>>>>>> It doesn't really matter.
>>>>>>>>
>>>>>>> However, not everyone knows that because they don't say much about
>>>>>>> the
>>>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd.
>>>>>>
>>>>>> Finally gave up and bit the uC bullet? ;-)
>>>>>>
>>>>>
>>>>> Sometimes you need it. A while ago I even had a switcher design that
>>>>> would have been totally impossible to do without a uC. But it does
>>>>> raise
>>>>> eyebrows if I request timers and port pins and MIPS, probably
>>>>> because of
>>>>> my analog background. "YOU want some of the uC resources? What for?"
>>>>
>>>> Sounds to me like you need FPGA resources moreso than an MCU. Are you
>>>> using the ADC or DAC, guess so or are you using the reference for the
>>>> brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
>>>> Otherwise FPGAs do everything an MCU does plus...
>>>>
>>>
>>> I nearly always need ADC capability. Not for the brownout, I never trust
>>> anything on those chips for that, the POR/BOR/WDT goes external. FPGA
>>> have some downsides, they tend to become large, expensive and sometimes
>>> power-hungry when you need math capability or an MCU core.
>>
>> If your FPGA designs are expensive or power hungry, then you are doing
>> things you can't do in an MCU or you are not using FPGAs properly. They
>> don't need to use any more power than an MCU and in many cases less.
>> They certainly don't need to be significantly more expensive unless you
>> consider every dollar in your designs. At the very low end MCUs can be
>> under $1 and still have reasonable performance. For $1 you can't get
>> much in the way of programmable logic. For $3 however, you can get a
>> chip large enough for a CPU (with math) and room for your special logic.
>>
>>
>>> But the main
>>> issue for many projects is people. If the client has the experts in
>>> house like in this case, fine. But if not then one is better off using a
>>> uC where one can find a programmer in nearly every town. This is one
>>> reason I am often partial to the 8051.
>>
>> Do you work in *every* town? I find if I need a skill, it doesn't
>> matter where the worker is. I also find FPGA design is pretty common
>> these days. If you are ever short on FPGA design skills, give me a shout.
>>
>>
>>> Of course the beauty of FPGA is that the availability of very fast glue
>>> logic. Most uC are sorely lacking in that domain.
>>
>> Yes, the ideal chip would add a section of FPGA fabric to a conventional
>> MCU and vary the size just as they do the RAM and Flash. I think at
>> this point the problem is cultural. Most FPGA companies are all about
>> the big iron selling for $100 a chip min and the MCU makers don't
>> understand programmable logic. Xilinx and Cypress is good examples.
>> Zync is a very high end solution, great if it matches your problem. PSOC
>> is not a bad idea, but their idea of programmable logic isn't worth much.
>>
>> Give me a good $10 MCU/FPGA combo and I'll design the world! In the
>> meantime I'll be using soft cores. They are a lot easier to program
>> than an MCU anyway.
>>
>
> That was available with the FPSLIC. AVR core with 5/10/40k gates.
> Unfortunately the combination of features didn't make sense.
>
> 40 MHz AVR with only 36 kB SRAM.
>
> It would have been much better with an ARM7 core
> with an external memory bus.

I don't know about the external memory bus, but the problem I had with 
the FPSLIC is that I was never convinced it would last.  It did however 
even with a very limited market penetration.  I don't know how large the 
FPGA fabric was, nobody usefully measures FPGAs in gates anymore.  So 
I'm guessing it was actually very limited.  I know for a fact it was 
rather pricey.


> Since it was implemented in a technology, and not shrinked,
> it eventually become cheaper to use a softcore with
> a standard FPGA in a fine geometry technology.
>
> I came to the conclusion that an MCU company cannot compete with an FPGA
> company unless the programmable logic part is only a small percentage of
> the die.

Compete how?  The FPGA companies are leaving huge segments of the market 
open to anyone who has the guts to exploit it.

> It would make sense to have a 5 kgate FPGAs in a modern micro.

I think 5 kgate is a tiny FPGA - what a couple of 22V10s?  It would be 
about the size of a UART in an MCU design.  Try 2-5 kLUTs then you have 
a useful device.  Otherwise you are just pissing in the wind.  The FPGA 
fabric should be roughly the same die size as the Flash or RAM and 
should scale as the memory does.


> The Xilinx Zync and Altera SoC are nice tries, except that most
> of the standard peripherals suck and it is still beyond the price
> most customers I've seen are prepared to pay.

You need to understand their markets.  Their designs are very good for 
their markets which are high profit margin.  Thinking like a $1 MCU 
maker wont let you compete in their space.  But you can compete in a $2 
to $10 MCU+FPGA space.  So get out there and explain it to your 
management!  Otherwise you lose design wins to softcores which get 
cheaper every day.

-- 

Rick

rickman wrote:
> On 9/7/2013 1:59 PM, Joerg wrote:
>> rickman wrote:
>>> On 9/7/2013 11:10 AM, Joerg wrote:
>>>> rickman wrote:
>>>>> On 9/6/2013 7:10 PM, Joerg wrote:
>>>>>>
>>>>>> That is often the problem. Sometimes a buck fifty is the pain
>>>>>> threshold.
>>>>>> Not in this ATMega case, the 2560 is very expensive but comes with
>>>>>> lots
>>>>>> of ADC and analog muxes and all that. Things that will cost extra
>>>>>> with a
>>>>>> FPGA solution and eat real estate.
>>>>>>
>>>>>>
>>>>>>     For $3 however, you can get a
>>>>>>> chip large enough for a CPU (with math) and room for your special
>>>>>>> logic.
>>>>>>>
>>>>>>
>>>>>> For $3 I can get a big DSP.
>>>>>
>>>>> What "big" DSP can you get for $3? ...
>>>>
>>>>
>>>> For example, this:
>>>>
>>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf
>>>
>>> I don't see it for $3.  Did you get a quote for your project?  TI says
>>> it is $5 to $8 at qty 1k depending on the flavor.  You still need to add
>>> Flash.
>>>
>>
>> 1k qty is $3.67 at Digikey:
>>
>> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713
>>
> 
> Not the same part pal.  You're trying to pull a fast one on me?  Are we
> talking about the TMS320C5535 with "tons" of memory or the TMS320C5532
> with *much* less memory?
> 

It doesn't have the single access RAM but it does have 64k dual access
RAM. That's a lot of RAM in embedded.

> 
>> $3.02 with 12wks leadtime at Arrow:
>>
>> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na
>>
>> ROM is included.
> 
> ROM is not Flash.. is it?  Are you thinking in terms of a mask ROM?
> 

You can use the bootloader or OTP your own bootloader if you don't want
to store your programming in ROM. In most situations this is part of a
larger computerized system from where it can download its programming.


> 
>>>>>                            ... It has been a while since I looked
>>>>> hard at DSP chips, but I don't recall any I would call remotely "big"
>>>>> for $3.  The TI chips that would be "big" are the TMS6xxx line which
>>>>> start somewhere around $20 the last time I looked and that requires
>>>>> all
>>>>> memory and I/O to be separate.  The smaller DSP chips that you can get
>>>>> for the $3 range are not "big" in any sense and only a very few of
>>>>> them
>>>>> include Flash memory.  So you still need another chip.
>>>>>
>>>>
>>>> It has tons of memory on board.
>>>
>>> Yes, and many FPGAs have "tons" of memory on board although not for
>>> $3... but then this isn't a $3 part either...
>>>
>>
>> It is a $3 part. See above.
> 
> No, you need to pick a part number and stick with it.
> 

I gave a part number. Still waiting for your $3 FPGA part number :-)

> 
>>>>> Even a "small" FPGA can run rings around a DSP when it comes to
>>>>> performance.  Usually "big" in DSPs means fast and when you want
>>>>> really
>>>>> fast DSP you use an FPGA with all the parallelism you can handle. 
>>>>> DSPs
>>>>> can't touch FPGAs for speed, even with low power.
>>>>>
>>>>
>>>> Most of the really powerful FPGA that I connected to or had to review
>>>> designs with them in there were painfully expensive.
>>>
>>> Because you were looking at FPGAs that were "painfully" large I'm sure.
>>>   How many pins, 256, 400+...?  20,000 LUTs, 40,000 LUTs?
>>>
>>
>> Sure, that's why I wrote "powerful". The less powerful ones have never
>> impressed me much but I have to admit that I haven't looked the last
>> five years. So, tell us, which FPGA can fully replace the above DSP for
>> three bucks and where could one buy it off the shelf?
> 
> Lol, I don't know where you are coming from now.  You don't like the
> large FPGAs because they use power like they are... well, large.  You
> don't like the small FPGAs because they are, well... small.
> 
> When you stop using terms like "powerful" and want to actually consider
> an FPGA for a design I can help you.  Gut feel is nice as long as it is
> based in fact.
> 

So then, what would be an FPGA that can fully contain the above TMS320
and what does it cost?

Which one could replace the MSP430F6733 including its ADCs and all, for
around $3?

http://www.ti.com/lit/ds/symlink/msp430f6720.pdf

[...]


>>> I can only remember one time where I iterated through design changes in
>>> the field and that was actually a case where I could have done it all
>>> remotely, but I was pleasing the customer to be there.  Turns out he
>>> wasn't initializing the design right and it was hard to detect.
>>>
>>
>> Well, if you are standing next to a huge roaring engine and this, that
>> and the other subtle disturbance has to be ironed out it would be a
>> major problem if the programmer is three time zones away. You don't have
>> to believe me but that's how it is with some of my assignments.
>>
>> Just like EMC jobs on large gear can simply not be done remotely. Which
>> is why I bought the Signalhound analyzer (fits into carry-on).
> 
> I don't argue your needs.  You keep saying these special jobs are a
> small percentage of your work.  So most assignments will work just fine
> with remote support, no?
> 

Yes, for myself I'd say it's >90%. For firmware and software support,
much lower percentage. Currently <50% of cases. Meaning I (or some other
folks) and the programmers have to literally work side-by-side.

Mostly this simply has to do with the fact that gear is too large to
ship and often also because operation by someone not used to it can
become dangerous. When pressures are several thousand psi and someone
screws up people could die.

> 
>>> One big advantage to FPGAs is the ability to simulate at a low level. it
>>> is very easy to emulate the I/O in an HDL simulation.  I don't know how
>>> they do that with MCUs, but in the FPGA world I've never had a problem.
>>>
>>
>> That is undoubtedly true. Plus probably less in errata headaches.
>>
>> [...]
>>
>>
>>>>> I've used schematic based tools and both VHDL and Verilog.  I've
>>>>> worked
>>>>> with the vendor's tools and third party tools including the NeoCAD
>>>>> tools
>>>>> which became Xilinx tools when Xilinx bought them.
>>>>>
>>>>> If anyone tells you they only know one brand of FPGA you are
>>>>> talking to
>>>>> an FPGA weenie.  I find MCUs to vary a *great* deal more than FPGAs in
>>>>> terms of usage.  MCUs need all sorts of start up code and peripheral
>>>>> drivers, clock control, etc, etc, etc.  FPGAs not so much.  They
>>>>> mostly
>>>>> have the same features and most of that can be inferred from the
>>>>> HDL so
>>>>> you never need to look too hard under the hood.
>>>>>
>>>>> In short, there is a lot of FUD about FPGAs.  Talk to someone who
>>>>> doesn't buy into the FUD.
>>>>>
>>>>
>>>> Yeah, maybe next time I need major logic we should talk. But better not
>>>> about politics :-)
>>>
>>> Yeah...  Even if you need minor logic let's talk.  I find the real
>>> advantage to FPGAs is in the fact that I can do almost *anything* in
>>> one.  I don't need to add stuff unless it is very application specific
>>> like the CD quality CODEC on my current production board.  I could get
>>> CD quality from an FPGA design, but it wouldn't be worth the work to
>>> save a $3 part.
>>>
>>
>> So far the next project on the books that will contain logic is 2nd half
>> of next year. It will need a 16-bit audio codec as well but we can use
>> an external chip for that, PCM29xx series et cetera. Would (probably)
>> even keep it external with a uC because the 16-bit ADCs on those aren't
>> very quiet.
> 
> Not sure what the requirements are for your CODEC, but I have been using
> the AKM parts with good results.  Minimal or *no* programming,
> configuration is done by a small number of select pins, very simple.  I
> have yet to find another one as small, AK4552, AK4556.
> 

Plus their prices are quite good.

[...]


>>> You do know that it is not hard to add an ADC to an FPGA?  No need for a
>>> mux if all the inputs can be connected to separate pins.  It all depends
>>> on the resolution you need.  8 bits is easy, 16 bits - not so easy.
>>>
>>
>> Mine are never less than 12-bit, often 16-bit.
> 
> What about delay time?  Is sigma-delta ok?
> 

As long as I can get into the tens of ksps.

> 
>>>>>> Last week I reviewed a design with some larger FPGA on there. What I
>>>>>> found fairly disgusting was how much they had to be babied with the
>>>>>> power sequencing. uCs don't have that problem.
>>>>>
>>>>> If you want to work with the wrong device, then you will find it
>>>>> hard to
>>>>> work with.  There are still single voltage devices on the market.  If
>>>>> this was an old design, most likely it was a Spartan 3 or similar era
>>>>> device when they (for still unknown reasons) used three, yes, count
>>>>> them, *three* voltages on the FPGA.  The 2.5 volt aux supply was there
>>>>> solely for the configuration interface which was normally to a 3.3
>>>>> volt
>>>>> device!  Only from Xilinx...
>>>>>
>>>>> If this was a new device, then I guess they picked one based on
>>>>> something other than ease of use, eh?  Don't assume all FPGAs are the
>>>>> same.
>>>>>
>>>>
>>>> Well, this guy is a real expert on high-end FPGA and the project
>>>> requires stuff with tons of horsepower.
>>>
>>> That's fine, just don't judge all FPGAs by the ones you have seen.  If
>>> the only MCU you had worked with were ARM 11s using 3 Watts and running
>>> a cell phone down in 8 hours, would you think the PIC MCUs were the
>>> same?
>>>
>>
>> Well, give us all here an example of a FPGA that can fully emulate a
>> TSM320 and costs $3 :-)
> 
> There are a number of $3 FPGAs.  I can't imagine why you would want to
> emulate a DSP in an FPGA.  I would rather design a project using an
> FPGA.  TI likely has a restriction about running their code compiled
> with their tools in an FPGA softcore.  So what is your project?
> 

I wasn't referring to a specific project, just your claim that FPGA can
do the same job as processors at the same price.

One project will probably require something of the caliber of a
MSP430F6733. Whether this kind or a DSP, what is key is that we are able
to use pre-coooked library routines. In my case for complex (I/Q) signal
processing, FFT, non-linear filtering and so on. Sometimes legacy
routines must be kept and in an FPGA that would require an IP block that
can emulate the respective processor well enough.

But what I see most is this: The respective client has in-house talent
for writing code. They are familiar with a particular architecture, have
a vast arsenal of re-usable code built up, and naturally they do not
wish to give this up. If it's a dsPIC like last year, then that goes in
there. If it's Atmel and MSP430 like this year, then that is used. Has
to be, the customer is king.

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

rickman wrote:
> On 9/7/2013 12:32 PM, Joerg wrote:
>> rickman wrote:
>>>
>>> You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
>>>   It has been a while since I got a quote.  The 1 kLUT part is big
>>> enough
>>> for a soft core MCU plus some custom logic.
>>>
>>
>>
>> Got a mfg and part number? Or a Digikey link?
> 
> At Digikey search on iCE40.  That will give you a listing of all the
> parts.  Looks like Digikey's prices are a little high, not just because
> they are Digikey.  The $3 figure I gave is from quotes I got from
> Silicon Blue before they were traded through Digikey. ...


Which part number?

I don't see how the equivalent of a TMS320 or a big MSP430 could fit
into one of these small Lattice devices.


>                                              ... Like I said, you
> need to get a quote on any FPGA to find the "real" price.
> 

I don't play those games. Or only once every 20-some years when buying a
car, and then the car dealer may develop an ulcer when we are done.

> 
>>> BTW, with MCUs Digikey will give you a realistic price quote.  In the
>>> FPGA world the distis never give you a good price unless you ask for a
>>> quantity quote.  I have gotten prices quoted to me that were half the
>>> list price.  FPGA companies play a different marketing game and have a
>>> lot of room to negotiate in order to buy a socket.
>>>
>>
>> Yeah, the old haggle game. Beats my why they still cling to such
>> medieval sales tactics. The only other market where that is customary is
>> with used car salesmen.
>>
>> They don't even know how much in business opportunity they are missing
>> because of this. Guys like me need pricing info here, this minute, right
>> now. If there is even as much as a label "Call" I usually move on.
> 
> I don't think it is all about the "haggle".  I think no small part is
> about doing what it takes to get the design in and deny the competition.
>  When you get quotes from Digikey web site they never even know you are
> looking at their parts.  Think of it as a live auction vs. sealed bids.
>  They prefer to be in the live auction.
> 

Well, most design engineers don't. tti lost a deal on capacitors last
week because they wouldn't let me look at the details of a cap without
entering some stupid captcha. Which as usual didn't work. I moved on and
 found it elsewhere. I simply do not have the time for such games.

-- 
Regards, Joerg

http://www.analogconsultants.com/

Ulf Samuelsson wrote:

[...]

> 
> I came to the conclusion that an MCU company cannot compete with an FPGA
> company unless the programmable logic part is only a small percentage of
> the die.
> 

They can compete, with the peripherals. But those have to be of good
performance and most of all versatile enough. Some things can probably
be achieved in simple ways. For example, by providing the option to map
two pins per ADC channel for folks who need it to be low noise.


> It would make sense to have a 5 kgate FPGAs in a modern micro.
> 

Bingo! That would be fantastic.


> The Xilinx Zync and Altera SoC are nice tries, except that most
> of the standard peripherals suck and it is still beyond the price
> most customers I've seen are prepared to pay.
> 

I hope this doesn't rub you the wrong way but Atmel often ain't that
great either when it comes to peripherals. When I looked at the
"reference" in the ATMega2560 that we just designed in I almost got
sick. In the relayout we piped in our own reference.

-- 
Regards, Joerg

http://www.analogconsultants.com/