AREF bypass capacitance on ATMega2560?

Joerg <invalid@invalid.invalid> writes:
> I don't see how the equivalent of a TMS320 or a big MSP430 could fit
> into one of these small Lattice devices.

I had thought the parts of those processors that would bloat up badly
(instruction decode etc.) are pretty simple so the overall effect of the
bloat is ok in the scheme of things.  The parts doing the most work
(memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks,
adders connected to the LUT's somehow) as efficiently as on the MCU's.

I do think softcores seem like a silly idea a lot of the time, and am
looking forward to more low end FPGA's with MCU blocks.

On 9/7/2013 3:39 PM, Joerg wrote:
> 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.

You do this often.  Start talking about one thing and shift the context 
to another.  Projects have design requirements.  I often am able to meet 
my design requirements with an FPGA and no MCU.  I often can't say the 
opposite, being able to use an MCU without the FPGA.


>>> $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.

That's a different wrinkle.  It is common to have a micro load an FPGA, 
many don't contain their own Flash.  But I haven't seen this done with 
DSPs as often and almost never with MCUs.  But if that works for your 
project, great.  You certainly wouldn't have a problem loading an FPGA 
then.


>>>>>>                             ... 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 :-)

Actually you gave me two part numbers, one for $5 and one for just over 
$3.  What's your point?  I gave you info to find the iCE40 line.  Xilinx 
also makes FPGAs that are very affordable and does Altera and Lattice.


>>>>>> 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 have already explained that I would never do a design in an FPGA to 
wholly incorporate a DSP or MCU.  That would be absurd.  So why do you 
keep asking about that?

Depending on your design requirements there are any number of FPGAs that 
will do the job and some may be $3.  What are your design requirements?


>>>> 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.

I understand the concept of work that can't be moved.  You don't need to 
continue to explain that.  I was asking why you said most of your word 
didn't have that requirement and yet you still were debating the point. 
  Now I get it, you are talking about two different things, work that 
can be moved and work that can't be moved.


>>>> 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.

Which, AKM or the other? I'd like to think I can get a CD quality CODEC 
for $3 from nearly anyone.  I mainly picked AKM because of the size, 6x6 
mm without going to a microBGA.


>>>> 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.

High 10's or low 10's.  Up to say, 20 or 30 ksps is easy to do in an 
FPGA with decent resolution, 12 bits.  Getting 16 bits is harder, I've 
not tried it, but should be possible.

I was looking at using a LVDS input for a comparator and Xilinx did it 
in a demo of a SDR.  They are very short on details, but they talk about 
1 mV on the input.  I know that's not anything special, I'm hoping to do 
better, much better.


>>>>>>> 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.

Yes, that is my claim.  The obvious exception is when some feature is 
needed that just isn't available in an FPGA.  I'm not saying *every* 
project can be done better in an FPGA.  I'm saying that designers tend 
to just not consider FPGAs when they are often viable solutions.


> 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.

Ok, that is likely a no-go.  If you really want to emulate a DSP chip 
then an FPGA is not likely to be a useful way to proceed.  Wanting to 
run DSP precompiled library code is a bit of an extreme requirement.  If 
the customer wants a DSP, then by all means give them a DSP.  But don't 
automatically exclude an FPGA from the task.


> 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.

Yeah, well that is a deal killer for *any* other alternative.  That is 
not related to what I was saying.  My point is that if you don't have 
any specific requirement that dictates the use of a given chip, an FPGA 
has as good a chance at meeting the requirements as an MCU or DSP.  In 
fact, FPGAs are what get used when DSPs aren't fast enough.  My point is 
you don't have to limit them to the high end.  They also do very well at 
the low end.

-- 

Rick

Paul Rubin wrote:
> Joerg <invalid@invalid.invalid> writes:
>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit
>> into one of these small Lattice devices.
> 
> I had thought the parts of those processors that would bloat up badly
> (instruction decode etc.) are pretty simple so the overall effect of the
> bloat is ok in the scheme of things.  The parts doing the most work
> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks,
> adders connected to the LUT's somehow) as efficiently as on the MCU's.
> 
> I do think softcores seem like a silly idea a lot of the time, and am
> looking forward to more low end FPGA's with MCU blocks.


Much of it has to do with legacy code. Yes, some things could even be
done more efficiently in the FPGA because you can actually streamline
the HW to the task, something neither uC nor DSP allow. For example, why
have a 32-bit HW multiplier when you know you'll never exceed 23 bits?
But legacy code won't run anymore and you need FPGA specialists to make
it all work.

It's like with Excel. There's better programs out there but one core
reason why companies stick to it is the huge repository of VBA
applications they have created over the years.

