On 4/2/2015 6:52 PM, already5chosen@yahoo.com wrote:
> On Friday, April 3, 2015 at 1:03:23 AM UTC+3, rickman wrote:
>> On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:
>>> On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
>>>> On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:
>>>>
>>>>> On 4/1/2015 1:27 PM, John Speth wrote:
>>>>
>>>>>> I've used both example products with great success. As you said, it's
>>>>>> real convenient to roll your own peripherals with impunity. It saved
>>>>>> me hours of coding effort when you can smartly implement the peripheral
>>>>>> of your dreams with a little HW design.
>>>>>
>>>>> The part that gets me about the newer versions of this theme is that
>>>>> they are large, pricey FPGAs and incorporate fairly high end CPUs which
>>>>> are typically programmed under Linux... a very far cry from the
>>>>> efficient solution I would like to see. There are few engineers who can
>>>>> even design the entire system on that chip spanning logic design and
>>>>> system programming.
>>>>
>>>> Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
>>>> which have big monster Cortex A9s meant to run Linux with a mess of DRAM
>>>> and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
>>>> FPGA with a dual or quad Cortex M4 instead? Nice and light with every
>>>> intention of running bare metal with 10-20K of code? I'd take it in a
>>>> heartbeat.
>>>>
>>>> --
>>>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>>>> Email address domain is currently out of order. See above to fix.
>>>
>>> Cortex-M is most useful when you have good chunk of flash on the same die. Which, unfortunately, would be incompatible with silicon tech used for moderm FPGAs.
>>
>> That is a bit of nonsense unless you consider Lattice and MicroSemi to
>> not be using "modern" FPGA processes. They include Flash in their
>> devices for the configuration memory.
>>
>
> Well, you are right, I am not familiar with Lattice and MicroSemi. From the little I know about them their FPGA are modern in a sense that they a new products and, may be, modern in specific system-level features, but when it comes to size and performance of the fabric, including such important to some of us characteristic as dynamic power per watt (static power is probably o.k) they are at least 5 years behind X&A, but probably more than 5.
Sometimes I get really tired of of Thunderbird. When I reply to a post
the quoted text is just as likely as not to extend beyond the margin and
off the screen... a bloody nuisance I tell you.
Anyway, I think you are not familiar at all with the Lattice products.
They have lines of FPGAs that are RAM based like the X and A parts and
are likely a generation behind in many terms... but you shouldn't focus
on the things that are intangible to you. Do you really care what
geometry a part is made in? No, you care whether your design will fit,
if it will run fast enough and how much the part costs. I think unless
you need the largest parts in the X or A line the L parts will do the
job competitively.
I would also mention that you can thank L for the availability of SERDES
in lower cost FPGAs. Lattice was the first to offer that and X and A
only followed begrudgingly I think.
The other parts, like the XOx and XPx lines can't be compared to
anything X or A makes (unless they've come out with something in the
last 6 months) because X and A have shied away from the Flash based
market. They are adequately fast and have brought the price down to a
point where they are competitive against MCUs in some apps.
So saying L is 5 years behind is probably no accurate and not very useful.
>>> DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.
>>
>> Once again you should tell that to MicroSemi... They make a mixed signal
>> FPGA with CPU, analog and FPGA on one die. I don't use it because of
>> the price, a bit higher than I like to see.
>>
>>
>>> Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.
>>
>> I think you are saying that an FPGA with internal MCU is not as useful
>> as separate FPGA and MCU because the MCU will have lots of other stuff
>> integrated that would be additional chips with the integrated approach.
>
> Yes, NOR flash, ADCs, DACs.
>
>> Clearly it doesn't have to be that ways since at least one company
>> makes such parts.
>>
>>
>>> The ugly part about MCU + FPGA solution is that, unlike chips from the past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA (good=simple, not to slow and not too many pins). But then again, those old 32-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA.
>>
>> That brings us back to the real differences between the MCU world and
>> the typical FPGA world. MCUs are intended for apps where speed is
>> limited by the software. FPGAs are intended for apps where speed is
>> potentially much faster with the limitation potentially in the I/O. So
>> a typical high end FPGA will have lots of I/O and some very fast I/O.
>>
>
> That about right, except that I am not talking about high-end FPGAs, but about modern "low-cost" lines of A&X. So, fast I/O optional and very fast I/O is rarely even an option (fast=1-3.125 Gbit/s, very fast= >3.125).
> But for MCU<->FPGA interface I will be mostly satisfied in much more moderate speed. Say, something logically similar to venerable LPC bus, but without 24-bit address space limit (28 bits probably acceptable) and with physical layer of RGMII.
"High" speed is relative. Integrated MCUs would have direct bus mapped
access to FPGA connections which clearly would run at full speed
depending on your FPGA design. Multi-die solutions would need to be bit
banged I/O from the MCU or use some peripheral like SPI or Ethernet. As
you say, there ain't no buses on many MCUs anymore.
>> But such an integrated MCU/FPGA device would not be intended for high
>> end apps with Mbps I/O. The FPGA would be adding special functionality
>> that perhaps can't be done in the MCU alone. I had a design that
>> required exactly this sort of need and ended up having to use an FPGA
>> with an attached CODEC since there were no MCUs which could implement
>> one interface. The FPGA was a bit jammed up in terms of capacity (only
>> 3 kLUT). A small soft core could do most of the work and potentially
>> free up some space. Had a combined chip been available it would have
>> been a breeze to implement the one interface in hardware (or maybe two)
>> and the rest of the design in software.
>>
>>
>>> Back to another reason why I think that hard ARM Cortex-M4 core in [Altera or Xilinx] FPGA does not look as a very good proposition:
>>> The added value of M3/M4 core alone, without flash and mixed-signal peripherals, is not that big. After all Nios2-f core (only core, without debug support and avalon-mm infrastructure around it) occupies only ~25% of the smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves comparable performance. As far as I am concerned, the main advantage of Cortex-M is a code density - significantly more code can fits on-chip. But even that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.
>>
>> Yep, the low end MCU on an FPGA without any of the peripherals would not
>> be a lot more interesting than a soft core.
>
> Just a nitpick - by definition there is no such thing as "MCU without any of the peripherals". Let's call them "MCU-style hard cores" or just "ARM Cortex-M4" because this particular core looks like the most logical (or least illogical) candidate.
Not sure what that means, but whatever. Potatoes, Patahtoes.
>> So when will they be doing
>> a better job of the Vulcan mind meld and getting more analog on the FPGA
>> die? It's not like there is anything so special about FPGA logic that
>> can't be done in analog compatible processes. Maybe you lose some
>> density or performance, but that isn't what we are after. At least *I*
>> am looking for a system on chip which includes some FPGA fabric. Don't
>> think of it as an FPGA with an MCU on chip.
>
> Yes, could be nice. But to be real useful FPGA part should not be too small.. I wouldn't bother for 1K 4-input LUTs. 5K looks like reasonable minimum, at least for gray haired devs like you and me. Younger guys a spoiled, they'd want more than that.
My current product is shipping in a 3 kLUT device. I could have shoved
a lot more functionality in if I had used a soft core (of my own design,
the canned ones are too large).
>> Think of it as an MCU with
>> FPGA fabric on chip just like the other umpty-nine peripherals they
>> already have along with.... gasp!... 5 volt tolerance. lol
>>
>
> Is 5-V tolerance really that useful [in new designs] without ability to actually drive 5V outputs? I suppose, even you don't expect the later in 2015 :-)
There are any number of MCUs that still have 5 volt I/Os. A Cypress
line that I was looking at can run with Vcc of 1.8-5 V. Clearly there
is a need for such parts or they wouldn't keep designing them. The FPGA
vendors ignore this segment because they have never wanted to go down
the low price, high volume road in earnest. They would love to get some
automotive products designed in and 5 volt I/Os are popular there I
believe. I remember when the Xilinx folks were saying the next
generation after Spartan 3 would not support 3.3 volt I/Os! But then
they also told me that if I connected the FPGA to the load with a 1 inch
trace I could blow up the Spartan I/Os if I didn't simulate it. Really?
They tend to see the world through FPGA glasses as if they drove the
market rather than the market driving their designs.
--
Rick