-- 
Regards, Joerg

http://www.analogconsultants.com/

On 9/7/2013 4:33 PM, Paul Rubin wrote:
> Joerg<invalid@invalid.invalid>  writes:
>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit
>> into one of these small Lattice devices.
>
> I had thought the parts of those processors that would bloat up badly
> (instruction decode etc.) are pretty simple so the overall effect of the
> bloat is ok in the scheme of things.  The parts doing the most work
> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks,
> adders connected to the LUT's somehow) as efficiently as on the MCU's.
>
> I do think softcores seem like a silly idea a lot of the time, and am
> looking forward to more low end FPGA's with MCU blocks.

How about an MCU array instead?

http://www.greenarraychips.com/

BTW, considering a softcore "silly" is not a useful engineering 
analysis.  Softcores can save money and/or time in a project.  But then 
people often have biases and aren't willing to look at things from a 
different perspective.

Bernd Paysan rolled his own small processor design for an ASIC and was 
able to save time *and* money in development as well as silicon cost 
over using a canned core in a custom ASIC design.  Dig around a bit and 
find the B16 for more details.  Or he would be happy to relate the 
fiasco of the whole project (it started with an 8051 core).

-- 

Rick

On 9/7/2013 4:46 PM, Joerg wrote:
> Paul Rubin wrote:
>> Joerg<invalid@invalid.invalid>  writes:
>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit
>>> into one of these small Lattice devices.
>>
>> I had thought the parts of those processors that would bloat up badly
>> (instruction decode etc.) are pretty simple so the overall effect of the
>> bloat is ok in the scheme of things.  The parts doing the most work
>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks,
>> adders connected to the LUT's somehow) as efficiently as on the MCU's.
>>
>> I do think softcores seem like a silly idea a lot of the time, and am
>> looking forward to more low end FPGA's with MCU blocks.
>
>
> Much of it has to do with legacy code. Yes, some things could even be
> done more efficiently in the FPGA because you can actually streamline
> the HW to the task, something neither uC nor DSP allow. For example, why
> have a 32-bit HW multiplier when you know you'll never exceed 23 bits?
> But legacy code won't run anymore and you need FPGA specialists to make
> it all work.

No, you would need a DSP specialist.  The FPGA designer only needs to 
know how to code the FPGA.

But that is exactly the point of the FPGA in DSP apps.  You code to the 
app, not to a processor.

-- 

Rick

rickman <gnuarm@gmail.com> writes:
> How about an MCU array instead?  http://www.greenarraychips.com/

Yes, we've had many discussions about that part ;-).  

> considering a softcore "silly" is not a useful engineering analysis.

The engineering analysis is implied: it takes far more silicon to
implement a microprocessor in LUTs than directly in silicon, plus you
lose a lot of speed because of all the additional layers and lookups.

> Bernd Paysan rolled his own small processor design for an ASIC

Yes, the ASIC bypassed the relative inefficiency of doing the same thing
in FPGA's.  It would be cool to have some tiny processors like that
available as hard cells on small FPGA's.

rickman wrote:
> On 9/7/2013 3:39 PM, Joerg wrote:
>> 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.
> 
> You do this often.  Start talking about one thing and shift the context
> to another. ...


I didn't. I said it is a DSP with large memory, which it is.


>   ... Projects have design requirements.  I often am able to meet
> my design requirements with an FPGA and no MCU.  I often can't say the
> opposite, being able to use an MCU without the FPGA.
> 
> 
>>>> $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.
> 
> That's a different wrinkle.  It is common to have a micro load an FPGA,
> many don't contain their own Flash.  But I haven't seen this done with
> DSPs as often and almost never with MCUs.  But if that works for your
> project, great.  You certainly wouldn't have a problem loading an FPGA
> then.
> 

The fact that most FPGA don't have flash is fine ... but ... there must
be a decent bootloader inside. In one of the upcoming projects it must
be able to bootload via USB. So the device must wake up with a certain
minimum in brain functionality to handle the USB stuff. With FPGA that
can become a challenge unless you provide a serial memory device (which
adds cost).

> 
>>>>>>>                             ... 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 :-)
> 
> Actually you gave me two part numbers, one for $5 and one for just over
> $3.  What's your point?  I gave you info to find the iCE40 line.  Xilinx
> also makes FPGAs that are very affordable and does Altera and Lattice.
> 

Both of the ones I gave you are $3. The DSP costs $3.02 and the MSP430
is $3.09. These are over-the-counter no-haggle prices. Can a $3 iCE40
device emulate a TMS320 or a big MSP430? I can't tell because I don't
know this Lattice series and I am not an FPGA expert. But it sure looks
like they'd have a hard time.

> 
>>>>>>> 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 have already explained that I would never do a design in an FPGA to
> wholly incorporate a DSP or MCU.  That would be absurd.  So why do you
> keep asking about that?
> 

Because you wrote yesterday, quote "For $3 however, you can get a chip
large enough for a CPU (with math) and room for your special logic".


> Depending on your design requirements there are any number of FPGAs that
> will do the job and some may be $3.  What are your design requirements?
> 

As I said, I do not have any hammered out ones yet but it'll come. This
was just about you $3 claim. So I gave some examples of devices that
cost $3.

> 
>>>>> 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.
> 
> I understand the concept of work that can't be moved.  You don't need to
> continue to explain that.  I was asking why you said most of your word
> didn't have that requirement and yet you still were debating the point.
>  Now I get it, you are talking about two different things, work that can
> be moved and work that can't be moved.
> 

Yup. Hence the need for availability of local programmer talent. Less
local availability means potential problems. That is because (where
possible) I like to use architectures I am familiar with.

Programmer talent means longterm. For example, if a client has an issue
with an 8051 design long after the original programmer has moved on I
could find programmers within a 10-mile radius. Try that with an FPGA.
In San Jose it may be possible but not out here.

[...]


>>> 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.
> 
> Which, AKM or the other? I'd like to think I can get a CD quality CODEC
> for $3 from nearly anyone.  I mainly picked AKM because of the size, 6x6
> mm without going to a microBGA.
> 

AKM has good prices.

> 
>>>>> 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.
> 
> High 10's or low 10's.  Up to say, 20 or 30 ksps is easy to do in an
> FPGA with decent resolution, 12 bits.  Getting 16 bits is harder, I've
> not tried it, but should be possible.
> 

Mostly I need 40-50ksps. But 20 is often ok.


> I was looking at using a LVDS input for a comparator and Xilinx did it
> in a demo of a SDR.  They are very short on details, but they talk about
> 1 mV on the input.  I know that's not anything special, I'm hoping to do
> better, much better.
> 

If you can keep substrate noise in check it could work. Try to remain
fully differential as much as you can. Not sure if FPGA design suites
still let you hand-place blocks so you can avoid making a big racket
right next to the ADC area.

> 
>>>>>>>> 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.
> 
> Yes, that is my claim.  The obvious exception is when some feature is
> needed that just isn't available in an FPGA.  I'm not saying *every*
> project can be done better in an FPGA.  I'm saying that designers tend
> to just not consider FPGAs when they are often viable solutions.
> 

In most of my apps I need much of the functionality that a decent uC
affords, like the $3 device from the MSP430 series I mentioned.

> 
>> 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.
> 
> Ok, that is likely a no-go.  If you really want to emulate a DSP chip
> then an FPGA is not likely to be a useful way to proceed.  Wanting to
> run DSP precompiled library code is a bit of an extreme requirement.  If
> the customer wants a DSP, then by all means give them a DSP.  But don't
> automatically exclude an FPGA from the task.
> 

Sometimes it would also be ok if there were similar pre-cooked FPGA
routines (I/Q signal processing, non-linear filters et cetera).

> 
>> 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.
> 
> Yeah, well that is a deal killer for *any* other alternative.  That is
> not related to what I was saying.  My point is that if you don't have
> any specific requirement that dictates the use of a given chip, an FPGA
> has as good a chance at meeting the requirements as an MCU or DSP.  In
> fact, FPGAs are what get used when DSPs aren't fast enough.  My point is
> you don't have to limit them to the high end.  They also do very well at
> the low end.
> 

No disagreement there, programables have come a long way since the days
of GALs. Which I never used because they were expensive power guzzlers.

One other challenge that needs to be met in most of my cases is
longevity of the design. A FPGA would have to remain available for more
than just a few years. For example, one of my uC-based designs from the
mid 90's is still in production. Since I kind of had a hunch that this
would happen I used an 8051 family uC. Is there something similar in the
world of FPGA?

-- 
Regards, Joerg

http://www.analogconsultants.com/

"Joerg" <invalid@invalid.invalid> wrote in message 
news:b91lacF5bvnU1@mid.individual.net...
> One other challenge that needs to be met in most of my cases is
> longevity of the design. A FPGA would have to remain available for more
> than just a few years. For example, one of my uC-based designs from the
> mid 90's is still in production. Since I kind of had a hunch that this
> would happen I used an 8051 family uC. Is there something similar in the
> world of FPGA?

Interjecting what little experience I have here;

MAX7000s are still available, and they were introduced in 1995;
http://www.altera.com/devices/cpld/max-about/max-about.html
although I think they've finally gone out of stock (not that you'd want to 
use them, they also guzzle power like they're NMOS).

FLEX 10K FPGAs don't appear on their website, but they're still quite 
available.  Can't seem to find when they were introduced?  I'm seeing 
documents since at least 1996 referencing them.

At least between the big two (Altera that I know of, and I would assume 
Xilinx too), FPGAs look to have excellent support over time.

And VHDL doesn't age.  The library blocks might, but I'd be willing to 
guess that those are synthesized as well, so as long as your toolchain 
supports whatever code format, you can migrate chips easily when they do 
finally die.

And really, if you have to support something for over 20 years, it's 
probably time it does die and gets a redesign.  Like that VAX or whatever 
it was NASA's still supporting.

Tim

-- 
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com 

rickman wrote:
> On 9/7/2013 4:46 PM, Joerg wrote:
>> Paul Rubin wrote:
>>> Joerg<invalid@invalid.invalid>  writes:
>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit
>>>> into one of these small Lattice devices.
>>>
>>> I had thought the parts of those processors that would bloat up badly
>>> (instruction decode etc.) are pretty simple so the overall effect of the
>>> bloat is ok in the scheme of things.  The parts doing the most work
>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks,
>>> adders connected to the LUT's somehow) as efficiently as on the MCU's.
>>>
>>> I do think softcores seem like a silly idea a lot of the time, and am
>>> looking forward to more low end FPGA's with MCU blocks.
>>
>>
>> Much of it has to do with legacy code. Yes, some things could even be
>> done more efficiently in the FPGA because you can actually streamline
>> the HW to the task, something neither uC nor DSP allow. For example, why
>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits?
>> But legacy code won't run anymore and you need FPGA specialists to make
>> it all work.
> 
> No, you would need a DSP specialist.  The FPGA designer only needs to
> know how to code the FPGA.
> 

So for this kind of solution in an FPGA you need a DSP specialist and an
FPGA specialist? That would be a problem.


> But that is exactly the point of the FPGA in DSP apps.  You code to the
> app, not to a processor.
> 

How long do the usual FPGA stay in the market? Meaning plop-in
replaceable, same footprint, same code, no changes.

-- 
Regards, Joerg

http://www.analogconsultants.com/

Tim Williams wrote:
> "Joerg" <invalid@invalid.invalid> wrote in message 
> news:b91lacF5bvnU1@mid.individual.net...
>> One other challenge that needs to be met in most of my cases is
>> longevity of the design. A FPGA would have to remain available for more
>> than just a few years. For example, one of my uC-based designs from the
>> mid 90's is still in production. Since I kind of had a hunch that this
>> would happen I used an 8051 family uC. Is there something similar in the
>> world of FPGA?
> 
> Interjecting what little experience I have here;
> 
> MAX7000s are still available, and they were introduced in 1995;
> http://www.altera.com/devices/cpld/max-about/max-about.html
> although I think they've finally gone out of stock (not that you'd want to 
> use them, they also guzzle power like they're NMOS).
> 
> FLEX 10K FPGAs don't appear on their website, but they're still quite 
> available.  Can't seem to find when they were introduced?  I'm seeing 
> documents since at least 1996 referencing them.
> 

Ok, sorry, forgot to say that I never use that manufacturer.


> At least between the big two (Altera that I know of, and I would assume 
> Xilinx too), FPGAs look to have excellent support over time.
> 
> And VHDL doesn't age.  The library blocks might, but I'd be willing to 
> guess that those are synthesized as well, so as long as your toolchain 
> supports whatever code format, you can migrate chips easily when they do 
> finally die.
> 

But the minute a footprint changes or you have to re-compile you are
screwed in some heavily regulated markets.


> And really, if you have to support something for over 20 years, it's 
> probably time it does die and gets a redesign. ...


Nope. Not if it's in the worlds of medical or aerospace. There you have
a huge re-cert effort on your hands for changes. New layout? Back to the
end of the line.

You also need to support very old legacy equipment with type-certified
spare parts and for those few sales you really don't want a re-cert.
Just think about the DC-3 which is still in service. Some of those are
over 60 years old. Can be worse with elevators. We have a company near
here that sometimes has to support elevators that are over a century old.


>                     ... Like that VAX or whatever 
> it was NASA's still supporting.
> 

Sometimes changing is very time consuming. I recently learned that this
is even the case for alarm systems. "If we even add as much as one
capacitor for EMC we have to go through the whole insurer certification
process again".

-- 
Regards, Joerg

http://www.analogconsultants.com/